71–80 of 176 posts
Earlier quoted context omitted.
Node doesn't run in the browser.
Presumably Node is the server (back end), and when the browser requests a TS file, Node is stripping the types before serving it to the browser.
Labeling UI frameworks as artificial complexity is simply a sign of inexperience manifested as NIH syndrome. The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI. Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" ev…
Not everyone is building complex UIs like google sheets. Most people are building static pages with a sprinkle of interactivity, or maybe form pages for doing CRUD.
This can be solved later, but is a lot harder when you have an entire application that needs to bee kept working, and almost trivial if you started with some reactivity built in.
In vanilla JS even small SPA projects can end up tangled or you are hand compiling what React would do for you for free.
Nit: in React events are events useEffect reacts to abstract state changes.
Earlier quoted context omitted.
To write good React you have to follow conventions, too. You can't get away from conventions. People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".
People keep touting react etc but I swear every mobile ordering app I use lags like hell.. I don't doubt it. People make terrible websites with React. However ... what might be happening is that you go to some websites, and some of them are great and others are terrible laggy garbage. When it's a bad one you open up devtools and see React, and that leads you to conclude that React is bad. But reality is that the good…
If we are going to rant like this… i’d say even most of JS is unnecessary. Just use server side template rendering with HTMX. LLM can see server side request flow better anyway.
> The idea of reactivity came from or was popularized by Angular.js No, spreadsheets popularized reactivity. And the general point is incredibly weak. Don't use frameworks and make your own? Sure, have your fun. But then try teaching your framework to your company of 1000 and see how quickly you realize your view of the "problems" are only a slice of the pie.
Do they need 1000 frontend developers?
Aside from the Giants maybe some consultancies or hire-firms have that many? But they use whatever the client uses. If you're not in the business of selling frontend development services then a big part of your competitive advantage is _being able_ to make technology choices that are more-optimal than the labor market's lowest-common-denominator slurry.
Between JS/ECMAscript being abandonware for a decade and CSS' historical immaturity (cross-browser layout, custom properties, more pseudoclasses, etc) the Web was more of a wild west "whatever you we can cobble together" place. So of course we built an entire toolchain ecosystem for all the cool new tools we would reinvent from scratch.
but Things Are Pretty Good these days. We even have the world's only fully system portable assembly language: WASM! And the browser's Web APIs are becoming something like the missing Standard Library (shoutout to Deno).
The author's point seems to be that we are past a tipping point where we need all that additional complexity. You don't _need_ a separate system of reactivity these days, you can write a (closer to pre-hooks React, even!) React-style component library with Web Components now.
Personally I would need for Type Annotations to be a fully supported part of the spec before I made the point to "use the platform" professionally. Until some market force causes the core web technologies to truly fork my skills are useful for life. It's like a pale shadow of how UNIX users must feel :')
Labeling UI frameworks as artificial complexity is simply a sign of inexperience manifested as NIH syndrome. The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI. Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" ev…
Earlier quoted context omitted.
To write good React you have to follow conventions, too. You can't get away from conventions. People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".
People keep touting react etc but I swear every mobile ordering app I use lags like hell.. I don't doubt it. People make terrible websites with React. However ... what might be happening is that you go to some websites, and some of them are great and others are terrible laggy garbage. When it's a bad one you open up devtools and see React, and that leads you to conclude that React is bad. But reality is that the good…
I did an experiment recently, I actually wanted to launch a dashboard and picked React because I knew I could throw React + Tailwind + popular_component_and_charts_frameworks at Opus and get a decent result. But actually, I realized a lot of fairly simple button clicks had like a 100ms-200ms delay, and I just did not like it. I ported it to Java/Javalin with J2HTML and kept tailwind, and it's very snappy and works great. It's currently 96k lines of java ^_^