Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better.<p>I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Is the modern JS based design our cubicle moment? Did we get suckered in by experts making productivity claims with nothing to back them up?
> 45% of mobile connections occur over 2G worldwide
> 75% of of connections occur on either 2G or 3G<p>this is so important. if you want growth you need to be making a product for growing markets.
Meanwhile, HN loads like a charm and time to interactive seems to be less than 0.5s<p>Seems like that's what happens when you are too deep in the js bog, and you forget what is below the thick js cover
Front-end developers could solve all of this by just learning the base technologies of HTML, HTTP, CSS, and JS really well and ignoring everything else.<p>We're at a beautiful point in web development where browsers are finally unified on open standards, and we're all too locked into these outdated JS frameworks to take advantage of it.
It's nice of you to make your web presence work for someone with 400Kbps link with a 400ms round-trip-time (“RTT”), while you're at it, also make sure it works with JavaScript turned off! And browsers with limited CSS support. And is readable on a terminal browser. And 600x400 px resolution.
It's remarkable how much js gets loaded onto a page (mainly due to libraries) vs. how much of its functions are needed for what the web developer is trying to do. There just is not a whole lot of use cases for the big libraries unless you're doing something really intensive like a drawing app.
His argument is based on an example where he puts JS in <head>, when it's been a recommendation for ages to put JS at the very end of <body>.
I'm sure there are niches out there where complex web apps are best built without an SPA framework, but use the right tool for the job! If I'm writing an embedded interrupt routine, I don't use slow clunky C, I use assembly. If I'm writing a complex web application, I use an SPA framework like Vue. If I'm delivering static content, I use minified html and css.<p>Everything comes with a tradeoff. If you pick the wrong tool, it's a big headache.<p>Learn to use all the tools.
Most of the requirements for Google's AMP project help bring down TTI by a large margin if you follow them as well.<p><a href="https://www.ampproject.org/docs/tutorials/create" rel="nofollow">https://www.ampproject.org/docs/tutorials/create</a>
I think the article makes some valid points, but it's important to remember that PWAs are just getting going. The existing SPA frameworks are still a little crude at the moment, but there is definite progress. For my own app (<a href="https://usebx.com" rel="nofollow">https://usebx.com</a>), I eventually ended up writing my own front end framework, as existing frameworks at the time felt rather bloated. Now, however, things are starting to look better with the likes of Vue.js etc coming on the scene. I also feel that PWA development will explode once Apple ships service workers with Safari, and that will bring along with it even more motivation to innovate in this space.
Actually, I think it is more important to be aware of the issues and handle them than to set strict size limits. For example, a few years ago I lead a redesign project for a mobile web shop and the designer told me he was not allowed to include icons as our CIO had set the limit of the page size to 100k (including all images).<p>By the end of the project the page size was about 200k, but when the sales were ~20% higher (multi million $ shop) nobody asked about the size limit anymore.<p>So yeah, page size/load time is important, but please keep reflecting what you are doing. The best load times are no good, if (as a result) the UX is poor.
It's also funny how many of my friends use $TrendyJSFramework for a portfolio site! Personally prefer to have all my content statically served unless I'm building some sort of an interactive single page application.<p>I run <a href="https://discoverdev.io" rel="nofollow">https://discoverdev.io</a> for which I wrote my own SSG framework in python+jinja, I spit out html and push it to netlify's CDN network. It's smooth, I don't have to worry about scaling and it works like a charm! (I could still do a lot of optimisation wrt image compression and minification though)
Just pushed live an app today that I had to cave and add babylon-polyfill so it would work in IE 11 after trying to polyfill a dozen missing es6 runtime features from various sources.<p>That made the final JS output 25% larger, a 90kb increase from the polyfill library alone, so here's a serious optimization waiting to happen (the natural dying of an older browser).
How come no one monitors their speed as much as they should?<p>SpeedCurve and Calibre are great options listed in that article. Also suggest MachMetrics <a href="https://www.machmetrics.com/" rel="nofollow">https://www.machmetrics.com/</a>
i cut my personal site's TTI by 62% after reading this. I just was lazy about performance when there were some real easy wins. i do wish for more guidance on how to do PRPL in React (without necessarily doing full Next.js which is too opinionated for some of the stuff I want to do)