oh god, the horror of the fact that this is necessary! As someone who has largely and happily sidestepped the whole reactivity thing for the last decade, it really sounds like that whole world is starting to implode and contradict the very things it promised in the first place (simplicity). Please let web assembly deliver us out of this js-ridden mess \o/
It's not reactivity that's the problem, it's React. The way svelte and solid.js do it is simpler. Things only run once unless explicitly made reactive. And there is no virtual DOM.
Unpopular opinion: I took a look at Svelte. Was immediately disappointed that I can’t just drop it in an existing website.
All these frameworks assume you’re writing stuff from scratch. Most commercial software, both internal and external facing, have legacy to deal with.
Even with a brand new app, you have to succumb to npm/webpack/babel stuff. It feels like building a castle on stilts. Inspires confidence, it does not. Back to jQuery I guess.
You're looking for Vue. It calls itself The Progressive Framework and the title fits.
The thing about Vue is that it spans the whole spectrum of a simple <script> tag à la jQuery all the way up to a fullstack app with server side rendering, jsx & typescript support, IDE plugin, browser debugger, and build system.
But the *great* thing about Vue is that you can start off with the simple <script> tag and add it to an existing project (built with other frameworks) and slowly build up to more Vue features if/as you need them.
It's learning curve is also incredibly smooth so you can ramp up the features to your specific needs.
Some examples:
- There's multiple well respected guides and video series out there to port old legacy enterprise Angular.js applications to Vue.js bit-by-bit until only Vue.js remains
- Laravel (the well known backend php system) has decided to use Vue for it's front-end integrations.
- Wikimedia (the foundation that runs Wikipedia) has decided to adopt Vue.
You can just drop it in. The API allows you to expose any components or code you compile which can be called/created/deleted as regular javascript objects
Maybe checkout lit-html[0]. It doesn't use a virtual DOM, it can be dropped into existing projects, it powers Google's Lit Elements[1], and if you want stateful components you can implement yourself pretty easily[2].
I just visited their web page and I had to laugh at the fact that preact is faster than React in their benchmarks... I used preact for hobby projects to avoid the horror of JS build systems. I didn't know that this is going to get me more performance.
I'm a skeptic of the promises of reactivity and a fan of web assembly, but the main reason reactivity is a pain is because UIs are inherently a painful domain, not because of JS itself.
No they aren't. Developers think their a painful domain because they are the ones that introduce the complexity in the name of the customer who doesn't care, to increase the developers salary in some kind of crazy Ponzi scheme.
I’ve been working on UIs for 15 years and when I read comments like this I have to wonder if you’ve worked on complex, stateful, feature-rich UIs. The potential for bugs to appear is almost exponential as you add layers, and it isn’t really the fault of the developer so much as the nature of nested behaviours. This is true in any environment, but easier to manage when human beings aren’t the ones executing your code in non-deterministic ways in variable execution settings.
The tools we have in the browser are excellent up to a point. I think the challenge comes when you need to create reusable abstractions around them several layers deep.
There are tools which help manage these challenges really well, like state charts, but they aren’t perfect and they come with their own challenges. The reality (I think) is that UIs can present quite incredible complexity, and creating tools with approachable APIs to help tame the complexity is a legitimately huge challenge.
It could be that I’m a bad software developer (most days I’m pretty sure there’s some truth in that), but I’m passionate and spend a lot of time deep in this space and exploring ways to make it better. It isn’t rocket science, but it isn’t digging holes either. The react team is a bunch of smart people and they’re doing good work on solving a tough challenge.
I don’t see a Ponzi scheme at all. Sorry if I’ve missed some sarcasm or something here - feel free to disregard if that’s the case (or if it isn’t, too)
One thing I've found is that things used to be a lot simpler. We've added tons of complexity in the last 15 years, but the fundamentals of web pages and the UI controls in them largely have stayed the same. We've largely moved backwards. And what's worse, I can't even hire junior devs who know how to do things the old simple way anymore. It's framework or bust now.
Web browsers have had callbacks for DOM elements since... forever. Why did we need to add an entire component framework like React on top of it?
Everything on a web page does not need to be interactive. It's a document first.
Web applications are cool. Maybe React makes sense there. _But every site does not need to be a web application!_ And yet somehow, React and company became the industry default.
I agree with you to the extent that components = interactive. But there are other benefits of a component model, even for pages which are mostly static. They allow you to develop the same page and its various (reusable) parts with the same code for rendering the static parts and the dynamic parts. This is especially nice on sites where the dynamic-to-static ratio may vary significantly between pages, or between areas of the same page.
This use case hasn’t been particularly well supported by many component libraries (React among them; Marko being a long time notable exception), but it’s an area that’s currently having a bit of a renaissance: there is of course Marko which has supported this model for years, joined by other notable frameworks like Astro and Qwik. Even React is moving more in this direction with Server Components, just targeting other use cases.
The component model will continue to thrive, not because everything is interactive, but because components are an excellent abstraction for developing for the web (and a lot of other formats).
React doesn't have to be your whole website. Even the starter tutorial in the docs starts off by showing you how to just add in React through a CDN and make a react app as a single component of a bigger webpage
Obviously that's not at all how it's used in practice (or even in the create-react-app template), but I do think there's a place for something like React
Others are right to point out that this isn’t a problem with reactivity. But there’s an even more important correction here: React, perhaps in spite of its name, isn’t actually (fully) reactive. And while that’s sort of an academic nuance[1], it’s the underlying reason for implementing things like this.
Are the people building React completely oblivious to the nigh-unbearable code smell that this is? Why is it so difficult to reason about whether or not code will have side effects?
I'm no frontend developer, and certainly don't have experience with React, but after stopping in at their homepage to see what it does for me and finding out about "JSX syntax"... jesus. I don't know how you parse something like JSX, but I would be willing to bet the implementation is a dumpster fire of completely unnecessary complexity.
I would really like to believe that the people building this stuff aren't amateurs, but the more I learn, the more convinced I am that this is the case. The modern web is bloated, slow, and riddled an assortment of issues that is different depending on which site you're on. Will my back button work this time? It's anybody's guess!
It only seems appropriate to lay the blame at the feet of those who thought the best course of action was to make web development ten times more complicated than it needs to be.
I wasn't intending to imply that it was the React team's fault.
Personally, I like React and think it has its uses. I was loosely referencing an old coworker who was successfully and comfortably using jQuery for over a decade.
> Blame the employer
I do. They wanted cheaper labour so they had a revolving door of junior developers straight out of online React boot camps and since it's all they know it's what they used on every project regardless of other technologies that were a better fit. Turnover can be expensive so the company caved in and turned every project into a React project.
> or yourself for not switching
Sometimes easier said than done. It can be hard for some people to up and leave when they like their boss/company that they've worked with for 20+ years.
> Why is it so difficult to reason about whether or not code will have side effects?
I’m not sure exactly what you mean here, but I can’t think of any reasonable way to write a JavaScript framework that invokes developers’ JS code containing functions, closures, etc. and makes it simple to reason about whether that code will have side effects. This seems like a basic consequence of Rice’s theorem. I suppose you could have a compiler that only supports a strict subset of JavaScript and makes side effects easier to reason about, but arguably that would just be its own separate language altogether.
