> They think that React is itself what browsers render
My kingdom for native JSX in the browser. That would be awesome.
Something similar to how we have WebGL and Canvas, but for pure JavaScript UI without the extra step of DOM reconciliation.
There’s a small (and growing) cohort of people working on rendering React Native directly on canvas or webgl (I think). Supposedly gives you super smooth UX, but I haven’t knowingly tried it yet.
> rendering React Native directly on canvas or webgl
I just threw up in my mouth a little. I can’t wait to:
- not be able to double click to highlight text a word at a time, because the developers of the “super smooth UX” didn’t know that’s what typical text does.
- or triple click to highlight a paragraph at a time
- or have the standard menu available when I highlight text (which I often use to look up words, etc)
- or have text editing support any of my OS’s key bindings, like ctrl-left to move the caret one word, ctrl-shift left to highlight in the process, etc etc
- or any one of the hundreds upon hundreds of common control behaviors, accessibility behaviors, system-wide settings on text behaviors, etc etc etc be respected
Of course if they’re anything like the Flutter folks, they’ll look at every one of these things and say “well, I guess we gotta implement all that” rather than understanding the basic fact that common UI elements offered by the OS should actually be reused, not reimplemented poorly.
I really worry about what software will look like 20 years from now. At this rate we’re just going to forget every thing we learned about how it should behave.
I think typical front end developers (or the managers they report to) don't really know what smooth UX is. They keep reinventing things like scrolling.
There's almost no HCI or interaction design in what passes for UX today. They are mostly - probably 90+% of them - visual designers who have memorized some canned responses to use when asked why they aren't doing basic things.
Seriously, anyone who things software as a discipline is bad, well, they're right, but they have no appreciation for how appalling "UX" is today vs even 1990.
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 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.
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.
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.
> 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.
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.
oh no. At this point, we just need something that doesn't use the stupid combo of two languages(one markup and one style sheet) for UI and one(totally single threaded) for UX that allows people to share and view simple text and media to one another. Maybe then we can rid ourselves from constraints like having to stick to JS or a Virtual Machine like V8 while settling on poor implementations like WebGL and Canvas. WebGPU is still not a thing and it probably won't be anytime soon.
A new web browser or another JS runtime won't be the solution to the current mayhem. What could actually be helpful is an alternative to the "web browser" that operates on an entirely different stack than the currently JIT overdosed JS engines. But since everybody is well accustomed to and excited about improvements within the current madness(like this comment), adaptation of any alternative web browser like software will be highly unlikely even if it were several folds better at transferring media and rendering graphics with a much simpler approach and high performance. We are officially fo*ked.
My kingdom for native JSX in the browser. That would be awesome.
Something similar to how we have WebGL and Canvas, but for pure JavaScript UI without the extra step of DOM reconciliation.
There’s a small (and growing) cohort of people working on rendering React Native directly on canvas or webgl (I think). Supposedly gives you super smooth UX, but I haven’t knowingly tried it yet.