BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Web vs. Desktop Apps: “Never Bet Against the Open Web”

Web vs. Desktop Apps: “Never Bet Against the Open Web”

This item in japanese

Bookmarks

HTML5 and EcmaScript 5, provide very powerful APIs that blur the line between the Web and the Desktop user experience. This has resulted in more organizations choosing to build their applications using Web technologies, rather than using the traditional Desktop approach. In order to explore the evolution of this trend, InfoQ had an interview with Dylan Schieman, CEO of SitePen and co-creator of the Dojo Toolkit, about the potential of the Web platform.

InfoQ: Hi Dylan, would you like to give us an overview of the technologies you consider being part of the Web platform? Where exactly does the Dojo toolkit fit in?

Dylan: Hi Dio, thanks for reaching out to us! The web platform has grown immensely in capabilities and features in the past couple of years, in an effort to basically compete with everything you need to build an application. From the foundation of HTML(5), CSS(3), JavaScript, vector graphics (Canvas and SVG), WebSockets/Comet, Local Storage/Offline, Data, WebGL, and so much more, it's a bit daunting at times, especially when factoring in performance and the diversity of platforms on the web today, from browsers to mobile devices to many other platforms.

Dojo still has many of the same goals today as when it started: to fill gaps in browser implementations, to make developers more productive, and to help you build efficient and well engineered web apps. That has evolved over the years, to cover all of the features above, and so much more. We've evolved to provide a collection of tools to efficiently manage CommonJS AMD packages, to a lean set of packages on top of this. We've just made so many improvements and changes with 1.6, and have a pretty incredible set of plans for 2011. It's by far the most ambitious year in our history.

InfoQ: How do you see these technologies currently being implemented and supported? What important APIs are already available and for what new technologies should we be waiting for?

Dylan: The promise of HTML5 has unfortunately left us with even greater gaps in features and capabilities than before, and mobile has left us with a fragmented landscape of features and capabilities. What's interesting is how the perception is changing from using only the things that have been standardized, to using whatever is available on the platforms you're targeting. For example, if you have WebGL or native hardware acceleration, you cannot use it fast enough, but you still need the ability to support platforms that do not. So we're seeing an incredible number of small toolkits that just help you handle a couple of key problems. For example, geolocation, it seems easy enough on the surface, but the APIs are inconsistent, and it's still nice to be able to fallback on something like Google's IP-based API as a backup plan. We're pretty excited about IndexedDB, and while it's not widely supported in browsers yet, we've leveraged the same concepts for the entire approach to the Dojo Store in Dojo 1.6 for loading data in a simple manner, and connecting data to widgets or templates, as well as implementing this approach on the JavaScript server-side with projects like Persevere. It's just amazing how far we've come, and how fast people are running.

For example, Game Closure is the latest JavaScript and HTML5 game engine, with this one focused on real-time Comet/WebSockets as the basis for how it works. To say "the latest" even a year ago would have been difficult to do while keeping a straight face, and now its expected that of course the browsers, both desktop and mobile, are up to the task for being viable gaming platforms!

InfoQ: What are the main benefits you believe that the web platform has over the traditional desktop technologies?

Dylan: One set of approachable development tools that can be adapted to work in many places. Quite simply, JavaScript, HTML, and CSS are approachable to a larger body of developers, and can work just about anywhere now. Furthermore, you have the promise not of write once, run anywhere, but that you can really get the zen of JavaScript and then be productive everywhere. It's a more realistic goal, and one that we're seeing take off with Node.js on the server-side, the mobile web, the interest in HTML5, and much more. So I see the main advantages being developer efficiency and productivity, and ubiquity. As well as the historical advantages of distribution and ease of browsing to a URL. And now, if you want to create an installable app, desktop or mobile, there are many tools that let you do that as well by wrapping your web app.

InfoQ: What types of application do you see more fitting for being implemented with web technologies and which technologies are those? How can the Dojo toolkit be used with those?

Dylan: I used to say "everything that's not a game with intense graphics, or something with lots of business logic." Now, I'm not sure there's anything that is not possible to do with the web. Dojo helps with anything where you're writing applications with JavaScript as the fundamental programming language. Common use cases of Dojo are communications suites (email, calendaring, etc.), real-time apps, vector graphics intensive programs (real-time whiteboarding, drawing, charting, etc.), enterprise apps, mobile apps. I've seen examples of games built with Dojo. Nothing really surprises me any more.

InfoQ: With JavaScript being a cornerstone for web technologies, how good do you think it compares to other desktop languages like C/C++, Java, etc? What is your opinion about the current frameworks and tooling that is currently available?

Dylan: As excited as I've been to this point, it's still very difficult to stay up with the rate of change, to test as easily as you can in traditional environments, etc. As Alex recently said, what's most frustrating is that the things we struggled with 5 years ago are in many ways the same things we struggle with today. As far as programming languages, JavaScript has been aggressively fixing the syntactical issues that have been the subject of criticism for more than a decade, and for probably the first time, serious involvement of not just browser vendors, but also people who build web apps. JavaScript as a language is extremely flexible and dynamic, and ubiquitous, which is why it's #winning. Whether it's actually a better language or not isn't really the point. Frameworks, toolkits, and tooling are evolving more rapidly than ever. If you have ignored JS for a couple of years, it's time to spend a few weeks and look again, you'll be shocked at how much has changed.

InfoQ: What do you think will be the main concerns for developers that would like to develop desktop solutions using web technologies? What about security?

