Hacker News Reader

Comment by throwaway284534 | Hacker News Reader

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React.

For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to solve a complex DOM state issue with custom hooks wrapped around refs.

Newer tools like Svelte and Solid do look promising as far as removing boilerplate, but they personally feel a step too far off the path of “it’s just JavaScript.”

Has anyone else here successfully left for greener JS pastures?

View on HN

I just use vanilla JS on the front-end just like I do with Node.

I have never understood why people find state management challenging. I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my state data in one object, save it on each user interaction, and use it only on page refresh. I have an entire OS GUI working like this and the state management part is only a few dozen lines of code.

Frameworks are like being locked in an insane asylum. You may not be crazy, but everybody else is and you have to follow all these extra rules you would never follow with freedom in the real world. But, the insane asylum provides you meals and bedding and many people can't be bothered to figure that stuff out without necessary hand holding.

I wish I could understand the appeal of react and other frameworks but everytime I interact with them I find them so terrible opaque and frustrating. I've built plenty of things with various frameworks including react[1], maintained, been in team-based development doing it, have github projects that use them with thousands of stars but I think they are brain-damaged terrible ways of doing things that shouldn't exist.

I've given it a fair shake and I wish I could change this opinion. I'm trying not to rant so I'll stop here.

I do a cathartic exercise every time this stuff gets to me at a themed twitter account. It's pure vitriol: https://twitter.com/sisnode

[1] oftentimes I see the anti-react argument as "react sucks which is why I use Y framework". I'm saying they are all(?) a toxic trend that leads to terrible products; more complicated, harder to maintain, aggressively encouraging a glossary of programming antipatterns passing it off as elegance.

Frameworks enable ecosystems. Ecosystems enable reusable components.

The more you deviate from one of the set of common conventions, often enforced by frameworks, the more you have to build on your own.

The larger your project gets, and the more developers who need to understand your code, and the more developers you need to hire and get onboarded quickly, the more that those extra rules start to make sense.

And once you've learned and internalized the patterns necessary to build larger systems, it becomes force of habit to just use it wherever, even if it's nominally easier without them. For most developers, a go-to pattern will be faster than working from first principles on every project.

I'll take Libraries over Frameworks every time.

> I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my...

Then you exactly describe MVC...

> state data in one object,

This is your model.

> save it on each user interaction,

This is your controller.

> and use it only on page refresh.

This is your view.

MVC is a relatively simple concept, and it works well.

Yes I was confused by this. It’s MVC, but without React’s benefit of having the GUI update without a page refresh.

edit - fwiw I too am another heartbroken React dev

I introduced Vue to a plain JS project once and reduced the amount of front end code by almost half, and vastly simplified the state management.

We must work on very different kinds of projects. I really can't imagine plain JS being a viable or appealing solution compared to Vue, which gives me very little grief at all.

While I don't doubt your specific experience, I'm wary about drawing firm conclusions from a single project. Vanilla JS projects can vary wildly in how verbose and complicated they are. I would bet that there are plenty of examples of both types: those that would be much more concise with a framework and those that wouldn't.

> and use it only on page refresh

Doesn't that mean you can never reflect state updates in the DOM without refreshing the whole page?

> I have never understood why people find state management challenging

Automatically determining what DOM objects need to be updated in response to a change in state and updating them without a page refresh adds a lot of complexity, if you completely ignore that requirement then state management would be simple like you said.

I’m also a developer and tech lead who’s been working with React since the beta. Agreed with all your points about React. I’m not sure I would say Svelte and Solid are a farther step off the “just JavaScript” path than React given JSX though.

I haven’t tried Solid, but Svelte has already paid considerable dividends for our team. Frontend feature development pace is faster, the code is generally leaner, and the developers love working with it.

> I haven’t tried Solid, but Svelte has already paid considerable dividends for our team. Frontend feature development pace is faster, the code is generally leaner, and the developers love working with it.

Is that just down to Svelte, though? Or is it the greenfield effect? Projects always fly quickly at first, when the code is fresh and unconstrained, and you're building the basics.

My concern would be when things get complicated and you have to debug Svelte's binding magic - and I have very bad memories doing that in Angular and Knockout.

I would argue it's 100% greenfield effect. A rewrite fixes all the things but introduces new problems. I would bet the OP could've achieved the same effect by figuring out what's wrong with their codebase (which honestly is easier for an outsider to do than someone who has worked on it everyday).

And I would caution against converting anything to a non JSX or hyperscript language (like svelte or vue), you don't want to tie your entire view to some HTML-like DSL IMO.

To clarify, this was new development — not the process of rebuilding of an existing app. For that reason, the greenfield development was indeed simpler.

