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.
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.
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.
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.
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.
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.
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.
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.
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.
“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.
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.
”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.
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.
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.
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.
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!
> 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.
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.
> '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
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.
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.
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.
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.
"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'?
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.
Sometimes it requires a lot of thinking to come up with simple solutions.
Usually you need to consider a lot of alternative solutions in order to come up with the simplest solution and that takes time and a lot of thinking and a deep understanding of the requirements.
When I start a new complex project, in the early stages, there are entire days where I'm just thinking about stuff without writing any code. Then as the project moves forward, I spend less and less time thinking about things until I get to a point where it feels like the code pretty much writes itself because the design is aligned with my original goals.
You just have to be very clear about what your big goals are and where you're going to need flexibility from the beginning.
"Overthink it' first, and then smooth it down to its essential simplicity" is usually the process.
FYI the reason I don't like the musical analogy is because in that scenario, the tooling can easily overwhelm the creative process. You get caught up in the tools and literally never think about the problem.
I suppose a software analogy be might be using 1000x various frameworks to try to do something: you'd never get past the frameworks.
I think it's too easy to be sucked in by the promise of distributed X or eventually consistent Y.
In the past I managed migration of a few services away from Hazelcast as the team started peeling away the nice abstractions they'd become used to so they could handle things they hoped it would protect them from. All of a sudden a distributed lock isn't a lock if your cluster splits.
In the end almost everything ended up back in Postgres. Resistance was surprising - there was a lot of opposition to simple things due to a fear that the database would be harmed by being used to hold a few row locks, for example.
I can see why people overlook the obvious when the complicated solutions seem more sophisticated, which is easy to mistake for "better".
A lot of technologies are getting way more complex and confusing than necessary. Just look at the market of time management. Tonnes of tools, software, coaches, websites, books, etc. You name it.
I recently found out that a simple .txt file serves me exceptionally well (a good IDE plugin definitely helps, too!). No more messy software, apps, journals, etc. which I feel are making my time management tasks even more challenging.
Imagine a static website that provides crucial information, for instance, some regulation you have to follow. Your enemy MITM attacks that website and sends you a different page, which gets you in trouble.
The certificate guarantees that the information you are getting is from the entity who actually has access to the server serving the website.
even if you have something like a "donate" link that's goes to a third party payment processor. a MITM could redirect that link the their own paypal collections page.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
― Antoine de Saint-Exupéry, Airman's Odyssey
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.