Tag Archives: jquery

professional, software development, visual studio, web authoring, windows

Telerik releases Kendo UI components for ASP.NET MVC

Component vendor Telerik has released an updated version of Kendo UI, its HTML5 framework. This is the first non-beta release with support for ASP.NET MVC server wrappers, with components including Grid, ListView, calendar and date controls, tree view, menu, editor and more. Kendo UI supports the MVVM (Model View ViewModel) pattern popular with Microsoft developers.

image

 

Telerik seems to be treading a careful path, maintaining its strong links to the .NET developer community while also creating a framework that can be used on other platforms.

I spoke to Todd Anglin, VP of HTML5 tools. Why the support for ASP.NET MVC – is Telerik seeing this becoming more popular than Web Forms, the older ASP.NET approach to web applications?

“Something in the range of 70% of ASP.NET developers are on web forms. We do see a bit of a trend that as they start new projects, developers are adopting ASP.NET MVC and HTML5, which is where it makes sense to use Kendo UI,” he told me.

The main reason though is that Kendo UI is less suitable for Web Forms, where more of the client-side code is generated by the framework. “Web Forms are a very high level abstraction,” said Anglin. “With MVC developers are a little closer to the metal.”

That said, he is not ruling out a Web Form wrapper for Kendo UI long-term.

Anglin says Kendo UI’s use of JQuery is a distinctive feature.  “Over the last few years JQuery has clearly risen above the pack to be the most common core Javascript library and the one most developers are familiar with. Unlike most commercial libraries out there Kendo UI chooses the JQuery core as the starting point and builds on that, so developers that adopt Kendo UI have a smoother on-ramp.”

Kendo UI supports both mobile and desktop web applications, but with different controls. “We believe that developers should offer experiences that are tailored to each device class, which is why you have Kendo UI web for keyboard and mouse, and Kendo UI mobile with a mobile-specific interface. We share code behind that, like the data source, between web and mobile, but we don’t think the interface on a mobile device should be the same as you show on a desktop browser,” said Anglin.

What about the tools side? Although Anglin says “We want to be agnostic on tools”, there is particularly good support for Visual Studion. “Kendo UI integrates with anything that supports HTML and JavaScript well, which includes the latest version of Visual Studio. We are delivering full vsdoc support for Visual Studio so that developers in that environment get Intellisense for JavaScript. But if you’re on a Mac you can use other tools,” he told me.

More interesting is a forthcoming cloud IDE. “We’ve just revealed a new tool called Icenium which is a cloud-based development environment for creating apps in HTML and JavaScript. It’s an incredible environment for building apps with Kendo UI.”

How about HTML5 apps that target the Windows Runtime (Metro) in Windows 8 – will Kendo UI work there? Apparently not:

“It’s certainly something we’ve paid attention to. Telerik’s primary position for Windows 8 runtime and Windows 8 development is with the traditional .NET targeted tools. Our RAD tools later this year will focus on introducing XAML and HTML tools for Windows Runtime. The HTML tools that we introduce will have a shared engineering core with Kendo UI, but we’ll make a tool that is specifically targeted at that runtime.

“Kendo UI is really focused on the cross-platform, cross-browser experience. You write once, at a core code level, and then use all the runtimes out there for HTML and JavaScript. Whereas Windows Runtime is leveraging familiar technology in HTML and JavaScript, but when you write a Windows Runtime app you are writing Windows software. It’s very platform-specific.”

adobe, javascript, professional, software development, Web

jQuery usage soars as Adobe Flash shows slight decline

A press release from .appendTo, a company which offers jQuery-based services and training, states that “jQuery Overtakes Flash on World’s Top Websites”. I found it a curious claim insofar as jQuery is not really an alternative to Flash, though there is some limited set of graphical effects for which I guess you could use either.

I took a look at the source data from httparchive.org – note that the data at this link changes regularly. I compared the most recent stats, from August 15 2011, to the oldest available, November 15 2010, an interval of nine months. The data is based on the most visited sites based on various lists and seems to amount to between 15,000 and 20,000 URLs.

In November 2010, jQuery was found on 39% of the sites, whereas Flash was on 49%. In August 2011, the stats show jQuery on 48% of sites with Flash on 47%, hence the press release.

Other figures that caught my eye: in web servers, Microsoft IIS has moved from 21% to 20%, apache from 51% to 49%, nginx from 11% to 13%.

Google analytics is the most commonly found script, moving from 61% to 63% of these sites. The amount of data Google receives on internet traffic is remarkable.

The real story here is the ascendancy of jQuery rather than the decline of Flash. If you want your website to work on Apple’s mobile devices as well as on desktop PCs, then Flash is not an option.

Adobe does not make money from the Flash runtime, which is free. It makes money from design tools and server-side services, among other things. Although it is good for Adobe if everyone uses its Flash client, it can still succeed in an HTML 5 world.

Flash has other roles too. Adobe AIR uses the Flash runtime on desktop PCs and some smartphones, and an iOS compiler lets you build Flash apps for Apple’s iPhone and iPad.

There is also some evidence that Adobe is tilting its efforts a little more towards HTML, with products including the preview of Edge which is a motion and interaction design tool for HTML5, CSS and JavaScript.

adobe, development, iphone, mobile, professional, software development

Hands On with RunRev LiveCode: rapid development for iOS, Android, Mac and Windows

