4 ms·

> Have you seen the horrible mess of web development caused by JS platform taking over backend and mb of js files just to write a text to a DOM element? Deno i

by dmix 3y ago

> Have you seen the horrible mess of web development caused by JS platform taking over backend and mb of js files just to write a text to a DOM element? Deno is one of the pioneering projects (via https://fresh.deno.dev/ https://fresh.deno.dev/) pushing SSR to the maximum so we don't need MBs to render DOM elements... unless you know, you want any sort of interactivity which every single client-facing SaaS app ends up needing (for which hydrated 'islands' are used only when necessary). Unless you remove the need for desktop-style interactivity on the internet JS is never going away. Maybe WASM will help here (w/ even worse Web standards), but I could reverse your same critique and point at all the horror-show UIs backend devs have built using backend-style code. I don't personally use JS server-side but I get why people do and it's not the language/runtimes making apps slow. Backend JS adoption is heavily informed by the dominance of JS on the client side, ease of hiring, and an effort to keep data structures DRY. > Enough of OOP that has horrible. OOP is not a requirement in JS and I rarely see it being used heavily these days. Nothing like Java or some awful Ruby projects I've seen.

pjmlp 3y ago
Pionering as in, rediscovering how we used to serve pages 20 years ago?
- 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
- balls187 3y ago
  I recently picked up Svelte and Sveltekit, and when discussing `+page.server.js` files, I usually say they're "code-behind from the old days."

by dmix 3y ago

pjmlp 3y ago

Pionering as in, rediscovering how we used to serve pages 20 years ago?

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
balls187 3y ago
I recently picked up Svelte and Sveltekit, and when discussing `+page.server.js` files, I usually say they're "code-behind from the old days."