Dylan: Most security problems today are still within the browser or server-side, as the assumption is that we don't trust web apps to be allowed to do too much. I've been reasonably amazed at how few major security issues have occurred over the years, and most of them were quickly squelched. I don't perceive the web platform as any less secure than the desktop platform, as I think it has less vectors for infection. That said, the breakthrough speed with recent advancements certainly opens the doors for a new class of potential problems.

InfoQ: Are there things that you think are currently missing from Web technologies, in order to be a viable alternative to current desktop solutions?

Dylan: I think if everything that's currently unfinished was suddenly done and highly performant, we'd still have work to do, but the discussion wouldn't be very interesting. I think the main focus has to be on how we can continue to rapidly evolve as we have been, and make it much easier to create applications with amazing performance. So I see it more a matter of polishing and finishing the many alpha and beta quality features and approaches that have emerged over the past 5 years as the main thing holding us back currently.

InfoQ: How do you see these APIs and technologies growing in the near future?

Dylan: I'm terrible at predicting the future, other than I recommend never betting against the open web in the medium and long term. I see them growing rapidly and being fiercely competitive to provide developers with exactly what they need to be amazingly productive on the web.

You can find more information about HTML5, JavaScript and Dojo, right here at InfoQ!

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Is that so?

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In a world that is always connected (3G/4G) where people bring their clients with them (smart phones, tablets, lighter-than-air notebooks), why would one want to use a Web based client? It has been proven over and over that when people have a choice, they use native apps over web apps, 99% of the time.

    That would be a bet that's very hard to win. if you combine security models and in-app purchases (i.e. pay for content), I don't see what's left of the Web moving forward. HTTP? Even HTTP will be quickly replaced within 2 or so years, for a much more efficient protocol geared towards supporting native apps.

  • Re: Is that so?

    by Richard Clayton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think the same was said about HTML/JavaScript when Java Applets and Flash first came out, yet we see a new generation of web technologies in the HTML 5 specification. I think it is highly unlikely that native applications will replace HTML/JavaScript/CSS in 10 years, and even less likely that HTTP will be replaced. The problem with native apps is that they are just that: native! No cross-platform technology is poised to dominate the desktop market in the next 3 years. Web development is the only solution that makes sense if you want to target as many users as possible.

  • Re: Is that so?

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Web apps had an obvious advantage 10 years ago, again with people bringing their client with them, I don't see any advantage left. People want speed and ease of use, nothing a web app can offer, it is clunky (still 10 years later, most apps can't deal with the back-button well or double submit).

  • Re: Is that so?

    by Robert Dean,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Native apps had an obvious advantage 10 years ago, when people didn't have clients that conformed enough to web standards or that were performant enough to make real apps. There isn't any advantage left to "native". It is expensive if you don't want to block out significant chunks of the mobile user community.

  • Re: Is that so?

    by Panthera Leo,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would say the opposite is true. With modern Web UI toolkits like Dojo, Ext JS, and SmartClient, the browser provides a better user experience than most desktop apps do, and they are also easier to develop with. For example, it's easier to implement drag and drop in Dojo, than it is in Swing. Adding a rich text editor to your Web app in Dojo is one or two lines of code. Things are not so easy in most desktop toolkits.

    And of course, given that AJAX calls are asynchronous, that also means you don't have to deal with multi-threading and worry about locking up the UI with a network operation that takes to long if you don't put it in a separate thread.

    From both an end user usability perspective and a developer productivity perspective, I think modern Web toolkits have the advantage over desktop toolkits.

  • Re: Is that so?

    by Mike Hansford,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'd hardly say that more organisations are choosing to use web based apps now that we have better toolkits. IT shops have been choosing web based apps for years principally because there's less trouble deploying them than with smart / rich clients and its easier to write a web app than a smart / rich client app. The users of these apps have been wearing the lousy UX ever since.

    As for modern web UI toolkits being superior to desktop apps, as Panthera mentions, if the comparison is being made to WinForms or GTK or such, then you're talking about a generational gap - it's an irrelevant comparison. Try comparing a web toolkit to a WPF or Air app or a similar, current generation desktop toolkit.

  • Feeling like a fart in a bubblebath

    by Nicolaas Kotze,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Reading these posts makes me very worried. I am a software tester and have been programming every now and then since the days of GWBasic, QBasic and Turbo Pascal.

    What worries me is no one is standing back to look at what a mess the industry is at the moment. Organisations want to make a profit, developers want the latest gadgets, and the testers and users just want something that works and will still work after a update.

    Both web and desktop have their place. Personally I prefer desktop because losing signal and paying crazy amounts of subscription fees for data bundles in 3rd world countries is quite frustrating. Desktop also have its fair share of frustrations such as threading, background applications interfering and security settings in organisations. All websites that do allow users to input information should cater for a API allowing desktop applications to interact as well.

    My wish is that people start looking at the basics and that it'ss quickly testable(that include compatibility with test automation tools) instead of overwhelming fancy feature rich interfaces. This way, organisations get a quick ROI, develepors don't have to work endlessly on the same project, and testers can bother the developers less with issues and suggestions as well as actually achieve the desired test coverage with confidence. The only problem is what do we do with the support center staff(if they are not replaced by a electronic answer machine yet)?

  • HTML is the juggernaut of our time

    by Dominique De Vito,

    Your message is awaiting moderation. Thank you for participating in the discussion.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT