16 ms·

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for React was - 1. JSX - typing and auto-complete for components, colocation. 2. No direct dom access. (Good bye $element) Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. Luckily none of the other frameworks, even Angular, have rampant direct dom access anymore. Hooks aren't a problem in general. It's just the useEffect hook. Unfortunately that's a big problem. That hook should never have existed. And it was clear from the start it'll be a pain from the limitations around it. It requires a mental model detached from everything people are used to and from other things around it. When using React I usually just use MobX and everything just works.

manmal 4y ago
What’s the alternative to useEffect? I need it very often.
- redbar0n 4y ago
  you could try XState events, see David's "Goodbye useEffect" talk: https://www.youtube.com/watch?v=bGzanfKVFeU https://www.youtube.com/watch?v=bGzanfKVFeU or you could try the newfound craze: signals.
thegeomaster 4y ago
How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard it, and why the modern webapp experience is so miserable for the average person.
- codeptualize 4y ago
  > the modern webapp experience is so miserable for the average person. I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?
  - marginalia_nu 4y ago
    Try getting a slightly shitty phone and visit a place with spotty wifi that drops some packets. It's very enlightening. I'm averaging a 15-30 second TTI on the most js-heavy sites.
  - gurraman 4y ago
    Same. We've been working on a huge React project for several years. Lots of graphs, 3d models etc ... and it is super-snappy. Only slow part is a WebGL-based chart component that visualizes 2-3 M rows of signal data. We can probably decimate the signal data to improve performance, but that has got nothing to do with us using React. N.B. No one is using the app from their mobiles. iPad and computers only. Our reasons for choosing React when there are so many alternatives: prior knowledge, ergonomics, easy onboarding, ecosystem.
    - dham 4y ago
      Super-snappy for who? You? with a $4000 Mac Book Pro? Even with 6x CPU slowdown in Chrome, that's not enough throttling for these modern computers to test with.
    - eastbound 4y ago
      Modularization. With React, you can delegate a component to one team and use it as a web-component. Actually, why aren’t web-components a thing, that’s another story. But componentization is why React creates clean code.
      - DoesntMatter22 4y ago
        I make this argument all the time and people think I'm an idiot, which is fine. But JSX to me is reason that Svelte and Vue aren't as good. They are faster IMO but with JSX it's nice that you can make a form and then each part of the form can be broken out into separate methods. The reasoning I get all the time is "Why would you want to do that? That's stupid". It's just so much nicer honestly. I'm not a react fan at all but that's one thing I miss about it.
scns 4y ago
SolidJS and Preact would be alternatives with JSX (and React compatibility in Preacts case). Worth checking out IMHO.
azangru 4y ago
> People tend to compare these frameworks on things that don't matter - often it's performance. Performance people get offended when they hear things like that. I imagine what they will tell a person who says something like this is to: - Look at the traces. Real metrics, on real devices that users have, not the one that developer has. - Consider either large contentful paint (will likely be subpar with client-side rendering) or first input delay (will likely be subpar with server-side rendering). Consider, too, the new interaction-to-next-paint metric (rumoured to be bad with all js-heavy sites) If these metrics look good, then great; carry on doing what you are doing. If they don't look so good, then, they would say, reflect on whether what you are building is losing the business money by driving users away.
- bayesian_horse 4y ago
  "Performance" matters a lot less than many other things like collaborating with other people, or getting the DOM manipulation right.
  - simmerup 4y ago
    I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.
    - pas 4y ago
      My reading is the opposite. Basically all real end-to-end UX (actual performance included) depends on a collaborative effort. Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.
      - thegeomaster 4y ago
        Structuring the UX in a user friendly way matters more, that doesn't mean random 200ms lags are OK. As you said, performance is UX too. I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Not particularly because of performance, but they will enjoy using it more, and they won't be able to explain exactly why. You'd think that with the ridiculous amounts of money software engineers are paid to do what they do, they'd be able to swallow slightly more difficult collaboration and developer experience in order to deliver a more quality product. Forgive me for being harsh, and I don't mean this as directed to you (I don't know you), but our industry behaves like a bunch of babies. Aside: if you're making an interactive game, you have 16ms to respond and render, not hundreds. In 16ms, modern games dispatch draw calls for millions of triangles, do AI, physics, netcode, level streaming and other bookeeping. Yet the teams there collaborate just fine.
