Don't compare JS (or any language) to any other language - or any language to another language. People wrote a lot about it (Your language sucks because... - type things). JS is just another language.
The JS ecosystem is wild and moving way too fast, but even that is not really the trouble with it: it's that it's being overused.
He mentions DHTML at the beginning, which was the perfect example of using too much of something: mouse trailing bouncy balls with falling snow, my, I don't really miss those days.
Yet we're here in 2017 and React & Co. is crippling the web. Plain simple news or a blog site rendering with JS? AMP, loading megabytes of Javascript, claiming to speed up the web? When your product is text, how about you serve text and maybe only boost it or do analytics with JS? I know it's not fancy, but for a lot of sites out there, JS based rendering is completely unneeded.
In case of web apps... A little while ago I listened to a talk of front end colleagues, claiming that we'll speed up the site by async calling some blocks, so the initial content will get down fast and the less important ones will follow. When I asked if we're measuring the very end render time - the one that heats the CPUs, because you offload the rendering to the client, which can get quite stressful - the answer was 'no', mostly because nobody knows how to do it. I also asked about how screenreaders will work with this, and they thought I'm talking about mobile, which is extremely sad, and no, I'm unaware of any screenreader-friendly JS based app. (Screenreaders are the programs literally reading out the text for visually impaired.)
Google and FB offers fallback, HTML-only solutions to their services, because the realised their things don't work on slow connections and/or slow devices. Maybe this should be taken as a sign.
- The paradigm shift in writing interactive web pages in the React "write your app like a game that re-renders every frame"-style is extremely compelling. You are correct that there are plenty of largely static sites that do not need JS-based rendering, but for people wanting to develop single-page web apps or other interactive content, that mindset is a godsend.
- We recently re-wrote an ecommerce site with React and it is WCAG 2.0 AA compliant. To our knowledge, and to the independent firms that have audited our application, screenreaders have no problem with it. You still have to go through the diligence of all of the standard a11y-friendly techniques like semantic markup and thoughtful keyboard navigation, but React at least does not get in the way.
Another compelling use-case of React is the ability to use it as a better templating language ― treating HTML as a data structure instead of a string, better composability of the units of your UI, and the ease of rendering to a string.
It's an interesting question whether the tendency to overcomplicate a largely static site by implementing it as a single-page app should be attributed to the average developer or to the creators of the library though.
They are blaming the carpenter. They're saying the carpenter is using a dovetail when they sometimes only need a butt joint. Of course there are cases when a butt joint is stupid, but using a dovetail everywhere is also stupid.
The JS ecosystem is wild and moving way too fast, but even that is not really the trouble with it: it's that it's being overused.
He mentions DHTML at the beginning, which was the perfect example of using too much of something: mouse trailing bouncy balls with falling snow, my, I don't really miss those days.
Yet we're here in 2017 and React & Co. is crippling the web. Plain simple news or a blog site rendering with JS? AMP, loading megabytes of Javascript, claiming to speed up the web? When your product is text, how about you serve text and maybe only boost it or do analytics with JS? I know it's not fancy, but for a lot of sites out there, JS based rendering is completely unneeded.
In case of web apps... A little while ago I listened to a talk of front end colleagues, claiming that we'll speed up the site by async calling some blocks, so the initial content will get down fast and the less important ones will follow. When I asked if we're measuring the very end render time - the one that heats the CPUs, because you offload the rendering to the client, which can get quite stressful - the answer was 'no', mostly because nobody knows how to do it. I also asked about how screenreaders will work with this, and they thought I'm talking about mobile, which is extremely sad, and no, I'm unaware of any screenreader-friendly JS based app. (Screenreaders are the programs literally reading out the text for visually impaired.)
Google and FB offers fallback, HTML-only solutions to their services, because the realised their things don't work on slow connections and/or slow devices. Maybe this should be taken as a sign.