7 ms·

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 arti

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?

kansface 4y ago
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…
- root_axis 4y ago
  Hooks are not a "language", they're just react API calls.
  - svachalek 4y ago
    "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.
    - postalrat 4y ago
      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.
      - bot41 4y ago
        Is it that they are global state to react but not to the programmer or his/her code?
        the_gipsy 4y ago
        It's that they are not shared like globals.
- nawgz 4y ago
  > 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
  - zero_shift 4y ago
    Indeed, part of svelte's whole "magic" is to interpret labelled blocks beginning with "$" as a hint to do all manner of AOT codegen
  - mejutoco 4y ago
    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.
    - jakelazaroff 4y ago
      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.
      - mejutoco 4y ago
        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 ;)
- dragonwriter 4y ago
  > 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”.
  - azemetre 4y ago
    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.
    - chrisco255 4y ago
      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.
      - ghayes 4y ago
        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.
        dragonwriter 4y ago
        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.
    - dragonwriter 4y ago
      > 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.)
nophunphil 4y ago
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.
- zero_shift 4y ago
  > 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.
  - candiddevmike 4y ago
    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.
    - nophunphil 4y ago
      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.
chimen 4y ago
Why does it have to be in the path of "it's just Javascript"? I don't understand this.
- nonethewiser 4y ago
  Wider marketability.
afavour 4y ago
> 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.
irrational 4y ago
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 ;-)
- blowski 4y ago
  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.
- y-c-o-m-b 4y ago
  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 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.
  - debaserab2 4y ago
sph 4y ago
> 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.
- chrisco255 4y ago
  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.
jacobr 4y ago
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
shaunxcode 4y ago
Yes! CLJS + Reagent (and thus react).
- cutler 4y ago
  Seconded. All the benefits of Clojurescript and React's core proposition without any of the classes/hooks madness.
dtagames 4y ago
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.
- krikou 4y ago
  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).
- rk06 4y ago
  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
  - dtagames 4y ago
    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.
dsiegel2275 4y ago
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.
- itbeho 4y ago
  Same here - we've been much more productive on the development side with LiveView than with our previous React iteration.
colordrops 4y ago
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.
turblety 4y ago
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/ https://mithril.js.org/
vjerancrnjak 4y ago
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 https://rxjs.dev, writing React feels the same. Using ExtJS years ago felt higher level than React.
throwaway0asd 4y ago
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.
- kristopolous 4y ago
  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 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.
- ebiester 4y ago
  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.
FinalBriefing 4y ago
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.
- suction 4y ago
monjumm 4y ago
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.
nop_slide 4y ago
AlpineJS fits my needs for simple sites.
tomgp 4y ago
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.
0xblinq 4y ago
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/ https://unpoly.com/ (2) https://lit.dev/ https://lit.dev/
resonious 4y ago
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.

kansface 4y ago

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…

root_axis 4y ago
Hooks are not a "language", they're just react API calls.
- svachalek 4y ago
  "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.
  - postalrat 4y ago
    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.
    - bot41 4y ago
      Is it that they are global state to react but not to the programmer or his/her code?
      - the_gipsy 4y ago
        It's that they are not shared like globals.
nawgz 4y ago
> 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
- zero_shift 4y ago
  Indeed, part of svelte's whole "magic" is to interpret labelled blocks beginning with "$" as a hint to do all manner of AOT codegen
- mejutoco 4y ago
  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.
  - jakelazaroff 4y ago
    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.
    - mejutoco 4y ago
      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 ;)
dragonwriter 4y ago
> 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”.
- azemetre 4y ago
  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.
  - chrisco255 4y ago
    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.
    - ghayes 4y ago
      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.
      - dragonwriter 4y ago
        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.
  - dragonwriter 4y ago
    > 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.)

nophunphil 4y ago

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.

zero_shift 4y ago
> 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.
- candiddevmike 4y ago
  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.
  - nophunphil 4y ago
    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.

chimen 4y ago

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

nonethewiser 4y ago
Wider marketability.

afavour 4y ago

> 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.

irrational 4y ago

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 ;-)

blowski 4y ago
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.
y-c-o-m-b 4y ago
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 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.
- debaserab2 4y ago

sph 4y ago

> 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.

chrisco255 4y ago
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.

jacobr 4y ago

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

shaunxcode 4y ago

Yes! CLJS + Reagent (and thus react).

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

dtagames 4y ago

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.

krikou 4y ago
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).
rk06 4y ago
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
- dtagames 4y ago
  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.

dsiegel2275 4y ago

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.

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

colordrops 4y ago

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.

turblety 4y ago

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/ https://mithril.js.org/

vjerancrnjak 4y ago

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 https://rxjs.dev, writing React feels the same. Using ExtJS years ago felt higher level than React.

throwaway0asd 4y ago

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.

kristopolous 4y ago
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 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.
ebiester 4y ago
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.

FinalBriefing 4y ago

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.

suction 4y ago

monjumm 4y ago

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.

nop_slide 4y ago

AlpineJS fits my needs for simple sites.

tomgp 4y ago

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.

0xblinq 4y ago

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/ https://unpoly.com/ (2) https://lit.dev/ https://lit.dev/

resonious 4y ago

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.