KyeRussell 4y ago
Your dislike for ‘templates’ is much more a matter of personal preference than you’re letting on. Using language like “still using templates” makes me think that you don’t see any valid opposing view. I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. But framing non-JSX approaches as objectively inferior is not in tune with the reality, being that this is something sensible people disagree on.
- wokwokwok 4y ago
  > Templates are a no go for me It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this. > I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. Ok. Um… well, it’s hard to have a discussion if you won’t talk about it… …but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text templates. It’s because they are code. A template is (almost always) a weakly typed DSL. Written, ignoring all the history of language design… by a bunch of folk who don’t really know how to write programming languages. …and, they. Are. Bad. Not always… but often. …because writing a language is hard, and because (reason) you can’t ever use an existing template language. Oh no. This framework has to have its own unique one, because otherwise it doesn’t integrate tightly. Do you like DSLs? Or do they just hide the complexity somewhere else? What if the DSL is bad, not orthogonal in its feature set, poorly implemented …but cute, and useful for a very very narrow use case. Isn’t the main critique of react that it hides complexity by moving it from one place to another? Don’t you think it’s a tiny bit ironic that all the other templates based languages with their custom template DSLs are doing the same thing? Anyway; I think it’s fair to evaluate template languages as what they are: DSLs. JavaScript is a better language than most template languages by a variety of metrics. Other languages are better than JavaScript, absolutely… but, never, have I seen a template language that is. You can love declarative configuration all you want, but it’s very very difficult to argue that just because you can make a mess with procedural approaches that they are worse; because they are a strict superset of what’s possible using the declarative approach. …so sure. I don’t but “JSX is easier to maintain”, but it’s distinctly superior in capability.
  - 4y ago
theteapot 4y ago
> Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. I've gravitated away from React towards Vue v3. Templates are working fine, well even. You still use similar amount of Javascript (probably less). > It's just the useEffect hook. Unfortunately that's a big problem. That hook should never have existed. Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation https://reactjs.org/docs/hooks-intro.html#motivation. They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion without going to hooks at all, but now everything is a fucking hook.
- Sammi 4y ago
  I'm interested in hearing more about that last point.
- Illniyar 4y ago
  >Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation https://reactjs.org/docs/hooks-intro.html#motivation. They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion without going to hooks at all, but now everything is a fucking hook. There was (and still is) a real problem in react with composability. Which they tried to solve with mixins, then HOC and then hooks. The three main hooks are useState, useContext and useEffect . useState and useContext are very straightforward and an overall improvement on their previous counterparts. useEffect was an improvement over mixins, but it was a worse solution for class component lifecycle methods. It was fairly obvious that useEffect had a lot of problems from the get go, but it was deemed worthwhile to add so that functional programming proponents could have state without classes and to finally have a way to use composability without the horribleness of mixins and hocs (which were worse then useEffect). The real problem is that useEffect has it's own problems, and while we no longer have the old problems, the new problems might be worse.
OtomotO 4y ago
> But I choose frameworks because of developer ergonomics. I understand that sentiment, but it's part of the reason why computers today don't feel faster than in the past and why we waste sooooo incredibly much energy.
- namaria 4y ago
  I don't think the sentiment in itself is harmful. I agree with the conclusion, but I believe the problem is, there is so much accidental complexity built into this space. Path dependency makes it hard to get rid of it, so rational developers and start ups end up contributing to the problem.
