4 ms·

The lengths that some JS developers go to avoid writing HTML is unbelievable. JSX is one of those technologies that was clever for what it was, but should have

The lengths that some JS developers go to avoid writing HTML is unbelievable. JSX is one of those technologies that was clever for what it was, but should have never caught on. Adding another layer of abstraction on top of JSX is the type of behavior at the root of the civilizational collapse argument. Just because you can doesn't mean you should.

raincole 2y ago
I don't think it's a very fair criticism. Of all the abstractions over HTML, JSX is the only one that forces you to learn HTML itself. So the reason why JS programmers chose JSX isn't that they refuse to write HTML.
gmueckl 2y ago
Just because you can doesn't mean you should in production. If someone want to build horrific abominations in rheur spare time at home, I won't stop them. They might become better engineers through that experience. But don't come to me suggesting actually using one of these horrors.
wruza 2y ago
Mind you, I’m a former x86 asm and C guy who avoids writing HTML. Web 1 state transfers never made sense to me. It just doesn’t click, I don’t think this way and refuse to do so in the name of not sure what. And while I despise react for its architectural delusions, I still use a js framework to render my webapps. I also don’t see any bloat or something, they all render instantly on both my pc and my phone.
- MonkeyClub 2y ago
  > I also don’t see any bloat or something, they all render instantly on both my pc and my phone. That's because both our phones and computers have multicore CPUs running billions of instructions per second per core. So all the bloat gets executed quickly, and we don't get to notice that it's there. But it's there. And it's dirty.
  - wruza 2y ago
    Due to my "roots" I'm capable of painting a "site" fully myself, given only the windowing API and e.g. pango/cairo (too lazy to reserach into skia) and a few utility libraries. I had actually created a fully working gui framework in the past using only drawing and windowing libs. And I can tell you that a browser is an absolute technological atrocity that is full of binary bloat and practical (as in, not on paper) inefficiencies. An additional layer that generates 2000-or-so {}s per mutating interaction doesn't add much to this. It doesn't add anything at all, unless you're armed with a profiler. "Browsers are fast and efficient" is a fucking lie. Same for HTML. You're looking for bloat in the wrong places. The only reason you don't realize it is because both our phones and computers have multicore CPUs running billions of instructions per second per core. So all the bloat gets executed quickly, and we don't get to notice that it's there. For example, this almost empty, absolutely js-less "Add comment" page I'm writing this comment on takes 50MB (a clean browser run, ALL plugins disabled). That's only the page -- the entire browser takes 450MB. A full-blown gtk-based backup app that I'm using, with numerous screens and layouts, only uses 14MB, and total 35MB after I click through all of its screens, settings, managers, etc. You can't even fathom how much memory it would take if it was browser-based.

raincole 2y ago

I don't think it's a very fair criticism. Of all the abstractions over HTML, JSX is the only one that forces you to learn HTML itself. So the reason why JS programmers chose JSX isn't that they refuse to write HTML.

gmueckl 2y ago

Just because you can doesn't mean you should in production. If someone want to build horrific abominations in rheur spare time at home, I won't stop them. They might become better engineers through that experience. But don't come to me suggesting actually using one of these horrors.

wruza 2y ago

Mind you, I’m a former x86 asm and C guy who avoids writing HTML. Web 1 state transfers never made sense to me. It just doesn’t click, I don’t think this way and refuse to do so in the name of not sure what. And while I despise react for its architectural delusions, I still use a js framework to render my webapps. I also don’t see any bloat or something, they all render instantly on both my pc and my phone.

MonkeyClub 2y ago
> I also don’t see any bloat or something, they all render instantly on both my pc and my phone. That's because both our phones and computers have multicore CPUs running billions of instructions per second per core. So all the bloat gets executed quickly, and we don't get to notice that it's there. But it's there. And it's dirty.
- wruza 2y ago
  Due to my "roots" I'm capable of painting a "site" fully myself, given only the windowing API and e.g. pango/cairo (too lazy to reserach into skia) and a few utility libraries. I had actually created a fully working gui framework in the past using only drawing and windowing libs. And I can tell you that a browser is an absolute technological atrocity that is full of binary bloat and practical (as in, not on paper) inefficiencies. An additional layer that generates 2000-or-so {}s per mutating interaction doesn't add much to this. It doesn't add anything at all, unless you're armed with a profiler. "Browsers are fast and efficient" is a fucking lie. Same for HTML. You're looking for bloat in the wrong places. The only reason you don't realize it is because both our phones and computers have multicore CPUs running billions of instructions per second per core. So all the bloat gets executed quickly, and we don't get to notice that it's there. For example, this almost empty, absolutely js-less "Add comment" page I'm writing this comment on takes 50MB (a clean browser run, ALL plugins disabled). That's only the page -- the entire browser takes 450MB. A full-blown gtk-based backup app that I'm using, with numerous screens and layouts, only uses 14MB, and total 35MB after I click through all of its screens, settings, managers, etc. You can't even fathom how much memory it would take if it was browser-based.