That being said, it’s been one year and making changes to the Svelte application is (in the developers’ opinions) easier than our set of comparably-sized React applications. Of course, all of this is specific to our team members’ skillsets, the application complexity, etc.

That's interesting. 12 months is still very early though, unless it's a project with a lot of throughput.

I can confirm Svelte is way easier, leaner, and quicker to work with than React. The exception is, of course, the library support, which is a huge drawback and would make me cautious of using it in a business setting for another year or two.

I'm also a TL (which makes me a teaspoon here in Germany, which I like more than the tech lead title). I understand how the development can be faster with Svelte, but ecosystem argument really hits home. You'd get to 80% with Svelte perhaps much faster than React, but that missing library for, say, drag-and-drop makes that last 20% itself plus "hey let's develop our own drag-and-drop library in-house which should be easy and opinionated and maybe it gets open-sourced" (it will be hard, with crazy high budget, as it will try to cover many use-cases you will never have and it still won't be open-sourced because now it's your "core competency" and five months later someone will realize your component has terrible a11y and etc. and one million bug fixes later it is a monster code-base that none wants to touch and maybe rewrite? oh here we go again).

What is a teaspoon?

Yeah, I also didn't get the 'teaspoon' reference.

German word for teaspoon per googling it on the bing: Teelöffel

Seems like the obvious abbreviation for that is TL, so it's a joke on cross-language abbreviation collision.

TL – Teelöffel (teaspoon, unit of measurement)

TL is the abbreviation for the unit teaspoon in German, the way ts is the abbreviation for teaspoon in English.

All excellent points. Yes, the package ecosystem has been a pain point.

We’ve turned this into a slight positive by pushing the business to allow us to make open source contributions. The developers seem to enjoy this a lot, and hopefully our work helps others in the space.

Someone needs to invent a way to import React/Vue/Angular packages to Svelte and still use Svelte syntax somehow. Sounds crazy but I wonder if even remotely possible.

Vue has been my favorite since Vue 2. It hits the right balance for me between the opinionated Angular and "you figure it out" React. It does what I want a JS framework to do: binds values and renders views with minimal setup (computed properties solve so many common problems).

Also, it has amazing ESLint rules that really help keep all your code aligned and following best practices.

That’s the thing though - hooks aren’t JS. They don’t allow for control flow. Hooks are a language that superficially looks like JS. I’m with you on not inventing new languages, and I wish that React didn’t step so far off that path itself…

Hooks are not a "language", they're just react API calls.

"Just" is not really fair here, they're a window into global variables. Global state is awful to deal with but a necessity in the real world, so having some sort of constrained global state is something we're always trying to solve in new ways, singletons, monads, etc. Here we have hooks, which is an interesting experiment but something I personally would have played with in some new framework rather than dropping into the most popular and mainstream one.

Depends on what you mean by global state. You don't have access to a single pool of global variables. You only have access to what you put there and what you've been given.

Is it that they are global state to react but not to the programmer or his/her code?

It's that they are not shared like globals.

> hooks aren't JS

This is so silly. Hooks are literally hooks into a scheduling algorithm you are at the mercy of. That scheduling algorithm is pure JS. Of course you don't have classical control flow in someone else's scheduler.

The key users are referring to when talking about "JS vs magic" is that React is just constructing objects and invoking functions, with known semantics, whereas Solid and Svelte are auto-magic-reactive systems without clear semantics rising from the choice to do even more things in their internal black boxes than React, such as never re-rendering components, dark compiler magic on syntax that doesn't naturally map to a JS tree, and other such things

But hooks need to be named "useX" and have restrictions on where to be called (that a program detects). While they are of js clearly they are not "normal" js functions either.

While I use hooks without problem, I also feel like it is an invented mini-language with a lot of extra quirks. Maybe the problem is js does not map elegantly to some of these functional concepts without a good type system.

Hooks don’t actually need to be named “useX”. That’s the convention, and the React team provides a lint rule that enforces it, but you can name your hooks whatever you want and it’ll work fine.

I’m not what sure what you mean by not “normal” JS functions, though? They’re an API provided by a framework, and — like all APIs — they have specific constraints that govern how they’re used.

Absolutely correct. I stand corrected. There is also a lint rule (the program I was refering to) to check that hooks are not called in some wrong places IIRC. Those lint rules are the default for create react app.

To each their own. Although I use react and hooks, for my taste the hooks api is not very clean. All these are implicit not explicit and without linting they can easily result in runtime errors. But maybe I am spoiled by Elm ;)

> But hooks need to be named "useX"

No they don't, that's a suggested convention

> have restrictions on where to be called (that a program detects)