Ciantic 4y ago
> When using React I usually just use MobX and everything just works. MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS. SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals changes. In reality it doesn't have renders, because it's not based on VDOM, but it makes it look like it does. However I like to keep my signal library separate, I would wish SolidJS had separate signals library I could use elsewhere as well. Also SolidJS is big library and framework by now, it comes with risks if Ryan Carniato were ever to loose interest. Edit, I also found that Ryan has created an example of MobX and JSX without React, it's a good way to demonstrate that React is not as important with signals libraries: https://github.com/ryansolid/mobx-jsx https://github.com/ryansolid/mobx-jsx since you know MobX that example probably makes sense.
- Illniyar 4y ago
  I haven't used SolidJS, so I can't comment much. But Signals have very good developer ergonomics. But from my experience other frameworks that use them come with drawbacks that I don't get with react. So MobX+React works better for me than - let's say vue. From a brief look at their website, the downsides for using SolidJs for me seem pretty big. At the very first example, if you change it slightly you can see my problems: const CountingComponent = () => { const [count, setCount] = createSignal(0); const interval = setInterval( () => setCount(count => count + 1), 1000 ); onCleanup(() => clearInterval(interval)); if (count() % 2 == 0) { return <div>Even count value is {count()}</div>; } return <div>Odd count value is {count()}</div>; }; 1. MobX let's me use objects without additional syntax (createSignal, count() instrad of just count) 2. The fact that the component does not rerender and that my code does not automatically change between even and odd text means I'll probably need to have an additional mental model for writing SolidJS components. Using React+MobX I just write as I would write any other function and it'll just work (There's magic involved, but manageable magic)
  - c-hendricks 4y ago
    There was a debate very recently between SolidJS and React communities over "internalized react-isms" like difference in behaviour you've pointed out. I think it's React that are doing the weird thing and calling your whole function again when one piece of data changes, but I do like having the ability to return early.
brnewd 4y ago
TSX + MobX are the reason I'm happy to stay on the React train after a transition from AngularJs (1) to Vue 2 to React.
- KronisLV 4y ago
  You might also be interested in checking out Vue 3 (with the Composition API) and Pinia, it's a pretty nice setup that feels similarly nice to how working with MobX is and even supports TypeScript. Composition API: https://vuejs.org/guide/extras/composition-api-faq.html https://vuejs.org/guide/extras/composition-api-faq.html Pinia (state management store): https://pinia.vuejs.org/ https://pinia.vuejs.org/ TypeScript support: https://vuejs.org/guide/typescript/composition-api.html https://vuejs.org/guide/typescript/composition-api.html While I mostly stuck with JavaScript, personally I found the setup more convenient to use than working with hooks in React, and Pinia is also more like MobX than something like Redux, in that you don't have to work with too much accidental complexity for relatively simple setups. Sadly I don't have examples from that project, because it was proprietary, but the linked docs are nice.
  - brnewd 4y ago
    Thanks, I'm sure Vue 3 is a lot better than v2, but I deeply appreciate TSX for its refactoring and type checking capabilities. Vue does support TSX but it isn't a first class citizen.
red_admiral 4y ago
> People tend to compare these frameworks on things that don't matter - often it's performance. Performance on the end-user device, especially if you're just under/over certain thresholds like 1sec to switch "tabs" or whatever you're using, does matter. Especially if you're trying to get people to buy stuff. I wish all developers had to routinely try their products on a low-end 2-year-old smartphone. That would take the discussion of whether performance matters to a more informed level.
- sonicgear1 4y ago
  Its is actually sad just looking from a hardware endpoint. A 2016 iPhone 7 has an advanced 5 nanometer CPU. That is really powerful when looking at the grand scheme of things. Yet most react "websites" will completely obliterate it and make the phone get blazingly hot. I do this for fun a lot when browsing the web: when a website makes my phone literally melt, I check its stack on my PC and sure enough it is almost always React paired up with Redux. These performance apologetics are sad.
