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.
135 comments
React is now the de facto choice and much less painful than past de facto choices, is my take on why. It has a mature and healthy ecosystem, and its relatively small surface makes it easy to learn and predictable, while declarative GUI in general is low on footguns compared to ye ol two-way data binding.
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.
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.
React doesn't have a "relatively small surface" any more, because even the React team doesn't recommend that you use "just" React. It's all frameworks on top of React like Next or Remix, and those are more complex, have many involved concepts and come with footguns. I have seen many, many sites switch to Next and completely bungle it, making the user experience worse than it was before the change.
(Of course, even React itself has gotten fairly complex with Hooks, Suspense and the dreaded Server Components.)
(Of course, even React itself has gotten fairly complex with Hooks, Suspense and the dreaded Server Components.)
> I have seen many, many sites switch to Next and completely bungle it, making the user experience worse than it was before the change.
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?
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?
> 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?
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.
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.
Another example is new reddit
You can still use just React. No one is forcing you to use Next or Remix
No one is forcing you, but the React docs say "If you want to build a new app or a new website fully with React, we recommend picking one of the React-powered frameworks popular in the community. Frameworks provide features that most apps and sites eventually need, including routing, data fetching, and generating HTML."
So, it going to be difficult to choose pure React with that kind of statement.
So, it going to be difficult to choose pure React with that kind of statement.
Even using React v5 without a state library for a large app was bonkers back then, regardless of what the library maintainers said.
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.
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.
How is it difficult? Tons of companies have profitable UIs that aren't using a meta framework. Just because the React team says "we recommend you do X" doesn't mean you have to do X. If they said, "you must do X" then yea, you should do X
I remember hearing exactly the same words about jQuery a decade ago. This is bias stacked on comfort using a bandwagon mythology as a qualifier.
Jquery worked for a world that was mostly html with some sticking a of JavaScript. In fact, it still does.
React is just a better approach to building all-encompassing SPAs.
React is just a better approach to building all-encompassing SPAs.
haha, I basically feel this way about Svelte/Kit. It's not mature, but the surface is so small and learning curve so pleasant that it's our go to choice now for internal webapps.
(We have no external webapps because my company, funny enough, builds a JavaScript framework!)
(We have no external webapps because my company, funny enough, builds a JavaScript framework!)
> not mature
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.
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 think Svelte has a much smaller learning curve, personally. If you know Javascript there's hardly anything to learn.
This is wrong in so many levels.
You need to learn useState,useEffects in react.
You only need to learn how to put {varName} in svelte.
You only need to learn how to put {varName} in svelte.
useState and useEffect are quite simple small elegant API. It does not mean it's very easy to use for newbie. Maybe like Lisp?
Oh sure, useState and useEffect are very simple. Your app built upon them, on the other hand…
You don't need to learn useEffect until you need to plug arbitrary js libs and components into react. That's the intended use of useEffect. Using it for anything else is usually a bad idea.
How can you "fetch something when your state change ?". It's the main use case for useEffect.
[deleted]
You can just trigger fetch in the function that does the state change.
Agreed, this is the correct approach. Overusing effects makes control flow difficult to understand and has many unintended consequences. The misuse of effects is so widespread the React team had to address it with Strict mode in React 18.
How is Svelte intended to be used that is so hard to learn?
[deleted]
I'm not a web dev anymore, I stopped right around the time hooks became a thing in React, and while Svelte was an exciting technology no big players had adopted yet. In fact the last thing I did for my old job was a little make-work exploration to test whether Svelte was was ready for them to use in prime time. My conclusion was that it was remarkably slick and empowering, but was not ready yet due to the lack of ecosystem support. It's cool that Svelte and its community has continued to grow to the point where it is a legitimate contender. I'll be honest, I never liked React very much and would love to see it dethroned, even though I have almost no stake in that anymore!
I’ve been working with Svelte very heavily since November of last year. It’s been a real journey with Svelte and SvelteKit over the last 7 months, seeing things change rapidly. I think one of the coolest things is that it has galvanized frameworks to become SPA framework agnostic.
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.
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.
> lack of ecosystem support
.. is the “Nobody Got Fired For Buying (IBM|Microsoft|Cisco)” for the 2020s
.. is the “Nobody Got Fired For Buying (IBM|Microsoft|Cisco)” for the 2020s
How's Svelte different from AngularJS 1? I have such bad memories that I refuse to touch any code-in-html framework with a 10 foot pole.
https://component-party.dev/
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.
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.
Doesn't sound like a very promising company if your own developers rather use a different framework than dogfood their own. Isn't that kind of admitting defeat?
We develop and sell a visual Diagramming library, not an SPA framework. There is no overlap.
Hold that thought. Many people are saying React has jumped the shark with the complexity of server components and tight coupling with favored frameworks like Next.js
I wouldn't be surprised to see some movement toward simpler but equally robust frameworks like Vue or Svelte.
I wouldn't be surprised to see some movement toward simpler but equally robust frameworks like Vue or Svelte.
Or SolidJS which uses Signals.
I actually really enjoyed programming with Qt in C++ using "signals and slots," about ten years ago for a school project. Perhaps it was ahead of its time.
I believe WordPress choosing React as its frontend framework of choice further solidified this point.
> React is now the de facto choice
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 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.
IMO a JavaScript revolution is quietly brewing. Today’s frameworks have gotten amazingly complicated and EcmaScript spec is gaining new capabilities at a rapid clip, so some of critical features for modern web dev is built in. This project is a great example of what’s coming https://www.arrow-js.com. I think the right move will become avoiding these large and complicated frameworks unless they’re truly called for.
I’m starting to feel the same way. React’s big selling point when it came out was that it was “easy to reason about”, and that was true at the time. With hooks, server components, and 10,000 different strategies for managing state and side effects, I can’t say React is easy to reason about anymore. We can do things now that were impossible back then, but now we need to do even more than that, and it feels like it’s time to take a step back and do something different. I don’t know what that is yet.
Hooks are particularly bad to reason about. I can't figure out why hooks seems to be the official Way, it just leads to a bunch of spaghetti functions. The old object-oriented approach might feel old and creaky, but OOP was invented for user interface. Functional programming, not so much.
Functional programming is excellent for UI in a FP context. It’s only awkward with eg React because it has to swim in a sea of imperative APIs—the underlying language, render target, and the world of libraries people expect to integrate with it.
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).
1: https://reagent-project.github.io/
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).
1: https://reagent-project.github.io/
The why of hooks is actually easy to explain, it's just that nobody does it.
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.
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.
Almost all of the issues you’re pointing out come from misunderstandings about derived state and side effects.
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.
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.
> people don't understand how they should useMemo for derived state, and instead emulate the old way with useEffect/setState
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.
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.
Since the beginning, the way to solve derived state is to remove it from state—these patterns are both anti patterns.
Or emit events and have listeners for them. Something more similar to message passing and, incidentally, one of the original definitions of OOP.
Yes. Frontend development has always has been a pendulum swinging between "heavy server, lightweight client" and "lightweight server, heavy client". React brought us to the heavy-client side of things and I think the pendulum is about to swing back.
That, while well intentioned, is probably wishful thinking. Large frameworks do not exist to provide technology capabilities or features. They exist to supplement skill deficits in people, primarily around architecture and composition, and any such features are built upon the stylistic premise they provide.
> They exist to supplement skill deficits in people, primarily around architecture and composition
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.
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.
> Frameworks exist to standardize architecture, not to mitigate skill issues.
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.
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.
> 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.
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.
> They exist to supplement skill deficits in people
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.
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.
That is true, but it completely misses the point because rolling your own SPA is next to trivial. Things like state management, event delegation, and modularity are challenging without frameworks but only if you have never tried that without some large framework.
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.
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.
https://vanjs.org is another example in that direction. It illustrates that it's even possible to have a full-fledged solution of composing complex reactive DOM tree with just plain JavaScript functions.
This is already ongoing in the area of build tools. There's a big competition on efficiency right now, with the fairly light-weight Vite already being the de-facto standard for new projects.
That is trying to replace a framework but doesn't seem to do routing or data storage?
Arrow.js looks very interesting.
Definitely going to try it out.
It’s interesting seeing so many comments about stabilization around React. It’s not wrong per se, but it’s also not reflective of what I see from the FE community elsewhere. I see a ton of interest in newer frameworks like Astro. Solid has been growing at a steady pace. Qwik is gaining steam. Even older frameworks like Angular and Preact are evolving, eg adopting more reactive features. Vue and Svelte are going strong, albeit probably not gaining much new traction. And people are creating new frameworks (whether for education/demonstration or to introduce new ideas) or building new paradigms on existing ones (even on React, be it Preact Signals or Blockdom).
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.
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.
I think there are a lot of frameworks on the edge of viability, but the bar is a lot higher than it used to be for front end tooling. React(70%), Angular(25%), and a little bit of Vue.js(5%) is the market for front end positions with React owning the Lion's share. There are always new things being built, but being used is different.
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.
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.
HN posts follow tech hype. AI is hot right now. Another thing will come and take its place in due time.
AI generated crypto funded JS framework written in Rust
Web distributed AI singularity implemented in Rust as JS/WASM/WebGPU app with crypto infrastructure to gamify crowd-sourced training and use - not too far really..
> JS framework written in Rust
This isn't far from reality these days
This isn't far from reality these days
That's what makes jokes/conspiracies/lies/memes so compelling. Not that my comment was any of the above including compelling
Isn't it wonderful how we can just chain tech-mumbojumbo and it mostly sticks? Like if you posted about "Watermelonjs: a Mersenne-backed crypto-funded AI metaframework kitchen sink mocker template written in Umlaut" I'd wager a fair amount of people wouldn't even bat an eye.
Take my money
For a while, it seemed that a new JS framework was coming out every day. There was even a "JavaScript framework of the day" blog, which unfortunately I can't find now. But things really slowed down several years back... I want to say 7 years ago or so. React really does seem to have won, as the other commenters have said. It seems to be the main software taught by coding bootcamps and the like. I suspect that the confusion caused by the Angular 1 -> Angular 2 transition helped React gain the upper hand. There were other JS frameworks floating around that had a considerable number of users (including Ember, Meteor, and Backbone, off the top of my head), but they were nowhere near as popular as React or Angular. (That's my impression, anyway.)
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.
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.
I see a lot less programming topics, in general.
Lots of political opinion posts. There seems to be an influx of non technical people posting culture war nonsense.
As the site grows the number of people interested in any specific tech gets smaller while the number of people interested in lifestyle posts (politics being a major category of those) grows. Ruby and or Rust specific posts get much less upvotes and lifestyle posts get much more upvotes and the frontpage with its limited real estate becomes less and less specific tech related. The problem will only continue to get worse as the population of users grows.
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.
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.
Ruby still popup but you have to search for Ruby and sort by date.
The people who left reddit due to the API pricing had to go somewhere I guess
Sam Altman is testifying in Congress. Elon Musk is retweeting culture war BS all day. Tens of thousands of tech jobs are being slashed by CEOs as the cheap money tap gets turned off.
Why would things not be getting political?
Why would things not be getting political?
Me too, it’s pretty depressing.
the programming moved to the forums discussing AI technically, here it is discussed mainly AI tools
Yes, now it's full of LLM grifter type of shit.
Someone should do a GPT analysis of HN submissions to find and catalogue the HN-Meta. The meta being, the general rise and fall of sentiments / curiosities.
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.
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.
there are some weird phases that happen for sure. I've noticed the same thing with programming languages. There are periods where there is tons of stuff about functional programming and then it'll die down again for a while.
tbh i feel like many posts on HN shouldn't make it to the front-page. HN is filled with smart people with tech skills and I have a feeling many of them are gaming the algorithm for self-promotion. Even just getting your friends to upvote something is kind of disingenuous since it bias what should be more objective and we know that people do tend to follow others (social proof.) I don't have a solution. This is symptomatic of quite deep and complex issues. maybe someone will solve this one day.
>maybe someone will solve this
It's solved by you going to the new page, reading every submission, and upvoting the interesting ones. Incentivize that.
It's solved by you going to the new page, reading every submission, and upvoting the interesting ones. Incentivize that.
This feeling why I stopped using my real name (on most sites, not only hear). Upvotes or downvotes don’t mean anything to me as I have nothing to sell to you, not even myself. It’s at least far more relaxed for myself to not have to worry about things that don’t mean anything anyway, like upvotes, downvotes or some flamewar someone wants to start about a tiny opinion of mine; I can just get up/downvoted and move on. Don’t have to be pc either because of fearing for my job if my boss reads something.
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.
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.
Been that way for a few years I feel. My entire life was cutting-edge JS for 5 years straight around the trends peak. Now it's been a long time since I've come across another developer with a strong opinion about what framework/package manager/compiler should be used.
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.
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.
AI "frameworks" like langchain have overtaken the space JS frameworks took previously.
Nature is healing.
Yeah and it’s been like that for a while. I’ve been a bit confused by people here thinking that’s still a thing in recent months. Personally I stopped caring several years ago though, so maybe I just subconsciously filter it out
Every JS framework I have ever seen hit the front page of HN was well-justified in its use-case, and contributed something meaningful to the state of the art. There are a few now and there were a few then. There was never a plague, just people who really love bemoaning plagues from positions that would not have interacted with them anyway.
The hotter (as in more news worthy, not usage volume) thing in web is minimizing use of JS, using something like HTMX or Phoenix Liveview.
React is mature. The trick is to not get distracted by shiny things. I still think the whole thing is so overblown. There’s a lot of choice, great! That doesn’t mean you can’t pretend there isn’t.
GPT knowledge cutoff is eons ago in js time.
They all had to go back to React for it to write code for them :D
They all had to go back to React for it to write code for them :D
I think about this a lot. About how ChatGPT is perhaps cementing a lot incumbent tech right now. I wonder if the existence of these tools might actually slow down advances in frameworks, packages, libraries, etc...
I don't think about it at all. ChatGPT isn't able to actually do anything I actually need to as a software developer. Code is the easy part, getting good requirements from stakeholders and implementing it as business logic that meets the goals of various other internal concerns is the hard part. ChatGPT doesn't know anything about that stuff.
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.
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.
https://chat.openai.com/share/927a1d81-4a23-4c2c-b97f-36447a...
It knows about that stuff just fine.
It knows about that stuff just fine.
People keep saying that. However, in my personal experience, GPT-4 is great help at requirement gathering. I regularly give it sporadic meeting notes and text chats and get very well organized requirements back.
Whereas before I would Google something 20 times, and visit Stack Overflow 10 times per day while coding… Now I visit ChatGPT 28 times per day.
We need another Jobs to tell us React is shit and restart the cycle again.
Will an AI Jobs do?
Anecdotally the layoff wave appears to have hit design and front end more than other areas. Additionally it feels like the dev tools market, which fuelled a lot of new frameworks, is slowing down.
For the next couple of years problems will not be technical but business and marketing. No programming framework is going to help.
For the next couple of years problems will not be technical but business and marketing. No programming framework is going to help.
So what I’m getting from reading so many comments here… Did react hooks just totally alienate nearly everyone?
I'm not a fan of hooks (and the endless blog posts and opinions that hooks somehow were the invention of functional coding), but react server components did a lot of people in. The default expectations being that react frontends have a node backed isn't how much people use react.
Not a single frontend dev I know in real life has had the same negative reaction about hooks that I often see on HN.
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.
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.
I found a gut bacteria story here just the other day. Hackernews gonna hackernews.
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.
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.
React won.
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.
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.
A point of clarification: angularjs is officially deprecated. Angular is very much still being developed and used for new projects.
Did react win? Or did it become the foundation for Next.js?
We're using Vue here and missed the memo about it being an also run :)
We're using Vue here and missed the memo about it being an also run :)
>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.
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.
Isn't Vue quite a bit different? It's more of a framework than React is, with official packages for routing, state management, testing, SSR, SSG, building... It also uses a reactive data model, whereas React doesn't (though in practice it appears to).
Vue was also ahead of React on some of the features they share if I'm not mistaken.
Vue was also ahead of React on some of the features they share if I'm not mistaken.
The Dev experience and documentation is way better
Do you have a source on Angular Being deprecated? That’s big news that I’ve missed if true.
Google hasn’t updated the Angular 1 documentation since 2020.
Angular is officially deprecated by Google? news to me. Wow.
It's incorrect. OP has used wrong terminology and should have said angularjs.
“Angular is officially deprecated”
Snark or lack of knowledge?
Snark or lack of knowledge?
[deleted]
That's because React developers are not on hacker news anymore, they are all reading my newsletter thisweekinreact.com (wink wink)
Similar to Spring in Java, React became de-facto a standard having now a thriving ecosystem and an enormous community. This is actually probably the largest community if you compare it to any other framework or programming language out there.
There was a point where over half of them were React and everyone seems satisfied with that.
All of the JS framework posts I do see are about how they don't like React. There are two kinds of frameworks, the kind people don't complain about, and the kind they use.
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.
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.
Must be all the recent layoffs.
I wonder what will be the next mindless thing related to AI on which programmers will be wasting their days reinventing the wheel every 3 months. Langchain and such?
It's pretty hard to see anything but AI related content, so yes.
I met a guy who succeeded with just vanilla JS (or whatever they call it now)
Even said there were almost no cross browser issues.
Even said there were almost no cross browser issues.
Lots of template languages of the week though. As if software engineering didn't have recorded history.
JS developers: fairly progressive
HN: fairly conservative
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.
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.
Hey - 3 of your last 4 comments have been unsubstantive and/or flamebait and/or broke the HN guidelines. Can you please not do this? We're trying for something else here.
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...
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...
AI kills frameworks
When it was?