Yes, it is strange that they opted for this implicit approach, but this is the nature of interacting with a scheduling algorithm in real-time; it is with limitations

I agree they are clearly not unrestricted free-use JS, but they aren't a custom DSL hydrated by compile-time craziness, they are hooks into a scheduling algorithm to help you maintain consistent state in a giant tree. I'm not sure how that is ever going to be free. Perhaps a better type system can help but this is fundamentally complex

> have restrictions on where to be called

This is because hooks are just next() calls on an iterator. Is it magic and entirely because the devs thought it was more beautiful than having to pass a key like state = useState("state", 0)? Absolutely. Does it transcend JS, no.

   hooks = [1, 2, 3, 4]
   
   isOne = next(hooks)
   isTwo = next(hooks)

   if flipcoin()
      isThree = next(hooks)

   # oops, it's sometimes 3
   isFour = next(hooks)

Indeed, part of svelte's whole "magic" is to interpret labelled blocks beginning with "$" as a hint to do all manner of AOT codegen

> hooks aren’t JS

They literally are.

> hooks aren’t JS

The code in React executing components relies on hooks running in a consistent order each time the component runs, but the existence of a runtime context that has expectations about side effects (and hooks are side effects) doesn't make it “not javascript”.

Hooks are executed in order as they are defined, isn't that a fundamentally broken design in regards to language spec?

I don't have an opinion, just generally curious because it feels very odd that the order of my functions matter.

It only matters that the order not change dynamically between renders. This probably could have been avoided if react required a unique key per hook, but I think for brevity it's a decent trade-off.

For the life of me, I can't understand why they didn't go the route of "add an id to your hook." It would solve one of the two big gripes people have with hooks.

ids would be stuttering (especially for things like useMemo/useState), add a different source of error, and—if the goal was to make hooks compatible with flow control—probably create new categories of bugs that would be harder to catch in a linter or even with runtime checks like the existing “number of hooks cllaed changed” one.

Adding visual noise to enable subtle bugs may not be a win.

> Hooks are executed in order as they are defined

Hooks are functions, and they are executed in the order called from within the component, which is itself a function, just like any other functions calls from within another function.

(The mechanism tracking calls to them and deciding whether the function passed to the hook needs to be called requires them to be called in the same order each time the component is executed; if they were called in order of definition rather than normal execution order this would be true by definition; the whole reason for the rule about not using flow control around them is that they are functions executed in normal flow order.)

Thanks for the correction and teaching me something!

Yes and I'm surprised no one has mentioned Lit or bare metal web components in this convo. I'm starting a large TS project at the AAA game studio where I work (my day job, not DTA) and it wasn't hard to choose to avoid React or Vue or Angular.

Lit is the anti-framework because it isn't a framework. Once you remove all the cruft, you can spend a lot more time writing the code that you want to write and, doing so in the way that you want to do it. Everything discussed in this article is solved by bare metal web components.

Indeed, lit is fantastic.

It is built on top of web-standard; I am surprised how (lit)tle attention it gets on HN (so far).

Because lit is too bare metal to qualify as a js framework. Does it have good solutions for router or state management? Last time i checked: No.

That is why it is not discussed that much. If you need to write components, then lit may work for you, but whoever wants to ise those components would prefer a js framework.

Also, lit is from Google. which makes it worse as Angular is from Google as well

Lit is just syntactic sugar for bare metal stuff that is W3C standards based. There isn't any vendor lock-in and won't be "upgrading" your Lit because they told you to.

You are right on components for other people -- but if all the components are for you or your company, ones you handcraft w/ Lit will be lighter weight and easier to write and fix.

Well, I work for a fortune 100 company and we use Vue. After using React, I strongly prefer Vue, so I would say it is the greener JS pasture ;-)

Personally, I found Vue was the best solution for CRUD-like use cases, where the complexity is in the sheer variety and volume of UIs you need to maintain. Whereas React works better for more complex interactions.

That being said, the Vue2 -> Vue3 migration has felt pretty frustrating. It's felt like, with enough work, I could eventually get Vue to behave similar to React.

Agreed. Vue is the best of all worlds in my opinion. Here's my take on the whole thing from a Svelte post a couple of weeks back: https://news.ycombinator.com/item?id=32763509#32767905

> I still think Vue (especially Vue 2) is the greatest of them all. I've worked professionally with Angular, React, and Vue. Each for several years. Vue is easily the winner for me with the syntax that closely matches native HTML and JS/TS and how it encourages clean separation of concerns and clean code. JSX/TSX is absolutely the worst for the latter, it's like the wild west. "But you don't have to write it that way" - yeah ok, but when you work in a large organization it's going to get written that way by your peers; good luck trying to stop it. Angular is just a clusterfuck of pipes and observables that require higher cognitive load to unravel when trying to understand a semi-complex block of code. Contrast with Vue where I can near instantly understand what it's trying to accomplish.

