If there is one truism in software development it is that there are no silver bullets. There is no "perfect" platform that should be used to tackle every software challenge.
Not anything yet invented.
As long as different software projects have different requirements, there will remain a need for different platforms. And that's a good thing. Choice and competition is healthy in any market, and in the software industry, we consistently see how competing software platforms or applications make the entire industry better (and how the lack of competition is very bad…ahem…IE6).
With the rise of modern mobile devices and on-the-go computing (where active Internet connections are not a guarantee), HTML is being pushed to do more. It's about software development, not web development. It's about building application front-ends that can be delivered over the web in a browser, packaged and delivered through an app store, or even cached and used offline when the Internet is not available.
This has an important impact on HTML development techniques.
For the better part of the last decade, HTML development has depended heavily on interaction with server-side frameworks. Technologies like PHP, Rails, and ASP.NET have helped developers create "HTML applications" where much of the front-end work and HTML rendering still happens on the server.
This approach works, but it is severely limiting when you want to create a "self-contained" application or something that will remain useful when the Internet is not available.
This is a bit of a trick question.
When we transition to say "apps" instead of "sites," now we're talking about "packaged" experiences. Software that can be "installed" (or at least accessed outside of the browser - or maybe in the browser without an Internet connection, in the case of Chrome "Web Apps").
None of these benefits is achievable with server-side HTML development.
With apps, though, you must also consider the native options. Choosing HTML/JS means making a decision between a "universal" reach platform and something that is probably less universal, less "standard," but probably more focused on a rich experience where it is available. For example, maybe you're considering:
Native platforms definitely have advantages, and they're well documented. For the richest experience on a PC, Mac, or mobile device, native platforms are always the winner.
The primary reason to choose HTML/JS over a native platform technology is reach.
If you want to build one app that can target multiple devices and operating systems, HTML/JS is your best choice. It helps you reach the most people with the least amount of duplicated effort. And when combined with tools like PhoneGap (for mobile - new tools for desktop packaging will likely emerge in the near future), HTML/JS apps have nearly all of the benefits of native apps, including:
Before I wrap-up this post, it's worth addressing this common misconception.
Where today you may use server-side technologies to handle much of your front-end UI rendering and behavior, with a pure HTML/JS app or site, the server reduces its role to focusing more exclusively on data. The server continues to play the role of serving application data, persisting data changes, and running business rules against user supplied input (such as login security). All that changes with the HTML/JS shift is a reduction in the role the server plays with the front-end UI.
Security is the same (SSL + server authentication).
Dynamic page templates are the same.
Data persistence is the same.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required