It was true, a fair number of users (2010 Yahoo research states around 2%) were still using a browser that was not compliant with the ECMAScript norm or not implementing it at all. In the case of an online store, if it was to lose 2% of its users, that could mean losing 2% of its profit, which was not imaginable. Not to mention that Google’s web crawlers were not able to parse a page whom content was generated and/or inserted through JS.
The wonders of progress never cease
-Other engines had to adapt and compete
-V8 is licensed under BSD which is open-source, making it available into various project
There we were, we finally had a environment allowing us, developers, to write competitive JS code and so as it became more and more performant, we noticed numerous libraries and frameworks making use of it.
The strength of Node.JS is its asynchronous I/O, event driven architecture. Using only one thread (1 core), all input/output operations are made without blocking. If Node has to perform a filesystem or database call for one request and it’s hanging, it will jump to the execution of the next request and come back later for the first one, therefore not blocking the thread on the first request. This is the asynchronous property of Node. This is perfect in such use case where all we need is read/write from a database/filesystem and serve data without performing much computation.
On the other hand, it is still possible to block this one and only thread by running a CPU intensive task. Reason why it is commonly said Node.JS cannot be used as a web server along with heavy algorithms . This problem is probably the main one Node developers are working on and some solutions are being proposed. Like having a thread pool the node platform can choose to use. This is still fairly young but I am confident node will get there one day.
Meteor is an open-source JS web framework that aims to produce real time client server application. It depends on node server side, and jQuery client side. It is cross-platform and can produce Android and iOS executable.
Another Framework, Reaction, built on top of Meteor, even proposes an e-commerce solution. Yes, someone finally made it : an online store solution turning their back on users with JS disabled. Well at least until Meteor support server-side rendering, in other words generating pure html/css from the server. Bang! JS mandatory and accessibility secondary, Is progressive enhancement dead? Or Should we call it reverse Progressive enhancement!
Conclusion : Is progressive enhancement dead?
As much as I enjoy the possibilities of a “refresh-free” web user experience. Progressive enhancement still make sense in the case of a public government website because it needs to be accessible. But If you need something as simple as using Google maps you need JS enabled.
For example, with JS disabled:
-Gmail proposes a pure HTML/CSS version but it does not contain the same set of features
-Twitter seems to work until you want to tweet …
-Facebook redirects to a version containing the most basic features like displaying 3 posts per page.
Practice are changing, businesses are more and more inclined to leave users with JS disabled. In 2010, a study from Tobyho, testing 19 of the most popular websites, shows :
16% of sites that are broken let their users know that the site is broken
A more recent study from the UK government, reports numbers between 0.2% and 1.1% with JS not working. The author attribute this to the growth in the use of mobile devices, shipped with modern JS-able browsers.
Uniting skill-sets, having just one language for different layers of development is definitely appealing. Back-end and front-end teams could blend. Companies could profit from a more flexible and heterogenous workforce.