> This shit right here - {#if <condition>} {:else} {/if} - is why Svelte is deterring me. For the love of god, can we stop coming up with weird custom syntax for templating code? This is one area where Angular also pisses me off: *ngIf for example is just as hideous. With Vue: v-if, v-else. You add it as an attribute to native html, it's dead simple. No weird symbols, no braces or other oddball shit I have to look up when I step away from it for a few months and come back. It just makes sense right away.

v-if and v-else are not native html attributes either. Control flow via HTML tags has always felt like a code smell and been a major turn off to me.

I tend to agree with this, I prefer the way Svelte make the not HTML/JS/CSS bits really stand out but it's definately just a personal preference. I don't really care about the "it's not JS" argument, people are happy to use typescript without that compaint so it feels rather arbitrary.

> Has anyone else here successfully left for greener JS pastures?

I've simply stopped doing any frontend development contract work *. Until the whole JavaScript world pulls its head out of its bottom, I'll leave that niche to other people.

* I'll do JS and React if I really have to, but I'm actively avoiding any client-side focused projects.

It's a wide open web with millions of developers, and 25 years of language and ecosystem development, so there will always be 27 1/2 ways to solve a problem. Client side dev is hard. Especially on the web. It's understandable that anyone would avoid it for easier work.

Been using various web component frameworks in enterprise level projects and have been very happy with them (Polymer, Lit, other custom frameworks as well). The nice thing is that since they are standards based you know that they will be around for the long haul and will have a more measured evolution.

I've been using React for maybe 6 years now and Javascript for at least 10 years before that. I've started using Svelte in the last 6-12 months in professional capacity having messed around with it ofr 12 months of side projects before that, to me it feels much closer to writing HTML, CSS and JS than React ever did. Animations, transitions and other things that can be really awkward in React, requiring hooks and all sorts of framework specific constructs just work as if writing in plain HTML/CSS/JS. The template type bits feel nicely and explicitly separate unlike JSX's oddities wrt things like "className", I prefer it. Particularly I find a typical svelte component significantly more legible.

I've used Mithril [1] for years for my personal projects, and React (unfortunately) for my day job.

I wish I could write everything with it.

1. https://mithril.js.org/

Same background here.

I don’t believe in quitting cold turkey and I don’t think there’s anything available to fully replace all aspects of React. We’re instead gradually transitioning our internal ecosystem to use less React-specific stuff, positioning us to migrate (or not) in the next few years.

- Move from CSS-in-JS to vanilla CSS

- Avoid React-specific libraries, both developing them internally or when selecting third-party deps

- Keep business logic out of React components whenever possible

Etc

I've went back to server rendered templates/html, and I'm using Unpoly (1) for adding interaction and partial updates where necessary. I also have a couple Lit (2) components for a part of the app that should work offline.

(1) https://unpoly.com/ (2) https://lit.dev/

I think my sentiment is echoed in some sibling comments as well, but I have been having a good time with vanilla JS lately.

React and friends really do make certain things easier and "nicer". But when you sit down and think about it, those things aren't that bad with vanilla JS. It really makes me wonder what value React et al is adding for the cost in KB and mental overhead.

We have had success in migrating away from React, and in fact away from client-side code altogether by building more and more of the UI of our Elixir/Phoenix backed application in Phoenix LiveView. There are still some parts of system that really need to be client-side code powered (a WYSIWYG HTML editor, for example) but now our default choice for new UI is LiveView.

Same here - we've been much more productive on the development side with LiveView than with our previous React iteration.

> they personally feel a step too far off the path of “it’s just JavaScript.”

That’s more or less exactly what everyone said about JSX when it first arrived. Now people don’t really consider it. I suspect we might end up feeling the same way about Svelte’s language additions if they ever become commonplace.

Why does it have to be in the path of "it's just Javascript"? I don't understand this.

Wider marketability.

Yes! CLJS + Reagent (and thus react).

Seconded. All the benefits of Clojurescript and React's core proposition without any of the classes/hooks madness.

React is great for managing the shadow dom, but it still sucks for state management. I am really happy with React + XState as my core stack. Scalable, type-safe, universal.

React is low level. Svelte and Solid are low level too.

You are dealing with particular values and wiring everything meticulously.

Whenever I write stuff using https://rxjs.dev, writing React feels the same.

Using ExtJS years ago felt higher level than React.

AlpineJS fits my needs for simple sites.

Reply on news.ycombinator.com