4 ms·

I thought about it briefly before about this issue I posted. If you target Chromium, Firefox, Safari you hit close to 95% of the web traffic. It is one of the "

I thought about it briefly before about this issue I posted. If you target Chromium, Firefox, Safari you hit close to 95% of the web traffic. It is one of the "pros" of a oligopoly in the browser space. I would reckon most websites would be okay with this reach. Just a guess.

solardev 3y ago
I think the main thing here is that it isn't just Javascript that would need to be replaced. Honestly, the entire web stack isn't great: HTTP, HTML, CSS and JS were all designed in an era where websites were documents viewed on desktop computers, not responsive interactive apps that can replace everything from email to Photoshop. A truly clean and modern solution might look something more like the native platforms, or one of Microsoft's failed next-gen Windows frameworks. But to get something like that on the web, we'd end up with a completely new, separate system anyway, so might as well just use the app stores for that. There have been some attempts in at least offloading large parts of that to WASM, similar to how Figma does it, but they still use some JS and HTML too. I guess the ongoing advantage of the web is that it runs everywhere, on everything, even if the devex isn't great and the UX isn't native-like. Every time people tried to drastically "improve" the web by introducing a totally new paradigm, it has to compete against the inertia of not just browsers but also existing developers trained on HTML/CSS/JS and entrenched metalanguages like React. It's a really saturated space, users by and large don't care as long as the final product somewhat works, and whatever solution we come up with here is unlikely to beat native mobile apps anyway, so why not just go straight to that if that's the intent...? It's a lot of effort for not a lot of gain. What I do wish is that the major browser and OS vendors would get together and just drastically improve Javascript itself, adding a built-in type system, a better standard library, a standard API across browser/server/serverless/anything else, a well-designed web component system, package managing, etc., then compete on performance and support etc.
- bruce511 3y ago
  >> Honestly, the entire web stack isn't great: HTTP, HTML, CSS and JS were all designed in an era where websites were documents viewed on desktop computers, not responsive interactive apps that can replace everything from email to Photoshop. We've had and discarded, that already. Flash was a different platform, much more powerful, better UI, very good response times, and so on. It was supported in every browser. Building a Flash app was common, done a lot, and well paid. But there were unexpected consequences. Flash apps were not searchable, or deep-linkable. (It turns out, that's a big deal). Their UI was "fixed". You might not love CSS but it's amazing when it comes time to refresh the look of a site. Accessibility for less-than-perfect-ableness was non existent. HTML has accessibility front and centre. Screen Readers, zooming etc. Maintainence sucked. Change the source, recompile, redeploy. Whereas HTML, CSS and JavaScript are all source that can be edited on the fly, on the server. Sure, you're not doing that on big production servers, but for the long, long, tail of small sites, it makes maintainence a lot easier. Learning is harder. To learn Flash I have to learn Flash. To learn CSS,if I see something I like, I can inspect it to see how it's done. (Oh, line-spacing, good to know you, I like what I see you doing.) HTML is easier to scrape, and automate. That may be good, or bad depending on your perspective, but there's no shortage of "we integrate with x" (where x has no API) by "driving" the web site externally. So yeah, I can see the value in talking about JavaScript, but the benefits of HTML and CSS are well understood. We tried replacing them. It didn't go well. (I've avoided talking about the security nightmare that adding a Flash, ActiveX, Java Applet, caused. Or CPU usage. Those are issues with implementation, not the concept. But for those who weren't around, it ultimately killed all of them.)

solardev 3y ago

I think the main thing here is that it isn't just Javascript that would need to be replaced. Honestly, the entire web stack isn't great: HTTP, HTML, CSS and JS were all designed in an era where websites were documents viewed on desktop computers, not responsive interactive apps that can replace everything from email to Photoshop. A truly clean and modern solution might look something more like the native platforms, or one of Microsoft's failed next-gen Windows frameworks. But to get something like that on the web, we'd end up with a completely new, separate system anyway, so might as well just use the app stores for that. There have been some attempts in at least offloading large parts of that to WASM, similar to how Figma does it, but they still use some JS and HTML too. I guess the ongoing advantage of the web is that it runs everywhere, on everything, even if the devex isn't great and the UX isn't native-like. Every time people tried to drastically "improve" the web by introducing a totally new paradigm, it has to compete against the inertia of not just browsers but also existing developers trained on HTML/CSS/JS and entrenched metalanguages like React. It's a really saturated space, users by and large don't care as long as the final product somewhat works, and whatever solution we come up with here is unlikely to beat native mobile apps anyway, so why not just go straight to that if that's the intent...? It's a lot of effort for not a lot of gain. What I do wish is that the major browser and OS vendors would get together and just drastically improve Javascript itself, adding a built-in type system, a better standard library, a standard API across browser/server/serverless/anything else, a well-designed web component system, package managing, etc., then compete on performance and support etc.

bruce511 3y ago
>> Honestly, the entire web stack isn't great: HTTP, HTML, CSS and JS were all designed in an era where websites were documents viewed on desktop computers, not responsive interactive apps that can replace everything from email to Photoshop. We've had and discarded, that already. Flash was a different platform, much more powerful, better UI, very good response times, and so on. It was supported in every browser. Building a Flash app was common, done a lot, and well paid. But there were unexpected consequences. Flash apps were not searchable, or deep-linkable. (It turns out, that's a big deal). Their UI was "fixed". You might not love CSS but it's amazing when it comes time to refresh the look of a site. Accessibility for less-than-perfect-ableness was non existent. HTML has accessibility front and centre. Screen Readers, zooming etc. Maintainence sucked. Change the source, recompile, redeploy. Whereas HTML, CSS and JavaScript are all source that can be edited on the fly, on the server. Sure, you're not doing that on big production servers, but for the long, long, tail of small sites, it makes maintainence a lot easier. Learning is harder. To learn Flash I have to learn Flash. To learn CSS,if I see something I like, I can inspect it to see how it's done. (Oh, line-spacing, good to know you, I like what I see you doing.) HTML is easier to scrape, and automate. That may be good, or bad depending on your perspective, but there's no shortage of "we integrate with x" (where x has no API) by "driving" the web site externally. So yeah, I can see the value in talking about JavaScript, but the benefits of HTML and CSS are well understood. We tried replacing them. It didn't go well. (I've avoided talking about the security nightmare that adding a Flash, ActiveX, Java Applet, caused. Or CPU usage. Those are issues with implementation, not the concept. But for those who weren't around, it ultimately killed all of them.)