molszanski 4y ago
> When using React I usually just use MobX and everything just works. Same. React as a UI library is great. React as a state manager (hooks) or a framework is (hooks or hooks+next) is not good. Writing and fusing business logic to a framework is always a bad idea
scotty79 4y ago
I don't see a problem with useEffect. It releses you from thinking about component lifecycle. Conceptually the body of your component runs on every render. If you want to have some effect on your component not running in sync with that then you have useEffect to set it up and clean it up not when the component is mounted, unmoutend, rerendered ... just when the stuff you are interested in changes.
larsnystrom 4y ago
I would say that useEffect is my favorite hook. It's neat. My least favorite hook would be useReducer. I've never used that one.
h9h9h9 4y ago
[flagged]
kypro 4y ago
> Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. Could you expand on this. You assert that "applications" are easier to maintain with JS, but blogs are not? Are you defining "application" here as something with dynamic and interactive content? Also, why is it easier to "make and maintain"? I'm not necessarily disagreeing, just curious as to why you believe this.
- Illniyar 4y ago
  The way I look at it - the majority of value with blogs and static website is content. Hence the majority of change is of content. For apps the majority of value is functionality and that's where a lot of changes happen. The main problem of maintenance happens where there is the most change - in JSX programming (I.E. functionality) is a first class citizen and it lends it easier to change. With templates content is much more of a first-class citizen. Of course this is all in the margins, you can write blogs/static sites well in react and applications well in template-based languages. The tradeoffs are just a bit skewed in favor of each, and it mostly manifests when you don't have time to be disciplined about changes.
  - kypro 4y ago
    Thanks for the explanation. Makes sense.
jmull 4y ago
JSX is yet another template language, is it not?
Tade0 4y ago
> I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. I dislike when JSX is framed as "just Javascript". It's really not - it's a templating language, just a very odd one - like its spiritual predecessor. Personally I find JSX to be write-only and hard to reason about when looking at someone else's code.
Varqu 4y ago
In my opinion, React was pretty much complete without the introduction of Hooks. Shifting from the previous Component-derived mental models to Hooks was a cause of many runtime issues in at least 2 companies that I worked for. Unfortunately, React went from less-capable and more understandable to more-capable and less-understandable model. But yeah, that's just a newbie-coder take.
philliphaydon 4y ago
There's 2 things that I hate about react. 1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup. 2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make the most mundane changes. Other libraries seem to suffer from this to a far smaller scale.
- azangru 4y ago
  How is this example from vue docs: <a v-on:click="doSomething"> preferable to the jsx version: <a onClick={doSomething}> or even this loop example from the vue docs: <li v-for="item in items"> {{ item.message }} </li> better than its jsx counterpart? items.map(item => ( <li key={item.id}>{item.message}</li> ))
  - tekkk 4y ago
    For one you don't have to write an arbitrary key={item.id}. What if you don't have a unique ID? And even if you do, it's just busywork. Then, what about conditionals? Or slots? Or classNames instead of classes? The saving grace of JSX is that it allows the creation of multiple small components inside a single file.
    - philliphaydon 4y ago
      > The saving grace of JSX is that it allows the creation of multiple small components inside a single file. That's definitely not the saving grace of JSX. As I said, every react project is soooooooo overly abstracted into the tiniest little components. It's no wonder people /think/ react is slow.
  - Yiin 4y ago
    Doesn't change the point, but it's usually <a @click="doSomething">
  - 4y ago
