Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately? Does this mean we are slowing down and things will mature? Hopefully. |
Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately? Does this mean we are slowing down and things will mature? Hopefully. |
So it seems people mostly settled on React. They're grumpy about it but it does the job and there seems to be no alternative compelling enough to complain about.
Even said there were almost no cross browser issues.
JS developers: hey here's an update to a library that's been around for 8 years HN: Why are there new JS frameworks every day???
Also HN: Why aren't people posting about JavaScript here?
Edit: I'd fix the formatting but it's not worth it, HN can't bother to interpret a line break, I can't be bothered to accomodate.
I understand it can be annoying to see posts you disagree with and dislike. Many people jump from that to a general image of the community as hostile to their viewpoint* - but the truth is that there's a stream of things for everyone to dislike here. That follows from the community being so large and diverse. (There's a longer explanation about this at https://news.ycombinator.com/item?id=23308098 if anyone cares.)
Fortunately most of your posts with this account have been fine, though I ran across some other recent ones that broke the site guidelines and were not ok:
https://news.ycombinator.com/item?id=36364904
https://news.ycombinator.com/item?id=36364823
https://news.ycombinator.com/item?id=36283716
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
* I've been trying to persuade users about this for years, though I'm not sure it's worked much: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Many of the competitors springing up define themselves in terms of React, either as an improvement or a foil. But if you're just trying to get things done, it's hard to go wrong with it - and in a practical sense, not a "nobody got fired" sense.
(Of course, even React itself has gotten fairly complex with Hooks, Suspense and the dreaded Server Components.)
What are some specific sites you've seen that adopted react and ended up worse as a result of it?
> doesn't have a "relatively small surface" any more, because even the React team doesn't recommend that you use "just" React
Isn't this evidence of it having a relatively small surface area that frameworks and other tools can build on top of, much like html, css etc?
React is just a better approach to building all-encompassing SPAs.
(We have no external webapps because my company, funny enough, builds a JavaScript framework!)
Svelte was first released in 2016 and has become bigger than its original creator, Rich Harris. It has quite a thriving ecosystem and a big community. The tooling around it is more mature than React's has ever been.
> surface is so small
I actually find the opposite to be true. React still has a relatively small API surface area. One-way data flow makes it easier to understand. However, a smaller surface means arguably less expressivity, so I think Svelte's bigger learning curve is worth it. You can learn about 90% of React in a weekend and be productive. You can learn about 20% of Svelte in a weekend and also be somewhat productive, but you need to learn about 60-70% more to use Svelte as it's intended, rather than as a React alternative.
I wouldn't be surprised to see some movement toward simpler but equally robust frameworks like Vue or Svelte.
I contract for a few companies and everyone seems to have a different take on the industry standard.
React may well be biggest, but I don't think it's possible dominance is the reason there are fewer framework posts on HN recently.
I think the reason these aren’t prominent on HN is because the community here is overwhelmingly skeptical of, if not hostile to, new developments and exploration in the FE/JS space… and because the FE/JS community knows that and is likewise reticent to subject itself to that.
That said, it is true that React is a formidable incumbent, and that quite a lot of the space has coalesced around it. I don’t think that’s set in stone, I even think there’s at least some churn coming sooner rather than later. But I don’t expect that to make huge waves on HN unless and until it’s well underway.
The React team has done a great job of being generic enough for a broad range of use cases. As new use-cases arise, someone can build a new framework to support it. SSR has gotten much more popular than the SPA style, and the core React team has moved to support it with server side components.
If they can continue to follow the innovators, React will continue to dominate the front end landscape.
This isn't far from reality these days
Irrespective of the merits of React, it is sad to see the monoculture that has formed around it. I get the same kind of vibes as I did back when Java was everywhere, and comp sci graduates used to have the impression that Java = programming.
AI is new and of interest to lots of people so its closer to a lifestyle post at this point than it is a pytorch post that most people would not even click on.
Why would things not be getting political?
I've been on here for 15 years and definitely feel phases when it seems like a lull because I am personally not interested in the current hype.
Side note: A few months ago, I swear I saw about 150 different databases I had never heard of on here.
It's solved by you going to the new page, reading every submission, and upvoting the interesting ones. Incentivize that.
People, definitely on reddit, are behaving very different as they see they talk to someone who has nothing to lose and where they cannot expect much in return; less warmongering, less dragging on about a subject I was done with 40 comments ago and only 1-2 downvotes max where people commenting a similar opinion under a known name or handle get 50.
For me a solution to try is random usernames and changing those when you get doxxed. Nicknames or the same handles across sites won’t work.
I think that was all mostly about the, very long overdue, burst of advancements in JS engines that IE was holding back for soooo long. Everyone wanted to make THE library that had the best, most efficient, DOM abstraction possible, while taking advantage of any new speed gains the competing engines would release every week. It was a pretty cool time looking back on it but, the competition in that space has stalled and what's left is good and boring enough to easily get by with on any basic project. It's still not great, but that's just how front-end dev work is.
They all had to go back to React for it to write code for them :D
Sometimes I wonder if anyone clutching their pearls about LLM stuff being able to replace them has actually done any real valuable work as dev.
For the next couple of years problems will not be technical but business and marketing. No programming framework is going to help.
I remember some people taking a little longer to adopt them either cause it wasn’t necessary or cause it didn’t click right away, but eventually everyone learned how to use em, and no one complains about them cause they’re just a tool you use if you use React (which is the framework of choice for most companies).
Honestly, the reaction I often see from HN around most frontend topics usually doesn’t match what the frontend and full stack devs I interact with regularly are saying. Don’t get me wrong, it’s not like we all love React and want to switch state management libraries every week; it’s that React is fine, the ecosystem is fine, and we specifically don’t use every library that comes out week after week.
But yeah, JS frameworks seem to have run their course. The corporate world appears to have settled on React. The new thing is, look what I did by futzing with AI.
Angular is officially deprecated, and the others are distant also-rans at this point. React Native has also almost completely taken over iOS development. Thank god we can all just agree on a baseline to work from finally.
We're using Vue here and missed the memo about it being an also run :)
I don't hate Vue and I wouldn't judge anyone for choosing it, but my question is... why? It just seems like that entire community is set on reinventing every React feature with a two year delay.
Snark or lack of knowledge?
That's just another hot take which makes no sense if you think about it. Being able to fit complex features into already existing abstractions is an even more sought after skill with frameworks than without. Frameworks exist to standardize architecture, not to mitigate skill issues.
This take really does not take into account the huge value added of 1) not having to roll your own SPA code and 2) the availability of a large workforce that is all familiar with a common design paradigm.
Every time I bring this up the common rebuttal is immediately quitting, something like: "I tried it once and it was tough, so therefore it can't be done". That just screams skills deficit.
Vue was also ahead of React on some of the features they share if I'm not mistaken.
It knows about that stuff just fine.
No? You can build on top of a large surface area, too? Of course, the funny thing is, even if you are right and React has a "relatively small surface area" (relative being the operative word,) what good is it when the creators of the framework say that you shouldn't use that surface area directly?
> What are some specific sites you've seen that adopted react and ended up worse as a result of it?
I don't think you're arguing in very good faith, but one recent example is the Indian grocery delivery service bigbasket. They switched from mostly-server-rendered to Next, and the new version was downright horrid for a while, and is only barely usable now. The most cruel part of the joke is that the next.js version is currently only shown to logged in users, so you can blissfully shop for a while, get to the cart and then be hit with the awful new UI.
So, it going to be difficult to choose pure React with that kind of statement.
At some point you will have some state that transcends the UI and trying to shove it into React UI component does not make sense.
Like NextAuth.js -> Auth.js React Query -> Tanstack Query
So at the very least, I think we are probably headed towards a plurality where it is practical to use Vue, React, Svelte or Solid though I do hope Svelte “wins” in the end.
I have to say, I still don’t think it’s to the point where it can be foisted on a team of mediocre developers in some kind of enterprise setting. Some of the libraries that exist for SvelteKit that I consider super critical are very small and maintained by one or two people.
I recently took on some freelance work for the first time in like 6 years, just to work on another large SK codebase and saw a lot of the same problems I encountered approached differently. I think there’s some key things that need to make it into core still.
.. is the “Nobody Got Fired For Buying (IBM|Microsoft|Cisco)” for the 2020s
Long-time Java dev by background, used more frameworks than I could possibly list. I won't touch React with a ten foot pole.
SvelteKit is the first web framework I ever used that I enjoy working with.
It's a pre-formulated architecture in a box so that developers don't have to make those such decisions, most often because they can't. That is a supplement for an absence of skills, the same reason that made jQuery popular.
jQuery emerged from a lack of standardization and features in web browsers. It was a huge step forward and some of it's core features were standardized as extensions of the DOM interface (DOM queries are an example of this)
> most often because they can't
The issue isn't skill, it's a question of common architecure. A batteries included framework gives you exactly one choice for each part of your core architecture, which accelerates development because you don't have to worry about it. In addition, it saves you time and _immense_ costs on maintaining the core architecture of your app. React is a bad example due to it's simplicity, but take Angular or Ruby on Rails. Lot's of choices made for you, so you can benefit from the ecosystem.
Even eliminating/substituting one of those (underlying language) can go a long way towards making FP UI a nicer experience. For example, Reagent[1] in ClojureScript has a state management approach that’s conceptually similar to hooks, but it uses the language’s own reference type semantics in a way that makes it much less awkward. It’s still a challenge to integrate (JS) libraries with side effects, but the community does a pretty good job of wrapping the more popular ones in idiomatic functional APIs.
The concept that ui = function(state) is incredibly powerful if you can stay within the concept. It can have some performance downsides, but even those can benefit from a language/foundation designed for it (eg with Clojure[Script]’s persistent data structures).
A complex UI component will usually contain different aspects A, B and C. Each of these requires hooking into the component lifecycle in various ways.
In a class/interface-based system, you have to sprinkle parts of A/B/C around in each of the lifecycle methods. The only way to abstract and contain this is to make `<A>` `<B>` `<C>` subcomponents, which comes at a significant cost.
Hooks instead allow you to group the bindings to the component lifecycle by aspect instead. You end up making a `useA(…)` `useB(…)` and `useC(…)`, which can not only run directly inline, but can also pass values directly from one to the other, setting up a complex, unconditional reactive data flow in a handful lines of code.
In my experience when hooks go wrong it's for a few reasons:
- people don't understand how they should useMemo for derived state, and instead emulate the old way with useEffect/setState
- react doesn't have an official hook for stateful derived props (i.e. useMemo which has access to the previous value), which leads to a hundred adhoc solutions in every code base
- people order their components the wrong way, nesting a source of truth inside a component that needs to derive from it
- sometimes, the side-effect free rendering model is a poor fit (e.g. mouse gestures, timers) because there is no guarantee every event is followed by a render... it's much easier to just use idempotent state changes on mutable refs here and tell the react core team to stuff it.
By the way, OO pretty much always implies retained mode UI. What React does it bring the benefits of immediate mode UI to a mostly retained world, and this is where FP excels, because you can use optics/lenses/cursors and all that meta-data-manipulation goodness to deal with mutations.
Derived state should be eliminated! If it can be derived, it’s not state.
If you aren’t trying to do derived state patterns, you don’t need to access the previous value. That’s a huge red flag. Likewise, “state” in useRef is a huge red flag. useMemo() is often a signpost pointing to bugs. If the useMemo cannot be removed without getting a different behavior in the application, that’s wrong—it might be slower, but the result should be the same with or without it.
It’s not a side effect free rendering model. Mouse interactions, requests, etc, are side effects; the pattern is side effect sets state and state defines the render. The problem happens when people try to “outsmart” this pattern and try to jump from side effect to outcome by subverting the state pattern, which makes them lose most of the advantages of react.
Any discussions around “triggering renders” or “preventing renders” before the component is behaving correctly are also big time red flags.
The problem is react keeps coming up with new leaky abstractions, instead of solid building blocks. Fashion is not a good way to do engineering.
You only need to learn how to put {varName} in svelte.