5 ms·

> 20yrs ago we had desktop-style interactivity on the internet? Yes. I believe desktop.com was launched in the late 90s, so well over 20 years ago. https://we

> 20yrs ago we had desktop-style interactivity on the internet? Yes. I believe desktop.com was launched in the late 90s, so well over 20 years ago. https://web.archive.org/web/20021217213351/https://www.internetnews.com/ec-news/article.php/186901 https://web.archive.org/web/20021217213351/https://www.inter... > Now the industry is shifting to delivering the same level of functionality with the bare minimum of JS on-page. Yet people act like it's all the same. It mostly is. Best practice was never to avoid JavaScript, that was just a caricature repeated by bad JavaScript developers. Best practice was to start with a solid foundation that worked for everybody and add on the interactivity as an optional extra. All the best JavaScript developers of the time were writing stuff that was client-side interactive but was still primarily server-driven.

dmix 3y ago
The innovation here is not about just being picky about where you add JS. That was always an option. It's about frontend teams having the tools to build their views in a single cohesive place, in a single structure, without having to make a tradeoff between SSR and client-side rendering. It is automatic and part of the frameworks. This is very important. Take rails for example, modern projects have `/app/views` for ERB templates and `/app/javascript` for the React/Vue views. It's natural for frontend teams to push more and more stuff into `/app/javascript` instead of the static `/app/views`. Because the JS frontend is where the highend-CSS tooling/clean reusable component libraries/high quality UI testing libraries/etc/etc live. Sure you could be extremely careful and divide the two. But in practice it's much harder than it sounds. You're basically running two different frontends. Having the components that compose the views simply be a single SSR (y/n) checkbox is far better AND even when it's not SSR it still renders static in the UI instantly, then hydrates in the background. So no vDOM loading time. We've never had anything like that before for high-functionality JS views. And it goes beyond that too. Linear has made tons of innovation in how data is synced with the UIs + offline support. see: https://replicache.dev/ https://replicache.dev/ <- static HTML offers none of this sort of fully offline cached data performance + realtime syncing UIs

dmix 3y ago

The innovation here is not about just being picky about where you add JS. That was always an option. It's about frontend teams having the tools to build their views in a single cohesive place, in a single structure, without having to make a tradeoff between SSR and client-side rendering. It is automatic and part of the frameworks. This is very important. Take rails for example, modern projects have `/app/views` for ERB templates and `/app/javascript` for the React/Vue views. It's natural for frontend teams to push more and more stuff into `/app/javascript` instead of the static `/app/views`. Because the JS frontend is where the highend-CSS tooling/clean reusable component libraries/high quality UI testing libraries/etc/etc live. Sure you could be extremely careful and divide the two. But in practice it's much harder than it sounds. You're basically running two different frontends. Having the components that compose the views simply be a single SSR (y/n) checkbox is far better AND even when it's not SSR it still renders static in the UI instantly, then hydrates in the background. So no vDOM loading time. We've never had anything like that before for high-functionality JS views. And it goes beyond that too. Linear has made tons of innovation in how data is synced with the UIs + offline support. see: https://replicache.dev/ https://replicache.dev/ <- static HTML offers none of this sort of fully offline cached data performance + realtime syncing UIs