synergy20 4y ago
why is useEffect hook in particular that bad? I played with Vue and svelte and now a firm React user, mainly due to its ecosystem, for most products the slowness of React does not play a major role at all for me.
afavour 4y ago
My personal bugbear about pretty much all web frameworks discourse is universally stated things like: > People tend to compare these frameworks on things that don't matter - often it's performance. Performance matters in a lot of contexts. If you’re doing complex stuff performance matters. If you’re a public facing site depending in search traffic performance matters. I’ve ended up disliking React simply because it’s become this one size fits all solution that 90% of web development goes through without it ever being necessary. There’s nothing wrong with React itself but it’s often applied badly.
adql 4y ago
> People tend to compare these frameworks on things that don't matter - often it's performance. I think I reflect the entirety of the user base of the internet when I say "fuck you" (not you in particular, just the trend of shitting on performance so we have apps running like it is 70's and tape drives on our gigahertz CPUs) here.
bakugo 4y ago
> things that don't matter - often it's performance You're a react guy, alright.
0xblinq 4y ago
This thinking is why most SPAs are utter shit for the end user. Most developers are so happy about their ergonomics and how cool their tools are and don’t care at all the application uses 200M on your browser and every key stroke takes 200ms to show in an input. This also happens in the backend, but the difference is that the company país the price in the form of more infrastructure. But in the frontend is “free” so why care at all, right?
- replygirl 4y ago
  that's a problem with the choice to go spa instead of ssr or static, not the choice to use a framework with productivity benefits. with every major meta-framework working seamlessly with the popular serverless hosts, it's a wonder anyone takes spa seriously in any performance-sensitive context
deleted 4y ago
[deleted]
pharmakom 4y ago
JSX is overrated. Why copy HTML, which is a pain to write? I much prefer regular old function calls. Or even s-expressions!

manmal 4y ago

What’s the alternative to useEffect? I need it very often.

redbar0n 4y ago
you could try XState events, see David's "Goodbye useEffect" talk: https://www.youtube.com/watch?v=bGzanfKVFeU https://www.youtube.com/watch?v=bGzanfKVFeU or you could try the newfound craze: signals.

thegeomaster 4y ago

How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard it, and why the modern webapp experience is so miserable for the average person.

codeptualize 4y ago
> the modern webapp experience is so miserable for the average person. I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?
- marginalia_nu 4y ago
  Try getting a slightly shitty phone and visit a place with spotty wifi that drops some packets. It's very enlightening. I'm averaging a 15-30 second TTI on the most js-heavy sites.
- gurraman 4y ago
  Same. We've been working on a huge React project for several years. Lots of graphs, 3d models etc ... and it is super-snappy. Only slow part is a WebGL-based chart component that visualizes 2-3 M rows of signal data. We can probably decimate the signal data to improve performance, but that has got nothing to do with us using React. N.B. No one is using the app from their mobiles. iPad and computers only. Our reasons for choosing React when there are so many alternatives: prior knowledge, ergonomics, easy onboarding, ecosystem.
  - dham 4y ago
    Super-snappy for who? You? with a $4000 Mac Book Pro? Even with 6x CPU slowdown in Chrome, that's not enough throttling for these modern computers to test with.
  - eastbound 4y ago
    Modularization. With React, you can delegate a component to one team and use it as a web-component. Actually, why aren’t web-components a thing, that’s another story. But componentization is why React creates clean code.
    - DoesntMatter22 4y ago
      I make this argument all the time and people think I'm an idiot, which is fine. But JSX to me is reason that Svelte and Vue aren't as good. They are faster IMO but with JSX it's nice that you can make a form and then each part of the form can be broken out into separate methods. The reasoning I get all the time is "Why would you want to do that? That's stupid". It's just so much nicer honestly. I'm not a react fan at all but that's one thing I miss about it.

scns 4y ago

SolidJS and Preact would be alternatives with JSX (and React compatibility in Preacts case). Worth checking out IMHO.

azangru 4y ago

> People tend to compare these frameworks on things that don't matter - often it's performance. Performance people get offended when they hear things like that. I imagine what they will tell a person who says something like this is to: - Look at the traces. Real metrics, on real devices that users have, not the one that developer has. - Consider either large contentful paint (will likely be subpar with client-side rendering) or first input delay (will likely be subpar with server-side rendering). Consider, too, the new interaction-to-next-paint metric (rumoured to be bad with all js-heavy sites) If these metrics look good, then great; carry on doing what you are doing. If they don't look so good, then, they would say, reflect on whether what you are building is losing the business money by driving users away.

bayesian_horse 4y ago
"Performance" matters a lot less than many other things like collaborating with other people, or getting the DOM manipulation right.
- simmerup 4y ago
  I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.
  - pas 4y ago
    My reading is the opposite. Basically all real end-to-end UX (actual performance included) depends on a collaborative effort. Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.
    - thegeomaster 4y ago
      Structuring the UX in a user friendly way matters more, that doesn't mean random 200ms lags are OK. As you said, performance is UX too. I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Not particularly because of performance, but they will enjoy using it more, and they won't be able to explain exactly why. You'd think that with the ridiculous amounts of money software engineers are paid to do what they do, they'd be able to swallow slightly more difficult collaboration and developer experience in order to deliver a more quality product. Forgive me for being harsh, and I don't mean this as directed to you (I don't know you), but our industry behaves like a bunch of babies. Aside: if you're making an interactive game, you have 16ms to respond and render, not hundreds. In 16ms, modern games dispatch draw calls for millions of triangles, do AI, physics, netcode, level streaming and other bookeeping. Yet the teams there collaborate just fine.

KyeRussell 4y ago

