[uk_programmer]

I shudder to think about the amount of man hours wasted on a relatively simple website that has been completely over-engineered with the likes of React and/or Angular JS when a simple server side MVC framework and a bit of jQuery could have sufficed.

The industry is rife with people that instead of looking at a problem and choosing the appropriate tech to solve the problem. They choose the technology and then try to solve a problem with it.

[arethuza]

While not disagreeing with your point, it is also worth noting that in some contexts developers are regarded as unemployable if they don't have experience with whatever the latest technology is so it is hardly surprising that people use every opportunity they can to get exposure to the latest tools.

'Modern' hiring practises cause a lot of problems.

[Ididntdothis]

That’s a real problem. I feel that me and my team have done serious damage to our resumes by solving the last few projects in a simple and straightforward way. Instead we should have done cloud, containers, React and whatever even if it made the solution very complex. This became really clear a few months ago when management two layers up gave one of our projects to another company who will move it to AWS. There were already plans for the transition and we said we could do it easily but the director decided that we have no experience and can’t do it.

My advice now is to always jump on the latest trend. It may make no sense for the business but it makes total sense for the devs. In many companies doing what’s right for the business will impede your career.

[collyw]

Do you think this is the reason for some of the supposed ageism in the industry?

I have been doing this for 17 years and I prefer server side rendering and jQuery to React / Angular plus some REST API I know it will take around half the code, and will be easier to debug and maintain. It doesn't make my CV look good though.

[uk_programmer]

I agree. Most of my colleagues think I am quite a decent JavaScript programmer, but because I haven't got much commercial experience with React or Angular it is quite difficult to find a JavaScript role.

[onemoresoop]

You can learn any framework and get good at even while on a project, in just a couple of months. The problem is that there are too many things to learn in terms of tooling and frameworks all the time making you have less time/bandwidth for the actual domain problems which are why you have the said job. Getting good is one thing and becoming an expert is another. Because these frameworks lifetimes you don’t want to become an expert over and over again on things that become obsolete because it takes a lot of energy and the payoff is short term.

[uk_programmer]

The problem I have with many of the modern frameworks is the tutorials is extremely simple or they are far too advanced.

Also there is a lot of jargon around each frameworks. So a lot of the time, I just give up and go back to jQuery, Handlebars and event delegation as that does 90% of what I need.

[onemoresoop]

That's why I am saying "while on a project". You have to create a project for yourself or join an existing project to make a framework like Angular click. Just aimlessly learning makes it much harder to make all this knowledge "crystallize", especially if it's the nth framework you're learning and the motivation's become low.

[uk_programmer]

I've worked professionally with Angular 2 and 4 and it just a PITA. People either just end up using it like the JavaScript version of ASP.NET WebForms or you end up with one guy that really knows it inside out and nobody understand the code he has written.

It hides too much of what is going on for my liking and if you break something a lot of the time it is impossible to diagnose without slowly pulling the code apart.

With just plain old JS I can always crack open the debugger and I am sorted.

[CaptArmchair]

It's a self-fulfilling prophecy.

Programmers develop new technology and paradigms to solve problems caused by existing technology and paradigms. As those new technologies are adopted, they are perceived to give an edge. And so, this creates a demand for experience in this new technology.

As time moves on, the impact of the new paradigm or new tech is getting better understood and the initial optimistic bias aligns with reality. Meanwhile, programmers develop new solutions to solve problems caused by... and the cycle repeats.

The problem here is that the problems that are being solved aren't necessarily new. It's just this foundational "how do you build a website or web interface efficiently" problem that underpins everything.

In a way, it's not much different from re-inventing the wheel. There are only so many specific ways of doing that before the entire exercise turns silly.

The bigger issue here is that - unlike tire manufacturing - the subsequent cycles of innovation are too short for a majority part of the workforce to keep up with changes. Why? First, because the complexity of those solutions creates a prohibitive cost for their employers to easily migrate on short notice and keep up with the cycle. Second, because the vast majority of new tech are just small optimizations in the real world with a limited impact on business making migration a risk and not an opportunity.

Hence why, once a tech has been chosen, companies stick with it for the long haul at the expense of individual developer experience keeping up with the innovation cycle.

That's what turns this into a self-fulfilling prophecy. The faster the cycle goes, the more tight the labor market becomes. That's why you'd see those crazy "Must have 15 years of React experience" requirements.

Finally, what we see is developers are being goaded into whimsical HR hiring processes that shake them down. In reality, it's not developers being "unemployable", it's the hiring process that's essentially broken as it is driven by individual business needs that aren't really that sustainable in the long haul.

