4 ms·

20yrs ago we had desktop-style interactivity on the internet? Everyone acts like there was no reason why people started adding Javascript to webpages. Whole sw

by dmix 3y ago

20yrs ago we had desktop-style interactivity on the internet? Everyone acts like there was no reason why people started adding Javascript to webpages. Whole swaths of the entire developer community just fell into because they were dumb. If static pages alone could accomplish what people wanted from the internet they would have figured it out a decade+ ago. 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. Probably because they've never actually used any of these modern high-performance desktop-tier web apps like https://linear.app https://linear.app

JimDabell 3y ago
> 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
colordrops 3y ago
I agree with everything you are saying in this thread, but https://linear.app https://linear.app is one of the slowest websites I've ever encountered. Animation fade-ins before you get to the content, and something heavy is happening which causes scrolling to be at most 3fps.
- dmix 3y ago
  ? What sort of browser are you using? One of those alternative ones?
pjmlp 3y ago
It is exactly the same as doing server side rendering, alongside DHTML and Ajax.
- dmix 3y ago
  Lol.

by dmix 3y ago

JimDabell 3y ago

> 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

colordrops 3y ago

I agree with everything you are saying in this thread, but https://linear.app https://linear.app is one of the slowest websites I've ever encountered. Animation fade-ins before you get to the content, and something heavy is happening which causes scrolling to be at most 3fps.

dmix 3y ago
? What sort of browser are you using? One of those alternative ones?

pjmlp 3y ago

It is exactly the same as doing server side rendering, alongside DHTML and Ajax.

dmix 3y ago
Lol.