Your dislike for ‘templates’ is much more a matter of personal preference than you’re letting on. Using language like “still using templates” makes me think that you don’t see any valid opposing view. I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. But framing non-JSX approaches as objectively inferior is not in tune with the reality, being that this is something sensible people disagree on.

wokwokwok 4y ago
> Templates are a no go for me It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this. > I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. Ok. Um… well, it’s hard to have a discussion if you won’t talk about it… …but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text templates. It’s because they are code. A template is (almost always) a weakly typed DSL. Written, ignoring all the history of language design… by a bunch of folk who don’t really know how to write programming languages. …and, they. Are. Bad. Not always… but often. …because writing a language is hard, and because (reason) you can’t ever use an existing template language. Oh no. This framework has to have its own unique one, because otherwise it doesn’t integrate tightly. Do you like DSLs? Or do they just hide the complexity somewhere else? What if the DSL is bad, not orthogonal in its feature set, poorly implemented …but cute, and useful for a very very narrow use case. Isn’t the main critique of react that it hides complexity by moving it from one place to another? Don’t you think it’s a tiny bit ironic that all the other templates based languages with their custom template DSLs are doing the same thing? Anyway; I think it’s fair to evaluate template languages as what they are: DSLs. JavaScript is a better language than most template languages by a variety of metrics. Other languages are better than JavaScript, absolutely… but, never, have I seen a template language that is. You can love declarative configuration all you want, but it’s very very difficult to argue that just because you can make a mess with procedural approaches that they are worse; because they are a strict superset of what’s possible using the declarative approach. …so sure. I don’t but “JSX is easier to maintain”, but it’s distinctly superior in capability.
- 4y ago

theteapot 4y ago

> Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. I've gravitated away from React towards Vue v3. Templates are working fine, well even. You still use similar amount of Javascript (probably less). > It's just the useEffect hook. Unfortunately that's a big problem. That hook should never have existed. Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation https://reactjs.org/docs/hooks-intro.html#motivation. They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion without going to hooks at all, but now everything is a fucking hook.

Sammi 4y ago
I'm interested in hearing more about that last point.
Illniyar 4y ago
>Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation https://reactjs.org/docs/hooks-intro.html#motivation. They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion without going to hooks at all, but now everything is a fucking hook. There was (and still is) a real problem in react with composability. Which they tried to solve with mixins, then HOC and then hooks. The three main hooks are useState, useContext and useEffect . useState and useContext are very straightforward and an overall improvement on their previous counterparts. useEffect was an improvement over mixins, but it was a worse solution for class component lifecycle methods. It was fairly obvious that useEffect had a lot of problems from the get go, but it was deemed worthwhile to add so that functional programming proponents could have state without classes and to finally have a way to use composability without the horribleness of mixins and hocs (which were worse then useEffect). The real problem is that useEffect has it's own problems, and while we no longer have the old problems, the new problems might be worse.

OtomotO 4y ago

> But I choose frameworks because of developer ergonomics. I understand that sentiment, but it's part of the reason why computers today don't feel faster than in the past and why we waste sooooo incredibly much energy.

namaria 4y ago
I don't think the sentiment in itself is harmful. I agree with the conclusion, but I believe the problem is, there is so much accidental complexity built into this space. Path dependency makes it hard to get rid of it, so rational developers and start ups end up contributing to the problem.

Ciantic 4y ago

> When using React I usually just use MobX and everything just works. MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS. SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals changes. In reality it doesn't have renders, because it's not based on VDOM, but it makes it look like it does. However I like to keep my signal library separate, I would wish SolidJS had separate signals library I could use elsewhere as well. Also SolidJS is big library and framework by now, it comes with risks if Ryan Carniato were ever to loose interest. Edit, I also found that Ryan has created an example of MobX and JSX without React, it's a good way to demonstrate that React is not as important with signals libraries: https://github.com/ryansolid/mobx-jsx https://github.com/ryansolid/mobx-jsx since you know MobX that example probably makes sense.

