341–350 of 756 posts
The only sure cure for the JavaScript blues is WebAssembly. Use something like Leptos and be happy: https://www.leptos.dev/
The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…
"A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture because of performance concerns. In practice, the baseline performance is often faster than they expect, and it can be made much, much faster using strategies like memoisation and fine-grained reactivity.
Earlier quoted context omitted.
I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…
Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization…
Modern CSS is amazing. Why on earth would anyone use SCSS? It pays to look at what Vanilla can do these days.
> Even a "thin" layer of JS on top requires some degree of dependency management
Use modules and import away. If it is truly a thing layer, there's no need for further optimisation until far along in the product.
I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
When you use an operating system, you don't see the millions of lines of code that go into scheduling/kernel, drivers, etc.
Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…
Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…
Something not JS, or even TS. So it has to compile to JS or WASM or both.
Rust is cool. Dioxus looks really promising. https://dioxuslabs.com/
Elm is great. Actually quite mature in my experience. (Sure there are talks about the development model and release cadence, but still...)
Same $LANG as on the backend, as many langs compile to JS and/or WASM nowadays. But then how do you feed the browser a DOM? You still need something: HTMX, or... React?
And if you squint your eyes, isn't Elm also doing the DOM-feeding in a React-like manner? (I dont know for Dioxus).
Possibly the idea of React is really good, just Elm has implemented nicer? (and provides a good story for how to structure the rest of the application: state-mgmt, API calling, etc.
Earlier quoted context omitted.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…
These disagreements almost always boil down to one side saying "some people use React to build content-oriented websites" and the other side saying "but most of us are building web applications". In a typical web application use case (yes, there are exceptions) you're only rarely looking at usage from old or cheap Android devices. Occasionally you'll see a tablet, but even that's rare. The vast majority of the time y…
I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such). That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.
Earlier quoted context omitted.
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…
>Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. that was the case in 2015 when entry level android devices were quite slow, nowdays a cheap $200 android phone has at least 4-6GB of RAM and an eight core processor. if that isn't enough for your react powered site, you are doing something very wr…