141–150 of 351 posts
It also highlights how far browser have come with new features such as dialogs, which I always implemented with (a lot of) JavaScript in the past
Earlier quoted context omitted.
I also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase. The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?
The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc. IIRC React itself doesn’t even know anything about the Web or DOM, as that integratio…
I'd put the blame on React and poor Web APIs in this case. Both are way too complicated for mere mortals to understand fully, and even simplest things like maintaining 100% container height through nested elements, can become a ridiculous time-sink for something completely unrelated to what is your main objective.
Ok, I'll bite. I've been coding for almost 25 years so have seen various things come and go, so hopefully have a bit of capital in the bank. Don't get me wrong, a HTML5 radio button is a beautiful thing, and sometimes React is a hammer and everything is a nail. However, I think something that OP doesn't mention super explicitly in their post is the codebase they are working on is probably a React codebase. React is a…
I'm sure you'll agree that React is overkill for some applications and, for the sake of this discussion, I'll agree that it's beneficial for applications beyond a certain complexity.
But where exactly (or even, roughly) does that line lie? A basic CRUD app? Surely not. A calculator? I'm guessing "no". Bluesky? Maybe/probably.
Earlier quoted context omitted.
The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc. IIRC React itself doesn’t even know anything about the Web or DOM, as that integratio…
Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.
> math tools or pdf generation
In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web. We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift. So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is). If we could just agree on adding non-te…
... beyond a specific size. This important distinction might transform "anybody" into "10%" or "5%" or "0.001%"—who knows, I'm still trying to figure this out!
What is it about multiselect or radio buttons that you feel is lacking in the current Web platform?
Earlier quoted context omitted.
It was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better
I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches. I’d rather have a honest framework than a chimera. I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex…
I think a lot of the time React appears complex and hacky is because we tried to solve world hunger with one component. I've worked on plenty of React projects that were very easy to scale, modify and iterate because they focused so heavily on small independent stateless components.
I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively in that abstraction. Unlike other abstractions where things get tidied up and more simple, React is much more complex than the technology it's building on. Necessarily, to enable it's features, but none the less it is a consequence of this that when all someo…
Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have to make a 27 div component to style an input.
The big problem is trying to convince the rest of the team that they should learn and use CSS.
Earlier quoted context omitted.
Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.
Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React. > math tools or pdf generation In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.