Illniyar 4y ago
I haven't used SolidJS, so I can't comment much. But Signals have very good developer ergonomics. But from my experience other frameworks that use them come with drawbacks that I don't get with react. So MobX+React works better for me than - let's say vue. From a brief look at their website, the downsides for using SolidJs for me seem pretty big. At the very first example, if you change it slightly you can see my problems: const CountingComponent = () => { const [count, setCount] = createSignal(0); const interval = setInterval( () => setCount(count => count + 1), 1000 ); onCleanup(() => clearInterval(interval)); if (count() % 2 == 0) { return <div>Even count value is {count()}</div>; } return <div>Odd count value is {count()}</div>; }; 1. MobX let's me use objects without additional syntax (createSignal, count() instrad of just count) 2. The fact that the component does not rerender and that my code does not automatically change between even and odd text means I'll probably need to have an additional mental model for writing SolidJS components. Using React+MobX I just write as I would write any other function and it'll just work (There's magic involved, but manageable magic)
- c-hendricks 4y ago
  There was a debate very recently between SolidJS and React communities over "internalized react-isms" like difference in behaviour you've pointed out. I think it's React that are doing the weird thing and calling your whole function again when one piece of data changes, but I do like having the ability to return early.

brnewd 4y ago

TSX + MobX are the reason I'm happy to stay on the React train after a transition from AngularJs (1) to Vue 2 to React.

KronisLV 4y ago
You might also be interested in checking out Vue 3 (with the Composition API) and Pinia, it's a pretty nice setup that feels similarly nice to how working with MobX is and even supports TypeScript. Composition API: https://vuejs.org/guide/extras/composition-api-faq.html https://vuejs.org/guide/extras/composition-api-faq.html Pinia (state management store): https://pinia.vuejs.org/ https://pinia.vuejs.org/ TypeScript support: https://vuejs.org/guide/typescript/composition-api.html https://vuejs.org/guide/typescript/composition-api.html While I mostly stuck with JavaScript, personally I found the setup more convenient to use than working with hooks in React, and Pinia is also more like MobX than something like Redux, in that you don't have to work with too much accidental complexity for relatively simple setups. Sadly I don't have examples from that project, because it was proprietary, but the linked docs are nice.
- brnewd 4y ago
  Thanks, I'm sure Vue 3 is a lot better than v2, but I deeply appreciate TSX for its refactoring and type checking capabilities. Vue does support TSX but it isn't a first class citizen.

red_admiral 4y ago

> People tend to compare these frameworks on things that don't matter - often it's performance. Performance on the end-user device, especially if you're just under/over certain thresholds like 1sec to switch "tabs" or whatever you're using, does matter. Especially if you're trying to get people to buy stuff. I wish all developers had to routinely try their products on a low-end 2-year-old smartphone. That would take the discussion of whether performance matters to a more informed level.

sonicgear1 4y ago
Its is actually sad just looking from a hardware endpoint. A 2016 iPhone 7 has an advanced 5 nanometer CPU. That is really powerful when looking at the grand scheme of things. Yet most react "websites" will completely obliterate it and make the phone get blazingly hot. I do this for fun a lot when browsing the web: when a website makes my phone literally melt, I check its stack on my PC and sure enough it is almost always React paired up with Redux. These performance apologetics are sad.

molszanski 4y ago

> When using React I usually just use MobX and everything just works. Same. React as a UI library is great. React as a state manager (hooks) or a framework is (hooks or hooks+next) is not good. Writing and fusing business logic to a framework is always a bad idea

scotty79 4y ago

I don't see a problem with useEffect. It releses you from thinking about component lifecycle. Conceptually the body of your component runs on every render. If you want to have some effect on your component not running in sync with that then you have useEffect to set it up and clean it up not when the component is mounted, unmoutend, rerendered ... just when the stuff you are interested in changes.

larsnystrom 4y ago

I would say that useEffect is my favorite hook. It's neat. My least favorite hook would be useReducer. I've never used that one.

h9h9h9 4y ago

[flagged]

kypro 4y ago

> Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. Could you expand on this. You assert that "applications" are easier to maintain with JS, but blogs are not? Are you defining "application" here as something with dynamic and interactive content? Also, why is it easier to "make and maintain"? I'm not necessarily disagreeing, just curious as to why you believe this.

