3 ms·

Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too. We

by zwnow 2y ago

Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too. Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVueSolidNextNuxt is not the solution but rather trying to patch up some symptoms... The Web needs true change.

incrudible 2y ago
> The Web needs true change. Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be. I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document platform and embrace it as an application platform. Use an actual programming language instead of adding yet another feature to the Rube Goldberg machine that is HTML+CSS. That's not solving any real problems, it's just making it incrementally less feasible to have multiple browser implementations and anyway it's not like you'll want to use the feature until years down the line when it's gone through the whole standard and adoption phase.
- zwnow 2y ago
  How will you scale your take on this? We are currently facing incredible scaling issues and complexity in web dev because of js based systems. Meanwhile companies that ditch js have great success (whatsapp, discord, ...) Js in the browser is fine, but with node and Nuxt or Next we now have it where it doesn't belong.
  - hajile 2y ago
    The big problem with scaling JS on the server is threading. There's simply no way to do it. You can spin up multiple processes, but then the communication overhead gets you. The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).
fridder 2y ago
Basically we are in this scenario: https://xkcd.com/927/ https://xkcd.com/927/ Honestly though I think WASM might be the final state of the web.
- diggan 2y ago
  > I think WASM might be the final state of the web Oh sweet summer child, we've been close to the "final state of the web" for as long as I've done web development.
- zwnow 2y ago
  I'd be fine with pure HTML Websites, just give me a way to make auth extremely secure. Been ditching js based things outside of work and I'm really enjoying BEAM. It is puzzling to me why companies prefer having 200 microservices orchestrated with Kubernetes if they could have it so much easier by ditching js...
- WorldMaker 2y ago
  WASM makes things worse because now "rewrite it in hip new frontend framework X" has more options. Tired of React? Try Blazor WASM (C#) or any of the exciting new Rust-based front ends or any of the up-and-comers in Swift, Go, Perl, Befunge, Intercal, and other favorite languages or flavors of the month. Dart's not just a thing for people installing Chrome Extensions, now you can use it in WASM almost like Father Google intended when Dart was originally envisioned. Most of these languages can at least use Web Components for some sort of interoperability. At least the ones doing FFI to JS for DOM manipulation. Of course the "new WASM hotness" for "performance" is "do everything in a canvas and avoid the DOM altogether". Every WASM "app" is an opaque VM to itself. Many WASM languages bundle a lot of things the browser already provides (beyond the ones also building their own DOM engines for canvas-based UIs) including things like GC. Maybe future proposals like WASM GC will start to break down the barriers between WASM languages/runtimes, and open up more instances of memory sharing and data structure reuse. Maybe. The flipside is every GC is special and not every language wants a weak version of JS' GC underpinning their memory management. Hopes for real convergence of WASM language runtimes seem very optimistic to me. (Especially in a world where even the JS DOM is being skipped for canvas apps because some languages want that control.) WASM may be the final state of the web in terms of being the diaspora of too many languages running on the web and the true death of the View Source web.

by zwnow 2y ago

incrudible 2y ago

> The Web needs true change. Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be. I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document platform and embrace it as an application platform. Use an actual programming language instead of adding yet another feature to the Rube Goldberg machine that is HTML+CSS. That's not solving any real problems, it's just making it incrementally less feasible to have multiple browser implementations and anyway it's not like you'll want to use the feature until years down the line when it's gone through the whole standard and adoption phase.

zwnow 2y ago
How will you scale your take on this? We are currently facing incredible scaling issues and complexity in web dev because of js based systems. Meanwhile companies that ditch js have great success (whatsapp, discord, ...) Js in the browser is fine, but with node and Nuxt or Next we now have it where it doesn't belong.
- hajile 2y ago
  The big problem with scaling JS on the server is threading. There's simply no way to do it. You can spin up multiple processes, but then the communication overhead gets you. The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).

fridder 2y ago

Basically we are in this scenario: https://xkcd.com/927/ https://xkcd.com/927/ Honestly though I think WASM might be the final state of the web.

diggan 2y ago
> I think WASM might be the final state of the web Oh sweet summer child, we've been close to the "final state of the web" for as long as I've done web development.
zwnow 2y ago
I'd be fine with pure HTML Websites, just give me a way to make auth extremely secure. Been ditching js based things outside of work and I'm really enjoying BEAM. It is puzzling to me why companies prefer having 200 microservices orchestrated with Kubernetes if they could have it so much easier by ditching js...
WorldMaker 2y ago
WASM makes things worse because now "rewrite it in hip new frontend framework X" has more options. Tired of React? Try Blazor WASM (C#) or any of the exciting new Rust-based front ends or any of the up-and-comers in Swift, Go, Perl, Befunge, Intercal, and other favorite languages or flavors of the month. Dart's not just a thing for people installing Chrome Extensions, now you can use it in WASM almost like Father Google intended when Dart was originally envisioned. Most of these languages can at least use Web Components for some sort of interoperability. At least the ones doing FFI to JS for DOM manipulation. Of course the "new WASM hotness" for "performance" is "do everything in a canvas and avoid the DOM altogether". Every WASM "app" is an opaque VM to itself. Many WASM languages bundle a lot of things the browser already provides (beyond the ones also building their own DOM engines for canvas-based UIs) including things like GC. Maybe future proposals like WASM GC will start to break down the barriers between WASM languages/runtimes, and open up more instances of memory sharing and data structure reuse. Maybe. The flipside is every GC is special and not every language wants a weak version of JS' GC underpinning their memory management. Hopes for real convergence of WASM language runtimes seem very optimistic to me. (Especially in a world where even the JS DOM is being skipped for canvas apps because some languages want that control.) WASM may be the final state of the web in terms of being the diaspora of too many languages running on the web and the true death of the View Source web.