3 Comments

RunRev LiveCode is a cross-platform development tool for Mac, Windows, Linux, Web, Apple iOS and, from this month, Google Android.

image

It is an individualistic tool inspired by Apple’s original (but now obsolete) HyperCard and HyperTalk, in which the building blocks of your application are stacks and cards. A stack is like a window, and a card is like a panel overlaid on that window. Unlike HyperCard, LiveCode is not a virtual card stack where each card can represent a record in a database; it is simply a means of building a graphical user interface.

A key attraction of LiveCode is that it now supports the two dominant smartphone platforms. I have been looking at a number of different approaches to mobile development, most recently PhoneGap; how does LiveCode compare to the competition? In order to get some hands on experience I set out to create my simple calculator application in LiveCode.

Coming almost new to LiveCode, I found that building this application took longer than it had done in PhoneGap, which uses HTML and JavaScript. I created a new stack and dragged some buttons onto it easily enough, but found that the approach to coding took some getting used to. There are lots of tutorials, but I found the easiest way to learn was to read through chunks of the user guide [pdf], which does a better job of explaining how to code.

One annoyance is that each object, such as a button, has its own script window, which appears as a tab in the editor. Although my calculator is simple, it does have a fair number of buttons, so you end up constantly switching between tabs. If you amend some code, you have to remember to click Apply before the change takes effect. If you forget, you run the application and puzzle over why it seems to be running an old version. The environment is strongly GUI-centric; you will not like it if you are an enthusiast for Model-View-Controller architecture.

The environment is dynamic, so you can test the stack you are working on at any time simply by switching it to browse mode. This is why it is called Live Code. In this respect it is similar to the Live View in Adobe’s DreamWeaver.

image

I had to get used to writing:

put firstNumber * secondNumber into theResult

instead of

theResult = firstNumber * secondNumber

I was impressed by LiveCode’s ability to change types on the fly and to work out correctly whether you wanted to do something with a string value or a numeric value.

The language is more English-like than most languages, though I am not sure if it really easier. The language minimises use of punctuation which helps readability. Cases in switch statements fall through, C style, unless you remember to include break statements, which is traditionally a common source of bugs.

I got my calculator working on Windows. I tried building for what RunRev calls Web, but was put off by the plug-in requirement:

image 

I then moved the project to a Mac to try it on iOS. Everything still worked, but I spent some time resizing the stack and repositioning the buttons to look half-way reasonable on an iPhone. I may be missing some tricks here, but scaling and positioning controls does not seem to be a strong point for LiveCode.

LiveCode does feel that bit more at home on a Mac, reflecting its origins.

image

I was impressed with how easy it was to build the app for iOS. The way cross-platform works in LiveCode is that you open a dialog called Standalone Application Settings. There is a tab for each supported platform, in which you specify options specific to each platform. The options for iOS are extensive, including supported devices, hardware access requirements, orientation options, external libraries and so on. You can then test immediately on the simulator. For on-device testing, you use the Organizer in Xcode to copy the compiled app across.

image

The good news is that the app ran well, much better than than the PhoneGap/jQuery Mobile version, though it did not look as nice and in fairness the other app’s performance issues are likely more to do with jQuery Mobile than PhoneGap itself.

Although I found it a bit of a hassle getting started, nevertheless I was able to build a working app for Windows, Mac and iOS in a few hours, so I should not complain.

Of course there is a lot more that LiveCode can do. It has database libraries, graphical effects, an embedded web browser on some platforms, XML and text processing support, and more. It is also extensible; there is probably not much that cannot be achieved with sufficient effort.

I have not tried the Android support as my version does not include it; though I did notice that the Android options dialog is basic compared to what is available for iOS.

My first impression of LiveCode is positive, but with reservations. It looks to me like a viable and productive route to cross-platform development, or you might use it just as a quick route to app development for iOS, but I did not enjoy working in the IDE which feels quirky and unsophisticated compared to other modern IDEs. My little app works well though, and that suggests it would be worth trying it for something more advanced.

adobe, mobile, professional, software development, visual studio, Web, web authoring

Native apps better than web apps? That’s silly talk says PhoneGap president

1 Comment

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

.net, development, internet, microsoft, professional, Web

Microsoft remakes WCF for REST and the web

3 Comments

WCF is Windows Communication Foundation, the part of Microsoft’s .NET framework that handles service-oriented architecture. When WCF was first designed Microsoft was betting on SOAP web services. SOAP is still widely used but since then the trend has been towards more web-friendly services based on REST (Representational State Transfer) and JSON (JavaScript Object Notation). Microsoft has always argued that WCF is flexible enough to support such alternatives.

That said, a project which I have become aware of here at QCon London is the WCF Web APIs, presented here by Microsoft’s Glenn Block. WCF Web APIs focus on support for REST, JQuery clients, and programming model simplicity for a variety of other clients such as Silverlight and Windows Phone. The bit that surprised me is that WCF Web APIs are not just another wrapper for WCF; it is a completely new library that does not build on the old WCF Service Model. The fact that it is called WCF at all is confusing, though of course it belongs in that space within the overall .NET Framework.

I have not had time to look in detail at the WCF Web APIs, but from what I have seen and heard they are well worth exploring, even if you have found the old WCF somewhat impenetrable.