I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.
no thanks. I will stick with Rails.
JavaScript churns more than Rails which churns more than Elixir/Phoenix.
I believe this is caused by “how sound the fundamentals are” (technical debt in the language itself and its stdlib).
For better or worse, you can take 10+ years old PHP code and it'll mostly just work.
I rewrote it in React for fun and not only is it totally out of date, but Github's dependabot has sent me probably 200+ security advisories based on its dependencies.
Meanwhile, I've had the misfortune of inheriting a React application that would no longer build a mere six months after the original developer left the company. I've come to loath working on React projects due to the insane amount of library and tooling churn in that ecosystem.
Glad to hear those changes did not impact you re PHP
It's a lot closer in spirit to something like Phoenix LiveWire.
That said, I still use React and... it's at 19.x :'(
I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current js ecosystem. That doesn't seem very economic to me.
I've been using it for quite a while now. It has excellent mono-repo features, pnpmfile.js hooks, and it's just downright faster than NPM. Way, way faster.
I switched to it a couple of years ago, and it was definitely a breath of fresh air: no more waiting for 5 minutes for dependencies to install! I still find this to be the case when the odd create-XXX-app script finds itself using NPM.
[0]: https://github.com/pnpm/pnpm/commits/main/?after=5d1ed94e6c4...
What does dominant even mean in such a short term context? It hasn’t even been 10 years.
As far as companies go, we move so slowly that when someone brings up a tech fad, the fad is gone by the time the committee actually gets to decide. So we stick with the status quo.
I'm using bun now, but I was on pnpm for a while.
Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far.
Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't require server side rendering and their API backend can be anything.
In the latter model, you just host a bunch of static assets and point them to your API. No need for compute, everything is done client side (except API operations of course).
In the first model, you need to pay for rendering and it guides you into doing the API the same way. Closer to older PHP/ASP sites but on steroids.
This move caters to Next.js. IMO, as a lot of recent developments do.
I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead of relying on react-router. Once I got going on Next.JS everything turned out to be connected to Vercel. Even the tutorial at one stage expects you to sign up for a Vercel account. This really turned me off of React because there doesn't appear to be a single framework for people who want to build the latter category of web apps without either a) tying together multiple disparate modules/libs or b) signing up with 1 framework with 1 vendor. Either option doesn't appeal to me.
I shifted over to Angular (despite everything) because it seems to have finally stabilized and has a pretty good feature set for what I'm looking for. Plus build times on Amplify have really come down. Build times for similar sized apps take around 4 minutes(!) for React applications and routinely under and about 1 minute for Angular applications. I honestly just want a frontend framework where I can build a foundation fairly quickly and just get on with building features instead of worrying about if dependencies have suddenly been sunset or if the author made some breaking change to some key library I don't even interact with directly and right now this is Angular.
Vue with Quasar has been that for me. And previously Vuex-orm, now Pinia-orm. With a RESTful backend.
However lately I've been using React because of a graphql backend (I hate graphql) and it's a relay type graphql and the frontend relay library only works with React.
React itself is pretty easy to pick up. But Relay is a pain in the ass. Fragments, @arguments, @argumentsdefinitions, the naming is a super pain in the ass. And it's even more of a pain with Typescript and doesn't work with Javascript. Reusing queries is not possible because of the naming requirements. You can't just have a PostFragment, no you need to have a MainPagePostsFragment and a ProfilePagePostFragment and a PostDetailPagePostFragment etc. But I digress.
React has been surprisingly cute so far. But I've also just been with it for 1 version only, 18. I could imagine switching to it because of the ecosystem and because most frontend jobs are React jobs. You can easily embed it into for instance static HTML files, unlike Angular or Vue, keyword easily.
Angular syntax is beautiful, but the framework is too time consuming. I have recreated a real-time forum, which took about 3 years to build with Angular in 2 weeks with Vue.
Bottom line, Vue, for me, is the most productive framework. Angular, Vue and React are all very similar. Svelte is a bit alien, because of its state management and kit being the nextjs equivalent, but apparently the fastest because of the compiler.
But Angular is the worst in terms of backward compatibility and it has the worst state management too. It's like they took everything bad from React and made it a standard.
You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a problem using the back button or ctrl-clicking links while navigating GitHub - which is not something I can say of most other React and heavy-js websites.
That's.. basically every lib. Welcome to abstractions.
While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.
How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs.
Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods.
I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.
The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.
It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all))
Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power.
I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state
I think we still just haven't figured out how to build a UI toolkit that is both highly expressive to use and performant for complex UIs.
I think there are some really great ideas in hooks but it might take a new language built around them to make them truly ergonomic. The React compiler is a step in that direction.
(I know we _can_ use them still but it's hard to convince teams of people to stick with them and ignore what the docs say are best practices for the last five years.)
most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated"
effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now