The self-fulfilling prophecy of React
joshcollinsworth.com
joshcollinsworth.com
React isn't as fast as Svelte, but Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many.
React isn't as thin as Preact (or whatever other small library there is), but that means that React has more functionality.
React might not be as easy to learn as some other frameworks, but that's because, honestly, React chose the right abstractions to build, and those aren't always the easiest to understand. (Honestly, they aren't hard to understand either; it's a minor difference at most, but it is what it is.)
And honestly, if you were to build a big matrix of frameworks graded across all these categories, I suspect you'd find that leaders in one category almost invariably tank in other categories, for the exact reason that you have to make significant cutbacks in order to beat the tradeoffs that React made.
In programming language / library design, you can often "have your cake and eat it too" if you can find a better design. Better designs take years to invent and mature - jQuery came out in 2006. React came out in 2013 (7 years later) and I think it improved on jQuery in just about every way.
But now its 2022. Its been 9 years since React came out. As far as I can tell, clever folks have improved on how react works in just about every way in turn.
What deep tradeoffs are Solid or Svelte making in exchange for their speed? I can't spot any. As far as I can tell, React's virtual DOM diffing is pure overhead - so good riddance. Solid and Svelte use a different approach to deal with state (similar to React's hooks) that honestly I prefer anyway. Dealing with state in react is a mess.
Where do the new frameworks lose to React on any technical metric? Svelte is designed to be compiled, but lets be honest - in 2022 almost everyone is compiling our JS anyway.
Go ahead and build a matrix of frameworks if you want. The competition is fierce. Like jQuery before it, React hasn't aged well. I'd bet good money that react, like jQuery, doesn't come out on top.
The reality is that nobody cares what you use to make your webpage or app. It might take a while to dethrone python and react, but who cares? Make software using whatever tools you want. There's lots of jobs, and these things are super easy to learn anyway.
I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start.
Easy to convince yourself of this, but in reality what is the benefit of having to sift through even more applications and waste time to go through the processes just to say "oh by the way we don't use React, we actually use Vue, hope that's ok" and think that the candidate, expecting to be hired to do React will just be like "yeah sure no problem, I actually mastered all the frameworks so it's fine that you lied about what you use."
Fantasy land.
But as for your points in hiring -
First, there's no need to lie on a job posting. "We use Vue, but we'll hire people with no vue experience. Show us your react chops and we'll train you up".
Doing something like this will get you fewer, but better candidates. If I see a job posting looking for frontend devs where they use SolidJS, I know the team isn't just a feature factory. They're interested and invested in the search for better ways of working. And I know they're given leave to do so by management. Thats a great sign for a good working culture. And from the other side, the kind of people who apply to jobs like that are the sort of people who don't see programming as a 9-5 grind.
I've seen this play itself out a bunch of times. At a startup I worked at many years ago, we took a chance and built our own data pipeline on top of Operational Transform. So all user data was updated live, character by character in our frontend app. It was really cool tech. We worried it'd hurt our ability to hire but it did exactly the opposite. We ended up putting it front and center in our job ads because high quality applicants were super excited by the opportunity to work on cool technology.
It’s kind of like webcomponents (separate concerns by component, not by language), I wish webcomponents had been part of one of the initial steps of HTML.
1. The concept of HTML being for layout, CSS for design, and JS for interactivity has not been true ever since web apps became a thing, if it was ever true. It’s been a decade and a half at least since JS wasn’t integral to both layout and design. So separating HTML, JS and CSS into separate files does not actually “separate concerns” because the concerns overlap.
2) Placing in different files is not the only way to separate concerns. You can still separate concerns within your .jsx file. Encapsulate your JSX generation code into a separate function, set of functions, and you can achieve similar separation of concerns, while still keeping code that are intrinsically tied together highly co-located. If you really think that separating them into different files is critical, you can put these JSX generating functions into their own file that can then be imported into your main component file.
The fact that no library/codebase actually does this, indicates to me that separating HTML into a different file provides minimal to no benefit in a component based codebase.
Svelte has a whole host of similar and differing problems.
Personal opinion - I’d choose React today over the rest, as someone who built my own frameworks much like Svelte and Solid 5+ years ago.
jQuery has aged beautifully!
In case you or anyone else reading don’t realize it, jQuery aged so beautifully the APIs are now built into (or in many cases fixed/standardized in) every browser in C++.
Yes that means the downloadable version is no longer needed, but please keep in mind every time you use a selector (for those that don’t call them “selectors” anymore some basic examples: “#content” or “.dropdown”) in JavaScript, you’re “using jQuery”. Even the fetch API was roughly pioneered by jQuery’s Ajax helpers, and slightly refined and included in every modern browser.
To discredit jQuery for being redundant is exclusively a lack of knowing browser history.
For Svelte, the comment you replied to already said that:
> Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many.
To emphasise, this was also the reason why it took so long for it to get TypeScript support (and I'm still not sure if everything's properly typed now, which is a common problem with template-based languages, but let's assume it is).
Additionally, I think (but haven't worked with Svelte, so could be wrong) that Svelte is a lot harder to write unit tests for? As in, you can just use React's virtual DOM in Node without needing to spin up a browser. With a quick glance I don't see any references to testing in the Svelte docs.
Solid I'm less familiar with, but AFAIK its architecture requires you to put logic back into your templates again, with components like <For>, <Switch> and <Match>, presumably limiting what you can do. And I totally get that the advantages of Solid's architecture make that worth it, but usually, if you can't spot trade-offs in advance, the reason is that you'll run into them later, rather than that there aren't any. So I'm sure I'd find more if I were to actually work with either of these frameworks. And yet I might then still conclude that they're worth it!
I wonder why so many folks care about performance. I guess it's the only objective thing you can throw in someone's face as an argument.
But I think one of the major benefits of Svelte is a better mental model for state management. It hides the right pieces of complexity, while both React and Solid throw them in your face.
Its been shown repeatedly that application performance dramatically moves the needle on retention, eg [1].
Personally I care about it because using slow software makes me feel like I'm ill. And developing slow software makes me feel like I'm bad at my job.
Your users have spent thousands of dollars buying hardware that can run billions of operations per second. They do that in order to run your software fast. (If they didn't care about performance, they'd be using old hardware.)
Your users didn't spend thousands of dollars buying super fast hardware just to get you off the hook for doing good engineering. Slow software is a sign of sloppy craftsmanship. I hate it.
[1] https://helda.helsinki.fi/bitstream/handle/10138/273640/Mast...
When I'm looking at Svelte or Vue I care about developer experience way more than their performance compared to React.
If performance mattered as much as you're claiming, React would never gain traction. After all, Virtual DOM is pure overhead.
React’s performance has never been that great. The library is large (a cost you pay for even on tiny websites). Time-to-interactive is quite long. And I can count on one hand the number of times I’ve seen shouldComponentUpdate used in the wild. Most apps just do a full rerender whenever the state changes.
React performs well enough when websites are small, and by the time a website is big, people don’t want to change their framework. The users are asked to put up with vaguely sluggish websites. They often aren’t given a lot of choice.
I think users bounce from websites due to sloppy performance all the time. But dev teams have no idea how much it happens because it doesn’t show up on metrics.
And it’s hard to fix a big, slow react website like new reddit. As they say, you can’t fix a problem with the same thinking that created the problem.
This is absolutely true but 99% of React sites don't need the extra functionality if they've already accepted stopping supporting old browsers. Everyone who uses React should be testing Preact to see if their app works. It could well be a very low effort way to knock a few tens of KB off your bundle size.
But everyone uses React with the JSX compiler? I mean it certainly is a strength of React that you _can_ use it as a plain old library, but it's not the common use case.
I think the root of the problem with react is actually the community. The web community has not figured out how to maintain software. There is an unhealthy attraction towards new paradigms and tools and an unhealthy willingness to endure paper cuts. So many practices simply wouldn't fly in any other community. Skepticism towards new ideas and a stubbornness to resist change are very important attributes for any community. It ensures that when a change does happen it passes through a very strict filter ensuring only the best of ideas get through. Tools that are built will only be as good as the community. I believe React had a great opportunity to become something cherished, but the community had to take it to that direction.
> There is an unhealthy attraction towards new paradigms and tools and an unhealthy willingness to endure paper cuts.
Web developers (who are often maligned on this site) are both too eager to move to better tools... But also, not eager enough
> So many practices simply wouldn't fly in any other community. Skepticism towards new ideas and a stubbornness to resist change are very important attributes for any community.
Yeah, and hooks had a lot of pushback at the time. The new useEffect semantics are getting pushback. These are exactly what you are asking for.
What are you wanting us webdevs to... _do_, exactly? It seems anyone can come to Reddit or the orange site and rail against UI programmers all day. But if we sit down and explain the situation nobody is very interested to listen.
And when someone tries to make things better with a new take or tool they get shat on here with “hurr durr those JavaScript developers always jumping on the new framework of the week”
HN, where sneering at web devs always gets upvotes and somehow never gets old
On the topic, the latest kid on the block is deno. New runtime is cool, but having to rewrite userland is ludicrous. Now you have deno dotenv package, (inspired by node dotenv), oak middleware inspired by koa, semver, base64, a modern web framework... where's the end to this? Reinvent the entire node ecosystem and fragment the community?
Now I never blame the creators because they are attempting something, but if this takes off I will blame the community. People should be up with their arms shouting what a terrible idea this is, but that kind of critique is something that is missing from this community. One of the best things about the web community is their unconditional positivity, but that is also their failing. I fear people will jump on bandwagon and embrace deno with both arms, we will see a race to rewrite all the popular node packages in deno, companies will open positions for deno developers, new developers will be asking whether they should take the node course or the deno course, all until the next asteroid arrives.
The problem is, how do you ensure that a "very strict filter" is also a good filter? The best stuff gets caught up in those filters, because the best stuff looks like nothing the filter has seen before. Or it might indeed look too much like something the filter has seen plenty of times before and (rightfully) dismissed as unimportant. And in the end it is not so much a community embracing the best idea, but the best idea taking a sledge hammer to the community.
I like React, and I think it is improving quite nicely. But Svelte seems also an interesting thing to try out.
Svelte is so much more than just faster.. It's reactive to the core!, you don't need redux stores or whatsoever, no react-hooks with all it's unacceptable traps and edge cases, no CRA where a simple eject shows the mess it actually is.. I can go on and on. Sorry but IMAO React is totally deprecated, it had its time, but there are much better solutions now.
Just take a few days to dive into Svelte (or even better svelte-kit) and I doubt you'll ever want to go back to the ever mounting complexity React has become.
I've been programming professionally in React from 2014. In the first years it was great compared to Angular, but today I cannot think of any reason to start a new project in React.
Svelte has now been around for, what, 4 or 5 years (according to Wikipedia)?
How bad are the breaking changes to larger apps that are built with it? When I google "svelte breaking changes", I get results such as https://svelte.dev/blog/whats-new-in-svelte-september-2022
Foundational churn that cause deep and broad downstream impact can really slow down a team. Generally, backwards and forwards compatibility is a plus in my view and a tradeoff against it is worth being intentional about.
Have you looked at the svelte compiler? It's not as small and easy to reason about as you want to think it is.
React's functional components are a monument to concept over practicality, and the overall ecosystem is a hot mess.
Populating initial state should not be a difficult special case. Handling state changes should not be a choice of esoteric extras. These are just basic requirements of any reasonable application.
React got quite a bit right, and it seemed cool at the start, but at a certain point the enthusiasm for "concept" diverged from actual requirements.
What all these React spinoffs seem to be doing is unlearning the lessons encoded in the React architecture and replacing them with more magic by "helpfully" applying state changes immediately instead of in a controlled fashion. But this is going to create mixtures of old and new state, which creates subtle bugs down the line.
Discussions about VDOM also seem mostly pointless because it is clear to me most people's mental model of how React renders is flat out wrong. If you are redundantly touching the DOM, that means you haven't memoized your components, or you are needlessly making copies of the same state. All of these have far bigger performance implications. In fact, even without memo(...), React renders can halt early.
Quoting from the Use.GPU/Live docs, which is a true React extension with the same semantics:
"If a component renders the exact same JSX object as before, React will not re-render that child, even if the child is not memoized.
So there is a hidden semantic in React: when you construct a JSX expression anew, you are requesting that those children be re-rendered unless memoized. But if you reuse a JSX expression from before, you are implicitly giving permission to ignore any unchanged children."
This is crucial to understand when stacking context providers.
I don't get the sense that React derivatives have been used to build e.g. desktop-class apps. They mostly seem optimized for web sites.
While it is true that React does a lot of things at run-time instead of build time, this is necessary for building truly data driven apps. JSX is really Lisp quoting in disguise. If you can't recognize this, you should probably brush up on the fundamentals.
That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.
I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive.
I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.
That being said, it's a relatively small complaint.
I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.
No, some people actually get them and there are way much better alternatives[1].
1. http://intelligiblebabble.com/compose-from-first-principles/
In this example the second $ won't trigger the first $:
let a = 1;
let b = 1;
$: if (a > 0) { b += 1 }
$: if (b > 0) { a += 1 }
let a = 1;
let b = 1;
useEffect(() => {
b += 1;
}, [a]);
useEffect(() => {
a += 1;
}, [b]);
https://github.com/sveltejs/svelte/issues/6730
https://github.com/sveltejs/svelte/issues/6732
So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)
It's a shame because it's an otherwise lovely framework.
It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2).
The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally.
The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months.
Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction.
Great frameworks don't trap developers in local maxima.
Do you have any links where I could read more about this? Or examples?
A couple years ago, that feature used to work similar as useEffect, so I got used to use it for transitions, and now is biting my ass because the Svelte team are breaking my transition use-cases
I used to use "$" like useEffect, but now I don't know how to use it anymore
And Svelte still bites my intuitions when dealing with complex objects, most of the times I've manage solve it by separating the code into multiple components, but it's not clear why that happens
What Svelte is doing is simply covering up the flaws in your code by short circuiting an infinite loop scenario which has been coded into your app. This will have unexpected side effects, however.
That being said, I think useEffects is far too overloaded in React, and is currently used for completely orthogonal purposes.
At he very least it’s used for the following completely unrelated purposes.
1. Component setup and graceful dismantling. 2. Syncing with external state. 3. Running code specific to a certain prop being changed.
I think the React team would be highly justified if they created a separate hook for #3 at least. Maybe a usePropsChanged hook that is called when one of the props change, and provides an isChanged function that you can pass a prop to, to check if it’s actually changed (I’m sure someone can come up with a better design than I have in the process of writing this comment).
That would be a semantic which would actually allow you to avoid the code flaw that your code above includes, as opposed to brute force papering it over like Svelte appears to do.
So where should we try to draw the line at what is truly the kind of "app" that deserves this much JavaScript, versus a "glorified website" that management wants to see lots of interactivity/animations/etc.?
In my career, I've struggled far less with choosing a JavaScript framework for front-end interactivity, and far more with justifying how much JavaScript goes into Web experiences these days, without any concern for the end-user performance impact or other impacts that may not be as obvious, e.g. accessibility.
Assuming you're asking more along the lines of "how does it work internally?", these are my usual recommendations:
- My own extensive post "A (Mostly) Complete Guide to React Rendering Behavior": https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
- Related, "When does React render your component?", which looks more at the source level checks: https://www.zhenghao.io/posts/react-rerender
- Dan Abramov's "A Complete Guide to useEffect" https://overreacted.io/a-complete-guide-to-useeffect/
- Shawn Swyx Wang's talk "Getting Closure on React Hooks" that builds a mini version of React hooks: https://www.swyx.io/hooks/
- Rodrigo Pomber's excellent "Didact: Build a Miniature React with Hooks": https://pomb.us/build-your-own-react
React deserves credit for bringing fresh thinking into the JS framework space but there's a tremendous amount of room for improvement.
* = subjective and there are a few rare exceptions
Generally you should only need to memoize a few things, and if you find that your app becomes brittle due to the amount of memoization you’re doing you probably are not handling state in the right way. If you’re using Redux that’s a common reason for this; don’t use Redux (is my advice). And yes, I’ve worked on several large enterprise React apps at successful startups.
I think what OP was suggesting is that you don't have to memoize at every level of the tree / where it doesn't make sense.
“React isn't great at anything except being popular.”
When the rubber hits the road, React is good. There’s a hundred thousand tiny little facets of its design that all contribute its effectiveness in getting functional (as in operationally successful) results. I’m no React fanatic. I hate the bundle sizes, the weird quirks with hooks, the footguns with performance, etc etc. But it works, and the results speak for themselves. I recently hacked for two weeks on React, Node and React Native to produce a CRUD app for Chrome and Android. It’s no FAANG app, being hosted locally for the site that needed, no localisation, ugly code, barely optimized… but it works! It has served its purpose well with minimal bugs for months, saving potentially thousands of hours of tedious labour. With React, I can prototype and get results fast. I’ve tried Vue, Angular, Vanilla, Blaze/Meteor, EmberJS, and even tried my own custom framework based on MobX. None were as good for getting results. For a bunch of little reasons, React is just… really effective.
Sure good devs can learn any language/framework, but there is a learning curve and most write shitty code while unfamiliar with a framework.
Popularity is an important feature.
> “React isn't great at anything except being popular.”
So did you stop reading the rest of the article after you hit that sentence or what ?
React is really effective. And that makes it "great" in my book.
I’m arguing that they keep choosing it because it’s effective and markedly more effective than the other choices currently available.
As soon as you go any amount of complexity higher in your program two way databinding is pure poison.
Two-way databinding is the absolute very worst feature people took from Flex.
Specifically, imagine you a component that takes an arbitrary node to render. Just pass the node to the temple right?
Ha.
This api sucks -> https://vuejs.org/guide/extras/render-function.html
Compared to having “{node}” in react.
Do you mean a component that renders out to a node?
Or a component that takes in a node external to the component so it can render to that external node (as opposed to or in conjunction with a node inside the component)?
If the first, isn't this just the job of the component's <template> or jsx?
If the second, isn't this what slots are for?
Yes. Mutable vnodes is a huge mistake that I've done long time ago when I've tried to figure out how to write efficient diffing algorithm (2014-2015), and a lot of libraries copied that terrible idea without deep understanding why I've done it in the first place.
Making this distinction between HTML <form>s and React shows a clear misunderstanding of the programming model that React provides. It targets the platform in a native way. This is how React DOM, React Native, and libraries like Ink[1] work.
Interdependencies between fields. Toggling visibility, dynamically changing drop downs based on previous values.
They almost always require local and remote validation. Sometimes long running validation that needs to be triggered early so it’s done by “submit time”. If it’s not done the submit needs to wait.
Any and all invalidation based on changing previous fields. Adding explainability. Submission preview. Mixing multi-media with regular text values. Complex error messaging that sometimes requires interactivity (e.g. uploading images may have errors for image quality and it’s nice to have the ability to crop or re-center an image from the error message).
If you think my requirements are over and above, maybe, but if you care about user experience it’s critical.
If you think the forms I’m building are “overly complicated” and “rare”, I disagree. Almost all of the above even apply to one of the simplest/very common usecase: “What is your address?”. eg handling global addresses with ergonomic drop downs, postal code validation, previewing the address and asking for user input for normalizing the address, etc. Similarly very common use cases for forms, contact information with phone number and/or email validation.
Using web forms is basically impossible or at best user hostile in 2022.
No, because as a user your React "app" fails to serve my basic needs. Web forms work. (I don't care that they're ugly or don't fit your corporate style.) I also don't care that they made your life difficult as a programmer. Sorry.
P.S. I've done my share of frontend programming too, so I feel your pain. Kind of. But sacrificing user experience for developer experience is not the way of the future.
> But sacrificing user experience for developer experience is not the way
I think you misunderstand my last comment. It’s not “difficult to maintain ergonomic web forms”, it’s roughly impossible. I know that sounds facetious but it’s true. There are too many under-experienced developers or developers who don’t “want to learn” or respect front end development. As such what should be simple is almost always broken.
Three years ago I joined a team, their “relatively simple” (16ish fields) web form took 3+ seconds to load. I got them to add React (ie increase page weight) and lazy migrate to components over 3 months. We dropped time to interactive to 500ms (including the server latency), improvements got made in weeks rather than the previously scoped months reducing time on task for our users, developers were happier and users reported better feedback.
This isn’t the first time I’ve personally improved a “simple web form” with React, and I know of many such success stories. You can disagree with me. You can argue they were bad developers. You can argue you would never have fallen into those traps. You might be right. But my description above is very much the reality of a very many “simple web forms” and definitely true for all complex web forms. Using a framework is just the better default.
> No, because as a user your React "app" fails to serve my basic needs.
Could you elaborate? Is it the “JavaScript required” issue? Increased page weight? Something else?
Except the back button doesn't work right.
Author's opinion, and one I find very strange. JSX with TypeScript is one of the best features of React, it's a dream compared to Angular's awkward arcane syntax (that didn't have type checking until what, a year or two ago?).
I get that people don't like React, that's fine. But "React is popular because it's popular" is an intellectually dishonest argument. There are obviously good reasons technically competent people choose it for projects.
It might actually be popular because it's popular; that isn't necessarily a dishonest argument on it's own. But usually when something is popular because it's popular it's also technically competent to enough of a degree that it's good enough.
It's disingenuous to say that React got popular for no reason and now people just don't want to change. React-isms ooze all over everything that came after it. If it was just "meh, good enough" until something better came out, then why does Preact name itself after React and have a react-compat mode and base itself on JSX? If React was just "meh, good enough" then why does every other framework out there take inspiration from React and when React came out with something all these other frameworks came out with their implementation of that feature?
I'm currently doing Angular again and I hate it (especially combined with NgRx, why do I need half a dozen observables, reducers, actions, selectors, etc just to make a HTTP request?), it's a step back from React in my last assignment; React's functional style with hooks and react-query was a great combo.
I'm not saying it's the best, but it worked for me. For my next trick, I should learn Vue.
Although on the other hand, front-end fatigue kicked in years ago. It's just the same thing again; some forms, validation, layout/style and a REST API, just using the tool-du-jour. Sigh.
That's helped a ton with the frontend fatigue for me. All the benefits of a SPA without writing any JS.
So far I've not gotten to use that stack professionally, but I'd sure love to.
I distinctly remember when React came out, pretty much every framework out there had to pivot to incorporate at least one of the 2 major ideas React brought with it (or at least, these were the most immediately beneficial features at a time when IE was still officially supported). The virtual DOM and one way data binding.
One way data binding didn’t even exist as an option in any other web framework and it was such a breath of fresh air. In fact, competing frameworks used to strongly advertise the fact that they had 2 way binding and how awesome it was. And 2 way binding looked great in your toy TodoMVC app, but absolutely failed when developing applications for real world use.
And the virtual DOM was so much faster when it first came out.
I should have said "software engineering experience" instead of "professional experience".
I'm not impugning the author, but it does provide context as to why he may not understand React's design choices.
Somehow people think there's a lot of foresight and wisdom in JSX invention. There's just so many good properties JSX has. But JSX was merely an easiest solution to an immediate problem.
Think about how React was created:
1. DOM management complexity gets out of hand. You solve it by treating view as a function of state (great idea btw).
2. If you do it naively, it is going to be slow. You make it performant with VirtualDOM.
3. Now that you went with VDOM, writing HTML is a nightmare. You address it with JSX.
JSX is obviously a great replacement for manually written render functions. But you know what's even better? Not writing render functions at all.
Same with setState() vs MobX/VueJS approaches. setState() was (is?) a horrible way to manage state. But it was the easiest thing that allowed you to implement V = F(S) formula at the time.
setState() a cost, not a benefit. JSX is a cost, not a benefit. I wish people stopped praising it.
Technically you can use Vue as a library to add interactivity. It works ok, but you'll switch to compilation eventually.
Still in my opinion Vue strikes good balance between getting shit done and developer experience.
Svelte would be my next bet, I just don't have enough experience with it to recommend it.
Now, the community doesn't know about that. So when you tell them that there's a better way to deal with component state, they immediately get defensive: "No, setState() is way better, there's no magic, it's very explicit".
But setState() was a necessary evil, not a genius invention. They made it super-explicit because it was the only way they could do it. Not because of some great foresight.
Is it bad? Probably not. I bet it's tolerable. But why settle for less when there are better alternatives?
Proxies have been around for at least a decade (here’s a 2010 talk about it
)
React hooks have been around for less than half the time as that.
Proxies for setState would be a terrible idea in React for the simple reason that non state variables also exist in React functional components and have dramatically different behavior than state variables. Proxies would make them both look basically the same after initialization which would lead to a ton of bugs as devs lost track of which variable was a state variable and which one wasn’t.
> Proxies have been around for at least a decade
Having Proxy described in ES5 standard and having it supported in browsers is two different things. IE market share at that time was around 30-40%.
> non state variables also exist in React functional components and have dramatically different behavior than state variables
Stateful functional components were introduced in 2018 (React 16). I'm talking about 2011-2013.
JSX is easy to dismiss as a "hack to solve problems", but there was more thought put into it than is immediately obvious. It's no less a template language than other template language. It has trade-offs and advantages. At least it's not pretending to not be a template language like Angular's pretends to "just be HTML" even though it is very much not just HTML (and is closer to ColdFusion, to be unjust).
Facebook was using React in 2011, TypeScript was released in 2012 (and it's not like it was immediately adopted).
Even the predecessor tech I mentioned E4X, which were the XML extensions to ECMAScript 4, the "lost" JavaScript version, were built on static typing. The most controversial feature that killed ES4 was static type hints. ES4 never directly showed up in browser support, but it did impact web development as ActionScript inside Flash and ES4 had influence on Typescript's syntax. (In some fun ways JSX with Typescript is almost a "Revenge of ES4". It's a lot better than what ES4 would have been, but it's so heavily influenced by ES4 there's a family resemblance and clues that language design is always more evolutionary than revolutionary.)
(Not to mention that the functional programming languages like OCaml and Haskell which inspired the "MVU" patterns are all about strong static typing.)
Now there's a chance that they had another version used internally at least 3 years prior, but at this point we're just speculating.
But IIRC nothing in React docs at the time mentioned how great JSX is with static types. It was all about render functions.
For now I'm sticking to Occam's Razor and the idea that JSX was a hack to make render functions usable.
React was not built with JSX in mind. React was built with JavaScript in mind. JSX was simply syntactic sugar. In fact, JSX was entirely optional at the beginning and all the initial React documentation had examples with and without JSX.
https://web.archive.org/web/20131118055243/http://facebook.g...
The key point is that JSX being syntactical sugar on top of a system designed to return JavaScript is what makes it work so well with Typescript and Flow. The key insight here was that components should be described using JS and not HTML. JSX was invented as syntactic sugar to make this more palatable for scores of web devs who had only used HTML. It is this decision to settle on JS vs HTML that directly led to JSX fitting in so nicely with Flow and TS since those are designed with JS in mind.
JSX has tradeoffs, but is way better for DX and for writing stable code. I've also worked with handlebars etc, Angular (significantly) and various other back-end cludgey templating languages. Nothing is as good as JSX.
To dismiss my experiences as "Stockholm Syndrome" is mildly insulting.
I don't care about the grimy details of its origin story, I care that it helps me ship good products.
Not sure I understand this, or if I do understand it, I definitely don't agree. HTML's a tree. Function calls are a tree. They're similar in nature and they map cleanly to each other.
> Or how you can’t use some standard HTML attributes in JSX (because JSX doesn’t know the difference between a React prop and an HTML attribute). Or memoization. Or how there aren’t real conditionals, so you have to rely on short-circuit operators. Or how preventing infinite loops is your responsibility—even though there aren’t really loops, so you have to use array methods…you know what, let’s just move on.
These are natural consequences of representing HTML as code, and they help me understand the first quote a bit better. I still don't think JSX is bad. Putting flow control into the template language in the style of Vue, Angular, or even the supposedly logicless Mustache ends in a programming style that I dislike, where the dividing line between template logic and logic in the actual code isn't clear, and you need to refactor heavily when you reach the gaps in what the template language lets you do.
They're closer to failures of EcmaScript. Coffeescript and Ruby weren't ideal, but their syntactic sugar would have let you do (in ES-like pseudocode):
const TodosList = ({ todos }) => (
<div class="todo-list">
{
if (todos.length > 0) {
todos.map(t => <Todo key={t.id} todo={t} />);
} else {
<p>No todos yet</p>
}
}
</div>
);
Yes, this is a key point. Indeed, many other 'constructed artifacts' compose nicely as trees, and thus functional languages are a natural fit for defining them parametrically.
Very very poor reasoning. I have never thought to myself, man I wish this wasn't JSX and just normal Javascript, to myself in the 6 or so years I've been using React. It just isn't something that anyone should care about and it shows the author has probably been biased against React forever, for no good reason.
> rather than bits of JSX just popping up everywhere here and there.
I did see lots of codebase write jsx like this. So I hate it. I starts the journey of front-end from jquery, ejs, angular.js, react to vue. And jsx of react always feels like a bad step to me.
Yes, If you write jsx properly, then it is just as readable as a normal template. But somehow some people never get it. And react also never made any attempt to stop insane codebase like this to exist.
(And you'd better pray your previous codebase owner isn't one of these, or you are in a big trouble)
In valid ES, you have many options even if none is perfect.
With the "horrible" ternary operator:
const TodosList = ({ todos }) => (
<div class="todo-list">
{
(todos.length > 0)
? todos.map(t => <Todo key={t.id} todo={t} />)
: <p>No todos yet</p>
}
</div>
);
const TodosList = ({ todos }) => {
let todoContent;
if (todos.length > 0) {
todoContent = todos.map(t => <Todo key={t.id} todo={t} />);
} else {
todoContent = <p>No todos yet</p>;
}
return (
<div class="todo-list">
{ todoContent }
</div>
);
};
const TodosList = ({ todos }) => {
if (todos.length > 0) {
return (
<div class="todo-list">
{ todos.map(t => <Todo key={t.id} todo={t} />) }
</div>
);
} else {
return (
<div class="todo-list">
<p>No todos yet</p>
</div>
);
}
};
const renderTodos = (todos) => {
if (todos.length > 0) {
return todos.map(t => <Todo key={t.id} todo={t} />);
} else {
return <p>No todos yet</p>;
}
};
const TodosList = ({ todos }) => (
<div class="todo-list">
{ renderTodos(todos) }
</div>
); const Todo = (todo) => (
<div class="todo">
{todo.status === 'UNFOOABLE'
? <UnfooableError todo={todo} />
: todo.size === 'GIGANTIC'
? <TextBox value={todo.body}>
: (
<div>
<p>I've run out of creativity but just imagine this has more stuff</p>
<p>And that there's a good reason not to make this its own component</p>
<OneLineTextBox value={todo.body} />
</div>
)
}
</div>
);To me it sounds as if you just didn't like JavaScript: the statement vs expression distinction constrains all non-JSX code too, e.g. you need to use the ternary operator to conditionally assign a value to a const variable.
Similarly, your example functions have long multi-line expressions as bodies so for the small gain of not needing the curly braces and a return statement, you pay a huge cost of not being able to use any statements in your code.
No, all four are fine and most people use them in code all the time. They're not completely identical to ternary operators because they move the location of the JSX outside the place where it's used, which can make it harder to read the code at a glance.
> it sounds as if you just didn't like JavaScript
Yeah, I see that as a failure of EcmaScript, as I said in the first comment. JSX has to work within the unfortunate boundaries of the language.
> for the small gain of not needing the curly braces and a return statement, you pay a huge cost of not being able to use any statements in your code
That wasn't intended to be a meaningful part of the example, I was just writing the shortest component that let me show a particularly style which would be nice to have in EcmaScript instead of ternary operators.
Oh boy, now that’s some flame-bait. I don’t like JSX, and like the Author also prefer Vue over React, but I know a lot of people simply dislike other frameworks *because* they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
Count me in that camp. My take is that while JSX isn't perfect, it's less of a cludge (and much more flexible because it compiles down to JS) than the templating languages that other frameworks use. I'd love it if they'd add just a little bit more sugar to JSX though. Support for JS-style comments would be top of my list.
<Button
// id=“commented-out”
onClick={doSomething}
I can accept a template language for a major framework where I can count on decent developer tooling, but it's a hard turn-off when evaluating niche frameworks.
A Crank component (which is an async generator) feels very different from a React component. Likewise for a Forgo component, which uses closures for state and doesn't have automatic rerenders. Solid doesn't have components in the traditional sense at all.
Although the syntax they use for representing HTML is the same, the rest of the framework can have arbitrary design.
If you are seeing errors that are React specific, most likely means you just need a subtle tweak in your tsconfig.json.
I don't care for React one bit, but IMO JSX is the highlight of React. Everything else in React is pretty much just OK at best (and some not even that), and the development of React itself has been extremely slow with very relevant few features.
You're not supposed to write single components that span a thousand lines of code nesting pure javascript and JSX elements.
Even better if you can factor out any computation out of the JSX parts into selectors.
Let’s apply it to Excel.
Not the best community. Python’s is more active and technical.
Not the best at collaboration. Google sheets is natively collaborative.
Not the best at charting. Tableau is superior and much more powerful.
Etc.
But it doesn’t matter. Excel is the best choice for most analytical users.
Excel may be the only choice for those who grew up without accessible programming around, but times change.
React is amazing in that you can build nearly anything in a mediocre way and it'll probably be fast enough. And when there are performance issues, there's a ton of resources and tools to figure out why and how to make it better.
That's not to say React has great performance. Everything in our field has performance tradeoffs. But on the whole, I think it's really disingenuous to say React's performance is bad. Python is orders of magnitude slower than Rust but for any use case where performance is that critical, you weren't fretting about language choice in the first place. If you actually had a use case where you're rendering a massive spreadsheet or lists with tens of thousands of nodes or some other wildly complicated UI, React can do the job if you really wanted it to, but why are you even fighting that battle in the first place?
Most UIs are boring. Dialog boxes. Forms. Tooltips. If your CTO is trying to optimize one of these UIs for sixty frames per second instead of thirty, they're an absolute fool and shouldn't be evaluating front end frameworks.
Can you post the proof you are referring to?
Here's some article about this topic: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-...
> Can you post the proof you are referring to?
The fact that applications which use 50M cycles to render text boxes exist and are very popular is proof in itself.
There is not a significant difference in the product if it uses 10M cycles (Or even less) vs 50M, as long as it is fast enough.
You know why VSCode is the leader? The tradeoffs of a little latency that can be annoying but mostly is unnoticeable is acceptable for all the added benefits the editor gives us.
But it doesn't matter. Cycles are not in shortage. CPUs are mostly idle. If something takes less than 16ms to complete, you simply won't notice.
That being said, solid is hardly the only one out there competing that can use JSX:
- https://github.com/vuejs/babel-plugin-jsx
- https://mithril.js.org/jsx.html
- https://preactjs.com/guide/v10/getting-started#setting-up-js...
I think people are starting to see the power of it when it's used in a functional manner (rather than early class-based components). A lot of alternate template libraries are only minorly different in syntax and use different styles of interop to handle the crossover. I think .svelte and .riot are fairly close, while still being somewhat html-like, rather than JS first.
I get the impression these things exist just to keep engagement numbers up
I do think it's fair to wonder what new frameworks ought to solve. Ex: As web GPU finally happens, we'd expect framework churn. Or, maybe it will be less about the framework, and more about the AI, or GIS+AR integration. Or some incredible tooling stack, like copilot is doing for autocomplete. Or maybe better multilplayer mode & collaboration. Just not smaller bundles and faster first paint.
Don't be ridiculous. I will not believe such kind of hyperbole without concrete numbers. In 2021, the Linux foundation had a $177M revenue. Does Vue's funding compare in the slightest?
I think not. Open Source success would be indicated by adoption. And "well funded" indicated by sustainability of the project.
And in thos regards, Vue is both very popular and well funded. And among open source projects of current era, it is one of the most well known one akin to linux and git.
PS: Comparing a 6yr old project with 22yr old one is hardly fair. Not to mention that linux is quite big in scope
Bizarre take. Market share may not be increasing, but this means that 8 of 10 new projects are currently choosing React...if that's not continued adoption, I don't know what is.
The objective time-to-profficiency has made React (and Solid which is quite similar to React) the most obvious choice for us, and I'm one uncomfortable with consensus. Svelte doesn't quite have the staying power of React or Vue yet. Since it's a superset of JavaScript, it's harder to teach, and the component frameworks just aren't there yet. Vue is great, but Vue 3 took a step towards performance and a step away from intuitive readability IMO- it's probably better suited to a team with homogeneously high experience.
How is it similar when React lets you write non-incremental algorithms when you working with your state and with Solid you are forced to write incremental algorithms? Simple aggregate (GROUP BY) use cases that your average junior developer will be able to solve in 5 minutes with React will be a huge problem even for experienced Solid developers. The only similarity is that it is also using JSX syntax, but with completely different semantics.
view: uhtml or lit-html (don't use lit-element)
action: DOM event delegation for intercepting anything happens on view
model: a global store passed to when custom element is defined.
update: list of [selector, f({model, view}] pairs passed to when custom element is defined.
---
Congratulation we now have a self-contained Elm architecture.
The way I see people using flexbox makes me cringe a little, too.
I think most people just don't understand how to get the most out of it in terms of creating user interfaces, and use "table" oriented thinking like percentage widths and media size queries to control overall layout.
I think you should use it the way that something like QT's BoxLayout and GridLayout containers work. Strictly using flex-grow and min-width, max-width and justify-content to control layout. I can design just about any interface with just these CSS classes, with very occasional use of the three properties above:
.VBox { display: flex; flex-flow: column nowrap; }
.HBox { display: flex; flex-flow: row nowrap; }
.VGrid { display: flex; flex-flow: column wrap; align-items: flex-start; }
.HGrid { display: flex; flex-flow: row wrap; align-items: flex-start; }
.Grow { flex-grow: 2; }I know the author pitched this as an idea to w3c a while back, but I don't know why it was rejected in favor of flexbox.
Working off your last link, the final "holy grail" example, with less style but the same exact layout: https://jsfiddle.net/Lpedja35/
You don't have to have a matrix with an artificial rank to represent this. I only need to specify the 1 and 4 rows once. I don't have to make a square and then decide how to divide it, which, is the "table thinking" I mentioned earlier. I just observe which elements need Grow and then design from the inside out.
Because 12 years after their idea was pitched Custom Elements still suck?
Just a tiny list of problems with them, with big consequences: https://twitter.com/Rich_Harris/status/1198332398561353728
> and template literals with tag functions like Lit
The whole field of programming has taught us not to use string-based programming and not to rely on regexps for parsing said string based programming to arrive at results.
Also. Why are you against JSX and React, but at the same time happy with such "standard" things from Lit like magical reactive properties and bullshit like ".value=" and "?hidden=" and "@click=" none of which are standard browser techniques.
> for choices like JSX that were made in the past when these standards weren't available yet
What standards? Very few frameworks want to touch custom components with a ten-foot stick. Yes, most can target them, but very few have the as the underlying abstraction because they are just horrendously bad.
Other reasons are that you have a lot of control over what gets re-rendered when using memoization, with the huge but that there a lot of foot guns. As well as it is easy to write terribly performing code in react, while it is really hard to write fast/good code.
With React you know it will work and scale (In terms of your organization) well. You cannot say the same for many other frameworks yet. For a company that has pretty generic frontend needs React is probably the best choice.
Technical merits are secondary concerns and only become primary when software engineers are empowered to make these decisions
Choice of tech stack falls somewhere middle or bottom of the list of things to consider when delivering a solution/product. Good enough is good enough. Other factors are far more dominant after a certain point.
Performance: Solid
Learning curve: React
Bundle size: ?
Scalability: React
Community and support: React
Financial backing: React
Developer experience: React
Hireability: React"Good enough, let's spend time considering other things instead: React"
It may no longer be the best at anything anymore, but it's a polished well-rounder that will probably be fine for the typical web app. Less cognitive load when you just use it and follow the herd.
When I was first getting into reactive frontend frameworks it was part of a time-sensitive project, and we chose Vue because we could basically just write HTML and sprinkle in the reactivity. This was back in the Vue 2 days before they made everything functional, and I still think that older Vue API is the most self-explanatory for people who already know HTML and some vanilla JS.
Learning curve: Hooks can be quite unintuitive for the React beginner. React's learning curve was far gentler when all components were classes and the lifecycle was simpler.
Personally, I can't stand writing JavaScript and prefer to insulate myself against the moving target that is ECMAScript by writing declarative UIs in ClojureScript + Reagent, which uses React behind the scenes: https://reagent-project.github.io/
There is some interesting new stuff on the horizon like Hyperfiddle Photon, which compiles network I/O for you. As for me, an old dinosaur, I'm tired of learning new syntax. Clojure the language has not changed since its release. Lisp has been around since the 60s. It will be around in another 60 years. For me, it is the 100-year language. I'm sure it's not the end goal, but I am willing to bet it will be a Lisp-like.
React keeps getting picked because it has an ecosystem. And that's the most valuable thing for medium to large scale enterprise jobs. Web developers are positively thirsty for abstractions that are powerful enough to get the job done without having to learn something new in 2 years.
In an industry of near perpetual churn for the apparent sake of churn, having something you can just cling to that does the job almost all of the time is great. You can focus on the actual problems you want to solve while someone else burns their time arguing whether you could solve them faster with Vue, hypothetically, in a spherical development environment where everybody on the team was already Vue experts.
Far more smoothly than if one were trying to change from React to another framework. All of my old class-based components still work under my React hook-and-function code.
Other frameworks have their own problems. Solid requires a custom babel compiler plugin. Some are new and lack components, placing a huge backlog to reimplement everything from scratch, just not worth it.
We need a framework that will not tie components and libs to itself, so they can be used with other frameworks or with plain ts as well.
That's why I wish web components would see greater adoption. Having worked through jQuery, Backbone, Sencha ExtJS, AngularJs, Angular 2 and React over the course of a 15 year career, It's frustrating when you can't switch frameworks because the cost to rewrite your existing components trumps the potential efficiencies of adopting a new set of design patterns and affordances.
Don't all of them do though? Like @babel/preset-react for example
Just write a function that returns an element.
Not templates, not an opaque resource bundle, not some whole other thing. Just code.
Bootstrap is a lot like React. You don't appreciate the "bloat" until you need it. Or worse, you recognize you reimplemented the wheel a dozen times without noticing and most of your "wheels" are polygons with a different number of edges.
Using any specific CSS - scoped or unscoped - for a particular component is not a good sign. This might not always be avoidable.
Vue has a mechanism for that, but you can't really exchange it for something that fits your needs. It's going to be there, trying to please you with all the features the upstream developers thought you'd need and you have to program around those feature.
I don't generally disagree. Component-level CSS is something I don't do all that often, but when I do, in Vue, I'm glad I can keep it in the same file (generally scoped). For me, it's easier to spot the edge cases (oh, this is modified, and here's where it's being done).
Even at the component level, you can see use system-wide offsets. "give me two times the usual margin to the right" may be a general rule, but for componentX, something needs to be three timex the usual margin, so... you can still reference a system-defined margin variable, but have that 3x override where it's needed.
Again, not something I do often but, imo, the Vue SFC style scoping makes it easier/safer to do when needed.
BackboneJS was MVC iirc? Don't remember if they had any notion of self contained component but it was very different from the MVVM paradigm react introduced.
No experience with Dojo so can't comment but I remember MVC being the paradigm with most mindshare before React became popular.
Introducing Svelte, and Comparing Svelte with React and Vue (2021) - https://news.ycombinator.com/item?id=32763509 - Sept 2022 (187 comments)
For me, who hires Devs and works with react daily, having an industry standard is wonderful. I still remember the stressful and heated days of the past. Where every 6 month a new framework came out.
Today, I can hire a junior developer and within 24h they contribute to the code. No need to train them for many months. This makes both lifes much nicer. I don't have to spend a lot of time training. And they feel like they are contributer early on.
Each project was so big, that I'm little in doubt about your statement "within 24h they contribute to the code". It could be your react apps are very very small or junior devs are very very good and probably shouldn't be called juniors.
Once you start trying to build complex, dynamic web applications that involve loads of state changing over time, and user and API interactions, it can get really messy and cumbersome. Think Gmail, Spotify, Facebook.
Now if you try to add other engineers to the project, without some sort of framework, it's difficult for them to understand what's going on, or to change things without cascading consequences.
The libraries used, as long as they have documentation and are supported and more or less widely used...that's fine, they're easy to learn. And if I have to switch between 10 different projects, then for me that's the actual problem, not the fact they have different architectures.
What has been a terrible experience for me, was when at two past companies in an attempt to "standardize" they ended up with custom in house libraries and wrappers, all of them built in house, undocumented, with the original developers already gone and nobody knowing/wanting to touch them. And then the rejection of any kind of improvement or modernization because "then that new app will have a different architecture"... So what? We have a terrible one, and we need to do every project terrible, so everything is consistently terrible.
"React is amazing but it won't live forever. It's hard to imagine what the framework that takes its throne will look like but it will probably look nothing like what we've seen before. Either way, React can't be the end. There will be a next framework."
So far that hasn't manifested. Vue arguably took some learnings from React but it feels more like a step back than a paradigm shift in some ways (not that that makes it bad, mind you). Remember that React took its throne from Angular and remember how Angular looked at the time. That's the kind of change we're looking for.
Most React developers I know know that React will go away eventually and that they'll switch to something else at that point. Mind you, they all didn't start out as React developers, so this isn't their first rodeo. But that new "genre defining" framework (as the article puts it) just doesn't exist yet, or if it does, it hasn't gained any real traction.
"The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing."
This post concedes that point in the first couple of paragraphs. Much like C and Unix-like systems, this is why React isn't going anywhere. Indeed not based on the competition it has now. The best its competitors can do is convince React to steal their ideas and keep pushing toward doing 90% of the right thing.
With react you just need to remember to pass className instead of class and sometimes to pass key prop and you are good to go. Overhead is minimal. Since jsx is optional, you can write <Component value={1} />, {Component({ value: 1 })} or createElement(Component, { value: 1 }), which gives you so much control.
It was a breath of fresh air.
And I do agree that in every other metric Angular is worse.
However, I feel that developer productivity wise and team output wise, Angular is a safe and reliable choice.
I only wish there was some framework that has the tenets of React and the structure of Angular.
It is not like you need to only use one framework per company. There is a lot of melting-pot coding happening out there.
React was probably successful in part because it didn’t require a rewrite.
Nothing burns more than having to dedicate an additional quarter to a project because half the code you need to finish the task is sitting atop another API or, much worse, in a different language.
And when we're talking web apps, There's real material cost to the end user in using more frameworks than are strictly necessary. React is large, but it tends to be large with a spanning set of features that means you don't have to glom something else in alongside it.
>Besides JSX, React itself has its own bevy of unique conventions and trip-ups (not to mention two completely different syntaxes that are not fully interoperable).
But elaborates no further. Does anyone know which two syntax they are referring to?
- Good enough
- Easy to find developers for
- Extremely well supported with libraries for whatever you want to do
- Good enough.
I'm convinced it'll still be the top framework ten years from now. That better frameworks exist is just not relevant, the above are what matters.
So everybody learns React, because companies need more React developers, because development is too slow. Think about it, which developer would prefer framework/library that gets job done quicker and easier, but pays less?
It's the same with Java versus Clojure. Are LISP macros really the reason those Clojure devs seem so productive compared to Java bodyshops? Or is it the most talented devs going after exotic technology, and the less able going for the lowest common denominator?
There is a problem with people over using and abusing it.
And it’s not react’s fault.
Wired: Web Components
The adaptive interface system for modern web experiences. Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard Web Components. Standards-based Web Components are the foundation of each FAST component, making them compatible with almost any modern web framework, including those listed below.
So. Have they solved any of the issues listed?
> Google has the Lit framework is using it in Angular.
You've missed a few words in there.
yes, Google has Lit. And yes, Angular can be twisted to use them (but doesn't use them by default).
> Web Components are here to stay. I'd like to know what Rich Harris thinks about Web Components today.
Literally nothing you wrote answers my question.
And the answer is: no, despite the tweet being 3 years old and web components "not being ready for prime time then", none of those issues have been solved in the three years since.
---
Edit. As to what Rich Harris thinks about them now?
https://twitter.com/Rich_Harris/status/1518912939876618242
They're the past. Specifically, they took our best ideas circa 2010 and ossified them into the platform
https://twitter.com/Rich_Harris/status/1513638143584518154
I don't see any evidence of [fameworks will be transpilers to native web components in the next 5 years]. if anything, i think we'll see frameworks begin to explore the notion that 'component' is a purely author-time concept
etc.
Too much gaslighting from a parent as a child turns you into an argumentative person desperate to prove your version of event's because you're used to being dismissed in an unfair power structure (tinybuddha.com)
I will say I've been building Web Components lately and think they are elegant and beautiful and solve some problems in a neat way, but of course don't solve all problems.
Also this: Angular elements are Angular components packaged as custom elements (also called Web Components), a web standard for defining new HTML elements in a framework-agnostic way. https://angular.io/guide/elements
So. Have web components solved any of the problems listed? Yes. Or no. No buddha quotes.
The Guide to Accessible Web Components
https://www.erikkroes.nl/blog/accessibility/the-guide-to-acc...
Server Side Render Web Components: It's a common myth that you can't server side render Web Components.
https://dev.to/steveblue/server-side-rendering-web-component...
Using SVGs in Lightning Web Components
https://developer.salesforce.com/blogs/2020/07/using-svgs-in...
There are various work around for global namespace problems
You're welcome
What you hear is me asking a direct question and expecting a direct answer. All I hear in response is non-answers.
> to do research for you.
I wish it were research and not a couple of links you just grabbed from a quick Google search.
> The Guide to Accessible Web Components
Translation: the problem is not solved because Shadow DOM isn't accessible. Relevant quotes:
"""
Building proper UI Web Components can be quite a task though, especially if you want them to be accessible.
As the shadow DOM is completely encapsulated and isolated, it is also completely disconnected. It's almost like it's a completely different document like an iframe.
When one of both (the label or the input) is in the shadow DOM, they're in a completely different context. This makes it impossible to refer to eachother. This same dillema also goes for WAI-ARIA attributes like aria-labelledby, aria-describedby and other that reference an ID. You need either both elements in the shadow DOM, or both of them in the light DOM.
"""
I'll let you do the research further. The only "solution" on the horizon is manually adding more boilerplate Javascript to your components when Acessibility Object Model becomes available in the browser.
> Server Side Render Web Components: It's a common myth that you can't server side render Web Components.
It's not a myth. It's pure reality. Which you'd know about if you bothered to read the links you provide.
The link even states this clearly: you can't render them. You have to use a very specific set of third-party tools that jump through hoops to provide the DOM object on the server. This is not a generic solution provided by the platform, you have to buy in to specific frameworks for this to work.
> Using SVGs in Lightning Web Components
And here we see that you didn't even understand the question. No one said you couldn't render SVG from custom components. However, you cannot do this:
<svg>
<x-axis min="2000" max="2019"/>
<y-axis min="0" max="100"/>
<scatter-plot points="..."/>
</svg>
You'd know that if you had done actual research, and not spent your time attacking Rich Harris, or gushing how Google invests oney in some framework.
It sounds to me like you went down the Web Components path and became very disillusioned. That's good to know. Maybe my enthusiasm is misplaced. My goal is to keep things simple. That's why I refuse to use React, Redux, Node, Gulp, Babel, blah, blah, build pipeline. I'm not building a Facebook clone. That's not simple. We have different goals then. That's fine. Thanks for the info.
It sounds to me that all you can offer is demagoguery
> My goal is to keep things simple. That's why I refuse to use React, Redux, Node, Gulp, Babel, blah, blah, build pipeline.
Does it have anything to do with the question I asked? No.
This thread is on a post about React. I'm not even sure what you want from me at this point. To prove that Web Components are better than React because I said React is tired and Web Components are wired? The "The self-fulfilling prophecy of React" article says React is tired.
> It sounds to me that all you can offer is demagoguery
I'm not trying to persuade anyone of anything. I'm saying I like Web Components. I haven't built a start up around them. I'm sure they fall short in many use cases.
This particular thread started when I replied to your claim about Web Components. I posited a simple question: have the problems listed at the link been solved?
You spent an inordinate mount of time and words to avoid giving an answer. Hint: the anser is "no".
> I'm not even sure what you want from me at this point.
At this point? Nothing. About three replies ago I was still expected a clear honest answer.
Also, what would be a better alternative, since you don't like it? Seems like it's yet another technology HN loves to hate, but every developer I know likes it.
Personally, I like the movement back towards the web platform, browser standards, and web components. For many cases, these are more than enough.
If you got a different type of UI, I can see why React would not saturate your use case.
Jenkins is horrible. But it's by far the most ubiquitous ci/cd thing.
Terraform is less horrible, but still pretty bad. Yet it's impossible to work for any company that wants to do IaC and not use it.
If the Peter Principle says "incompetence rises to the top", the Poettering Principle should be "the most popular garbage rises to the top".
I see React as today's PHP... same terrible community, similar issues and also extremely messy code, yet if you dabble with it, you'll find a job where people just don't know any better.
I see it as today's jQuery.
I think React is more like Kubernetes. Not the simplest way to do things, but standardised, various gotchas designed out, lots of ecosystem, and plenty of people who know how to use it.
I recently spent some time learning Vue 3, and I’m a little less enamored. The composition API is nice for not requiring deeply nested code inside a giant object literal. But having my code littered with .value is ugly and a source of endless bugs. (You also don’t always need .value, such as when referencing a Pinia store. Ugh.) I looked into the pending “Reactivity Transform”, but it too introduces weird surprises and seems like its issues may be unsolvable.
Bottom line: I hope and pray for the day WASM allows Python to get a decent footing in the browser environment.
What I like about Vue is that you can work up a static design, then cut and paste chunks into single file components, add in a few :attr=“someVar” bindings, some handlebars, and you’re done with the template part. You can also copy and paste and rearrange the markup very easily. It’s a nice workflow and it makes it easy to see and manipulate the structure of the markup without having to think about the JS too much.
I imagine if you enjoy writing JS, then it makes sense to make everything a function and do it all in JS.
JSX is only appealing to a webdev community. Modern native react-like UI libraries are perfectly fine without XML-like syntaxes: Flutter[1], Jetpack Compose[2], SwiftUI[3].