Hacker News Reader

Comment by gentleman11 | Hacker News Reader

Haha. I ignored the web dev scene for a year or two to work on something else. Angularjs vanished and nobody will hire you unless you have worked with react. Rest is gone and everyone is obsessed with graphql. Kubernetes really took off. React alone isn’t enough though, it’s nextjs and everyone is looking into trendy redux replacements now. Typescript is everywhere. Everyone assumes you can’t code your way out of a paper bag if you haven’t worked with their exact stack for one year longer than it has existed, even though it’s all incredibly easy to learn. Also interviews are even more nuts and irrelevant. It’s depressing that your relevant important skills don’t matter at all unless you are self employed

View on HN

When I started learning to code few years ago, tutorials were always, "how to create a blog ?" because it shows everything (authentication, crud, nested view, rights).

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 !

https://www.youtube.com/watch?v=Gzj723LkRJY&t

This is a wonderful comment. You've put into words what I've felt about the industry these past 10 years.

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.

This is not about a learning curve, I feel like you will never be productive with any of those javascript framework.

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.

> 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.

I've heard of a theory that says "A's hire A's but B's hire C's". The gist is that cream-of-the-crop interviewers actively look for open-ended-ness and the possibility that the interviewee may be better at things than they are, whereas less effective interviewers only look for people whose skills are a subset of their own (and by implication, design tests that only leverage the skillset they know, hence the "must have 5 years GraphQL experience cus I ain't got no interest in coaching you" attitude instead of "I am prepared to go out of my comfort zone and talk to people to get them up to speed on tech stack minutiae")

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've "fired" interviewers that were just wasting my time asking me about googleable trivia.

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.

I agree that good engineers can learn most tech fast, and that that is due to experience and not them being inherently smarter than others. If this is true though, how do you measure (non specific) experience? Maybe asking for 100 relatively easy but totally random knowledge crumbs? (some web, some unix, some networking, some functional programming, etc). It would be impossible to score high, but well rounded engineers could get more of them right. This might actually be a better approach than asking a few hard questions.

For me a good sign are task questions: suppose we have X with Y as a restriction. How would you accomplish Z?

> everyone is looking into trendy redux replacements now

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.

Totally! Wonder if people realize that the person who wrote a lot of these libraries (hooks) as part of the core React team wrote Redux before joining the team? Dan Abramov. Everyone soured on an older (worse) abstraction because the same engineer who build the abstraction thought about it longer and built better abstractions that were also easy to adopt. I think that’s super cool, and doesn’t quite fit the narrative that people are trying to paint here of “fad chasing.”

The speed with which Google moved things around 2012 was just stupid. Gwt to angular was fast and left basically no real migration path. Or recompense for having jumped on in the first place.

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.

> React has at least been steady.

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.

But you can still use that same class syntax when writing your components.

Yeah. I should have been clearer on that. React has been steady in that the same code mostly still works.

That or I've just been lucky. Very possible. I have mostly ignored the fuss over redux and friends.

I got more into "principles" than stacks recently and can fight might way telling performance optimization stories about stock market-connected microservices and so I get less question about stupid stuff like how you color a div using react vs angular.

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

> everyone is looking into trendy redux replacements now

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

I enjoyed it while I used it but my main issues with it were with the developer experience and how many files the logic was spread across: actions, action constants, reducers, etc. When you have to edit 4 different files just to add a loading flag then I feel like something has gone wrong. If it solves your problems and you’re happy though, no need to let anyone convince you to change!

You should checkout redux toolkit and it’s sibling rtk query - it solves these problems you mentioned really well and has been a breeze to work on a complex app with multiple people.

Also both of these libraries are from the official redux team.

Just a really happy user and has helped me tame the state problem.

On really big frontend apps, redux with 4 files becomes the easiest part of the day.

It may be verbose, but it’s the one thing that all the other devs won’t be implementing in some weird, proprietary way.

Redux vs. jank proprietary solution aren't the only options. For instance, a lot of what people use Redux for is fetching and storing API data, or managing cross-component state. A combination of react-query[1] and React context does the same in a much more developer-friendly (IMO) way. Again, not advocating for anything, just important to know what the options are.

[1] https://react-query.tanstack.com

Check out my Redux Toolkit wrapper, I think it makes working with Redux incredibly easy - https://github.com/bluedevil2k/ruffle

its global state with a bunch of ceremony. outside of things like the user session and feature flags its essentially useless and more error prone than its worth.

It's a bit bad if you're not using typescript—then it's entirely fine.

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)

It makes the different parts of your app more coupled than they have any reason to be, and it requires a ton of boilerplate.

The pushback I've gotten is that there's too much boilerplate.

I really like the boiler plate though. Everything is very specific

At my last company (a FANG) it was deemed too complicated/hard to learn

Both your point and the article one are valid. Your point reflects the reality of the market while the article correctly states that the most important skill of a software engineer is the ability to learn quickly (built on top of a solid background of computer science fundamentals). Most of today's new things are in fact just evolutions of old concepts slightly revised and adapted.

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.

> Everyone assumes you can’t code your way out of a paper bag if you haven’t worked with their exact stack for one year longer than it has existed, even though it’s all incredibly easy to learn.

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?

As a back end Dev it looks like build tooling has largely materialized into a few choices and doesn’t change as fast.

As a firmware dev it looks like all yalls crazy

Amen, the fact that articles like this need to be written is the reason that I have no interest in a web dev career.

So very true. :)

I have encountered little to no adoption of GraphQL in the wild. It really never blew up the way anyone expected.

YMMV: I see lots of job offers for Angular, just mostly in the Enterprise sector. The sort of places that also use Spring Boot on the backend.

Outside of that sector, I personally don't know anyone who would choose either - but it's definitely still a significant market segment.

Reply on news.ycombinator.com