Then javascript framework came out. It was so hard that they move to just a todolist tutorial because even the creator didn't know how to create a blog with their new cool tech.
Some blogger were still able to understand how to use it and release todolist tutorial with authentication to demonstrate authentication, session management and rights.
Then new cool javascript framework came out and now it was even harder to code, creators weren't able to develop a todolist because it was too hard so their tutorial was just a basic counter application.
Now with nextjs we are even a step further. The developers don't know how to use it (is it even possible ?) so the tutorials show just how to "start" an application, load css and how to create a route.
In just a few years we came from create a full application to not even know how to do a todolist. (Imagine form validation, it must be so hard !!!).
Everybody seems happy and very productive. It must be myself.
In 15 years we came from 15 minutes to create a blog with this old tech to a few days of work. That's a lot of progress we don't have to reload the page !
Complexity correlates strongly with onboarding. The more complex your framework, library, or tool, the longer and steeper the learning curve to become productive with it.
Yes, of course there is a learning curve. For react you will be a lot faster after a few month using it. And this curve is a lot longer than for rails(react and rails are just here for example here).
But it seems even after being a react god master you will still be x10 times less productive than an average rails developer for developing an everyday feature.
This is a very enlightening point, maybe because the creators of React can afford to pay for unproductive gods, and those crazy assumptions are accidentally embedded in their tools, unlike rails, which was built by a guy trying to solve problems in the optimal way.
The real issue is when such tools become the standard for everyone else, and this often happens because giant corporations have the capital to push their bullshit, just to make their hiring process easier.
As a candidate, I've "fired" interviewers that were just wasting my time asking me about googleable trivia. There are other employers willing to pay premium for experience over technology memorization.
I feel like this is a great bit of advice for interviewers and interviewees: for the interviewer, don’t ask about things that are easy to look up, and for the seeker, take it as a red flag if they do.
A lot of people are probably soured on redux forever (that's how these things tend to work) but they've done a really great job with their hooks based API and especially the redux toolkit/RTK Query. Getting started today using the toolkit is so much more straightforward and easier to understand that it feels like a totally new library. If you're still living in the old school redux world of trying to explain containers vs components, mapStateToProps, how to build reducers from scratch, how to organize ducks, etc., you really should take a look at the newer tooling.
I believe angular got better, but I didn't stick around to find out.
React has at least been steady. It has some parts that I'm personally in the camp is over engineered. But, I think that is more that the scene encourages highly engineered solutions. Reminds me a lot of the j2ee days where there was just so much ceremony on a basic ui.
The rest of the technologies you list are similar to me. Not wrong or bad choices, at large. Also not typically needed, at large.
Huh? I did a bunch of React work a few years ago when everything was classes. Then I went off and did other stuff for a bit, and when I came back to React, everyone was using hooks.
That or I've just been lucky. Very possible. I have mostly ignored the fuss over redux and friends.
Honestly, I ve done all the frameworks at various point, either they help touch your dom or clean your code, and now I teach noobs in JS at the bank to just do their own frigging well cut functions, around jquery and basta. The only thing I allow is a css preprocessor because that's a true progress.
There s so little to gain with a JS framework (I agree typescript is a good initiative tho) and so much to pay in time wasted. And God knows impatient idiots like to "migrate" "legacy", so the least surface you expose to "unmaintained framework", the least you hear those morons steering the company towards non productive migration work to get less than we started with :D
What's wrong with redux? I've been using it in my last 2 companies, it scales amazingly and I think that's one of the stack in react that I'm comfortable with
Also both of these libraries are from the official redux team.
Just a really happy user and has helped me tame the state problem.
It may be verbose, but it’s the one thing that all the other devs won’t be implementing in some weird, proprietary way.
It's a bit bad if you try to add a bunch of extra shit to it unless you really need that shit (e.g. Thunk).
The terminology's kinda bad ("action" for "event", especially, which also gives us junk like "action creator") which can make it seem more complex than it is.
(I mostly like it, for the record)
I really like the boiler plate though. Everything is very specific
Unfortunately the market is more driven by the latest FAD rather than rationality. I am of the opinion that the main responsables are WE, the software engineers. I have seen several times that SE in a position of influence will sistematically go for the latest FAD rather than make a rational choice (which in most of the cases IS the "boring stack") for the sole purpose of pumping-up their CVs. At the same time this is allowed by lack of competence and governance on the IT by the business. The bottom line is that our entire sector instead of progressing by leaps and bouds keeps on continuosly reinventing the wheel and makes only very small incremental changes and adaptations. The innovation and progresses in productivity that we had in the last decade pale with respect to the one that we had , just for example, in the nineties and are mostly due to an increase in processing power. And there is still much to be discovered: our sector is still very immature. In some way some of the experimental development environments that were available in the eighties were more advanced than what we have today.
Even if I am not a Ruby user and so my judgement could be superficial I have the impression that in the last two decades the only community that has consistenly tried trying to challenge the status quo and really improve productivity for our profession is in fact Ruby community.
Indeed, I see this a lot – complaining about lack of skilled workforce and not having trained anybody themselves so far or even talking to someone with different buzzwords in the stack. That's parasitism at it's best, isn't it?
Outside of that sector, I personally don't know anyone who would choose either - but it's definitely still a significant market segment.