Illniyar 4y ago
The way I look at it - the majority of value with blogs and static website is content. Hence the majority of change is of content. For apps the majority of value is functionality and that's where a lot of changes happen. The main problem of maintenance happens where there is the most change - in JSX programming (I.E. functionality) is a first class citizen and it lends it easier to change. With templates content is much more of a first-class citizen. Of course this is all in the margins, you can write blogs/static sites well in react and applications well in template-based languages. The tradeoffs are just a bit skewed in favor of each, and it mostly manifests when you don't have time to be disciplined about changes.
- kypro 4y ago
  Thanks for the explanation. Makes sense.

jmull 4y ago

JSX is yet another template language, is it not?

Tade0 4y ago

> I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. I dislike when JSX is framed as "just Javascript". It's really not - it's a templating language, just a very odd one - like its spiritual predecessor. Personally I find JSX to be write-only and hard to reason about when looking at someone else's code.

Varqu 4y ago

In my opinion, React was pretty much complete without the introduction of Hooks. Shifting from the previous Component-derived mental models to Hooks was a cause of many runtime issues in at least 2 companies that I worked for. Unfortunately, React went from less-capable and more understandable to more-capable and less-understandable model. But yeah, that's just a newbie-coder take.

philliphaydon 4y ago

There's 2 things that I hate about react. 1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup. 2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make the most mundane changes. Other libraries seem to suffer from this to a far smaller scale.

azangru 4y ago
How is this example from vue docs: <a v-on:click="doSomething"> preferable to the jsx version: <a onClick={doSomething}> or even this loop example from the vue docs: <li v-for="item in items"> {{ item.message }} </li> better than its jsx counterpart? items.map(item => ( <li key={item.id}>{item.message}</li> ))
- tekkk 4y ago
  For one you don't have to write an arbitrary key={item.id}. What if you don't have a unique ID? And even if you do, it's just busywork. Then, what about conditionals? Or slots? Or classNames instead of classes? The saving grace of JSX is that it allows the creation of multiple small components inside a single file.
  - philliphaydon 4y ago
    > The saving grace of JSX is that it allows the creation of multiple small components inside a single file. That's definitely not the saving grace of JSX. As I said, every react project is soooooooo overly abstracted into the tiniest little components. It's no wonder people /think/ react is slow.
- Yiin 4y ago
  Doesn't change the point, but it's usually <a @click="doSomething">
- 4y ago

synergy20 4y ago

why is useEffect hook in particular that bad? I played with Vue and svelte and now a firm React user, mainly due to its ecosystem, for most products the slowness of React does not play a major role at all for me.

afavour 4y ago

My personal bugbear about pretty much all web frameworks discourse is universally stated things like: > People tend to compare these frameworks on things that don't matter - often it's performance. Performance matters in a lot of contexts. If you’re doing complex stuff performance matters. If you’re a public facing site depending in search traffic performance matters. I’ve ended up disliking React simply because it’s become this one size fits all solution that 90% of web development goes through without it ever being necessary. There’s nothing wrong with React itself but it’s often applied badly.

adql 4y ago

> People tend to compare these frameworks on things that don't matter - often it's performance. I think I reflect the entirety of the user base of the internet when I say "fuck you" (not you in particular, just the trend of shitting on performance so we have apps running like it is 70's and tape drives on our gigahertz CPUs) here.

bakugo 4y ago

> things that don't matter - often it's performance You're a react guy, alright.

0xblinq 4y ago

This thinking is why most SPAs are utter shit for the end user. Most developers are so happy about their ergonomics and how cool their tools are and don’t care at all the application uses 200M on your browser and every key stroke takes 200ms to show in an input. This also happens in the backend, but the difference is that the company país the price in the form of more infrastructure. But in the frontend is “free” so why care at all, right?

replygirl 4y ago
that's a problem with the choice to go spa instead of ssr or static, not the choice to use a framework with productivity benefits. with every major meta-framework working seamlessly with the popular serverless hosts, it's a wonder anyone takes spa seriously in any performance-sensitive context

deleted 4y ago

[deleted]

pharmakom 4y ago

JSX is overrated. Why copy HTML, which is a pain to write? I much prefer regular old function calls. Or even s-expressions!