When businesses lament that they can't find good talent, but at the same time reject the vast majority of candidates because they can't possibly be proficient in the latest cycle of hype technology (unless you're a core contributor to a particular framework or live a monastic life foregoing any and all other aspects that make life worthwhile living, that is), well, that's a form cognitive dissonance I would say.

As a developer, I feel it's important to keep an eye out of how things evolve, but there's little to no point in trying to keep up with the nitty-gritty at all costs without knowing if you're ever going to need it.

[Ididntdothis]

“The bigger issue here is that - unlike tire manufacturing - the subsequent cycles of innovation are too short for a majority part of the workforce to keep up with changes. Why? First, because the complexity of those solutions creates a prohibitive cost for their employers to easily migrate on short notice and keep up with the cycle. Second, because the vast majority of new tech are just small optimizations in the real world with a limited impact on business making migration a risk and not an opportunity.”

It seems the worst thing that can happen to you is to work on a successful, stable product. Almost by definition you will become an outdated dinosaur. To keep up your own market value you constantly have to insert friction by jumping on new stuff that doesn’t really improve anything.

[CaptArmchair]

Nobody cares how the pie is made. They simply want pie.

When it comes to new tech and frameworks, those who pay don't care if use React, Angular or Svelte. They only want a working product that provides value for money.

Losing business has little to do with the technology that's being used or sold, it has everything to do with the problem that the business intends to solve or the need it intends to cater. And how well it succeeds in doing that.

You don't become an outdated dinosaur overnight because someone comes up with technology that brings marginal improvements to the customer. You become an outdated dinosaur if your competition figures out a radical new way of doing things.

IKEA didn't roll-up the furniture business because it re-invented chairs, tables, beds or cupboards. It succeeded in doing that because it successfully marketed self-assembly as a convenience to it's customers, eliminating a big part of the production chain. Moreover, that - in turn - opened up the door to disposable furniture by introducing low-cost materials, and a faster design cycle that has come to a point that it defines furnishing fashion trends.

My point is that - as an engineering team - you could decide to switch to the newest framework, stay on edge in tech trends, and still miss the boat completely because business still sticks to an outdated model while customer behavior - wants, needs, trends,... - have already shifted a long way ago.

Put differently, it's still possible to build a Facebook/Reddit/Twitter clone based on the latest and greatest technologies and still fail because you expect to push those out of that market. Whereas it's viable to do the same thing, but only if you differentiate by catering to the needs of a specific market segment. Hence why you see platforms like Mastodon thrive without exponential growth, even though Twitter caters to billions.

A successful or stable product is by definition not tied to temporary trends. It caters to a universal need that people will always have. When the market is saturated and sales plateau, the trick then isn't to fundamentally re-invent your product. It's to use what you've learned and tackle an adjacent segment of the market with a new product or service.

In software the vast majority of companies are one-trick ponies that stick to a single product or service that's too specific, and doesn't allow them to expand to other areas. That's what makes them so vulnerable for either a competitor that brings true business innovation, or fundamental shift in what consumers want next.

Put more succinctly: people tend to rail against corporate, boring, byzantine constructions such as SAP. But that's exactly how they operate. They started out doing payroll and accounting, and they expanded from that by incorporating adjacent parts of business processes in their software such as logistics, material management and production planning. A corporation like SAP doesn't go along in the short-run hype cycle unless a significant game-changer comes along such as affordable cloud solutions.

Now, hiring for experience in specific technologies or frameworks only makes sense if you're going to hire someone for the long haul, whereas if the horizon of your business doesn't extend beyond the next 2 or 3 quarters, well, you're shooting yourself in the foot by rejecting good, well-motivated candidates based on them not having 5 years experience with bleeding edge FancyFramework2020.

[Ididntdothis]

”Nobody cares how the pie is made. They simply want pie. When it comes to new tech and frameworks, those who pay don't care if use React, Angular or Svelte. They only want a working product that provides value for money.”

When paying nobody cares about the tech. When hiring, all they care about is the tech.

[CaptArmchair]

Hence the cognitive dissonance I was mentioning in my initial reply.

[tdsamardzhiev]

Yep, that's the other side of the "resume-driven development" coin.

[gonzo41]

If everyone did do something like server side rendering with a sprinkle of jquery then we'd have this terrible issue of everyone going home at 5. And then the existential dread would start to creep in and that causes a lot more problems.

[dutchCourage]

It's a statement I see regularly on HN and that confuses me. Something like Next.js gives you the power and structure of React while doing a great job of hiding any complexity under the hood. And it scales really well, whether you need a complex website or just a set of static pages.

I'm not sure why jQuery is mentioned either. It was popular when I started programming but fell out favour when its major functionalities were implemented in ECMAScript.

What am I missing?

[uk_programmer]

In the past most websites were Rendered HTML from a language such as PHP / Java / C# / Perl and then they had a small amount of JavaScript over the top for interactivity and client side form validation i.e. when you submitted a form a full postback to the server was made. jQuery bridged the browser compatibility problem that existed at time. So most sites were built using jQuery + Server side MVC framework + SQL Database. Overtime more and more logic was pushed onto the client side (mostly updates via AJAX) and eventually JavaScript MVC frameworks were written to deal with the extra complexity. Angular / React etc are just the latest incarnation of these.

However much of the JavaScript written on those sites was done by back end programmers who didn't really understand jQuery or JavaScript and thus you ended up with jQuery spagetti code which others have lamented about. However if you were proficient with JavaScript at the time you could use a few JavaScript patterns and keep everything fairly clean.

This architecture while dated works incredibly well (minus the jQuery spagetti) for quite a few web applications. This includes everything from shopping sites, bespoke CRUD apps, Forms etc. However it isn't cool, it doesn't look as good on your CV and you actually have to really understand what you are doing to keep it performant.

[blackandblue]

still unsure i follow. i must be missing something... react does not prevent anyone from using jquery afaik. in fact, anyone can go ahead and use jquery with react if they want.

react is doing what php did a while ago (and is still doing). it's mixing frontend with backend stuff. i personally find it refreshing!

we did that for a while then people came and told us how bad it was and we needed to do strict MVC or whatnot. now everybody is doing it and it's cool again!

[uk_programmer]

> still unsure i follow. i must be missing something... react does not prevent anyone from using jquery afaik. in fact, anyone can go ahead and use jquery with react if they want.

React / Angular JS etc tend to require spending a lot of time learning how it works first. Then you have to build almost all your application around it. This can take a lot of time, which pushed up costs and complexity. If you are building something like Google Docs or Google Maps you want to build it like a SPA. For a lot of the sites I've worked on in the past building it as a SPA was completely unnecessary.

> react is doing what php did a while ago (and is still doing). it's mixing frontend with backend stuff. i personally find it refreshing!

We've been trying to get away from that for quite a while. I try to write almost all my JavaScript in a way that assumes as little as possible about the page structure, the web application etc. It can be done, however it requires thinking about how your markup works and how the page works.

Generally you should have good separation between your markup, your styling and your scripts.

> we did that for a while then people came and told us how bad it was and we needed to do strict MVC or whatnot. now everybody is doing it and it's cool again!

The problem is that it is cool again. I don't want my backend code tied to my front end code.

[qwerty123457]

React is easy as hell to learn nowadays, I'd say about as easy to get into as as PHP. Any semi-experienced developer will be writing production grade code after at most a week of learning.

[uk_programmer]

Is it? Because there is normally things like JSX, React Router, Redux and a lot of other stuff that you have to learn with it to build an application.

I've seen fairly decent backend developers having a right mare trying to get their head around just the npm tooling (no it isn't obvious if you haven't worked with it before).

People don't realise that there is a lot of the eco-system you have to learn just to do something fairly basic. You also have to unlearn things that you've done before elsewhere which itself can be difficult.

So I find this hard to believe.

Anyway this is going down the road of "why don't you use this it is easy?" which isn't the point I was originally making. I personally getting fed up of all the bloody tooling you have to learn to make something basic, when I can just ignore it and go back to basics.

[jariel]

So this isn't quite true for a few reasons.

Reach is quite a different abstraction than we are used to, it's huge and prolific.

It generally takes some time to get used to it. Though one might be able to do 'some production quality stuff' in a week, generally speaking, there's far too much that anyone is going to master in a week.

[wltprgm]

> 'm not sure why jQuery is mentioned either. It was popular when I started programming but fell out favour when its major functionalities were implemented in ECMAScript.

less than a year ago I was doing Magento, yea, jQuery is still there.

Now working on an already established Angular web and hybrid mobile apps, I saw jQuery symbol, and immediately checked it in the source, really surprised to see it there

[jariel]

The problem here is that it's actually hard to do a lot of what should be 'simple things' without all that cruft.

Web interfaces are unlike other tech layers in the sense that without tooling, it's often not 'simpler' it's diving into the cruft and weirdness of browserland.

React etc. are not just 'frameworks' they are also 'making something very hard to use, usable in a specific way'.

This issue exposes the inherent hidden complexity of browser weirdness.

If you really want to keep it simple, within some very specific parameters, and have enough experience to know what those are ... it's managable 'by hand' or whatever. But it usually gets ugly.

[edhelas]

Yes! Time to drop all those React/Angular/Vue… frontend tech! Let's go back to good old Javascript, dividing pages weight by 100, no npm, no complex rendering. We're wasting time in those tech, maybe Facebook needs it in some specific cases, but a large majority of the websites just need simple JS.

[JMTQp8lwXL]

Over time requirements and feature sets tend to grow, and if those features include client-side updates, with enough time you'll end up with jQuery Spaghetti, which is exactly what happened to many server-side render web applications built in the years preceding the early 2010s.

[uk_programmer]

Well I would argue that is because many of the developers writing those weren't really JavaScript developers. It is quite easy to keep things tidy if you just keep to some basic JavaScript patterns which aren't very different than some of the patterns promoted on the server side.

The problem is that JavaScript just isn't that well understood and this is partially because superficially it looks very similar to C# and Java.

[zeroonetwothree]

IME React leads to simple solutions far more than jQuery spaghetti.

[mosselman]

"Driving your car is far more safe while drunk than blindfolded and on cocaine"

You can sprinkle some jQuery here and there without it being 'spaghetti'. Also, how is having thousands of dependencies for a bit of HTML rendering 'simple'?

[cuddlecake]

You assume that all webpages are "a bit of HTML", which is imho an arrogant way to look at Client-Side web development.

[mosselman]

If you add up the lines of code that your javascript dependencies have versus the lines of HTML code that is generated with those hundreds of thousands of lines of JS, then probably yes, the lines of HTML are only few.

But to each his own.

[rezeroed]

Partly because we have to upgrade the CV.