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.
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.
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.
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.
“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
[+] [-] uk_programmer|6 years ago|reply
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|6 years ago|reply
'Modern' hiring practises cause a lot of problems.
[+] [-] gonzo41|6 years ago|reply
[+] [-] dutchCourage|6 years ago|reply
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?
[+] [-] jariel|6 years ago|reply
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|6 years ago|reply
[+] [-] JMTQp8lwXL|6 years ago|reply
[+] [-] zeroonetwothree|6 years ago|reply
[+] [-] rezeroed|6 years ago|reply
[+] [-] cryptica|6 years ago|reply
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.
[+] [-] jariel|6 years ago|reply
"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.
[+] [-] Plugawy|6 years ago|reply
Author here - I should have tweeted that instead of writing a blog post
[+] [-] collyw|6 years ago|reply
[+] [-] rainforest|6 years ago|reply
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".
[+] [-] pjc50|6 years ago|reply
Replacing a known solution with known limitations with a new, unknown solution which has no known limitations!
(... which means that there are limitations, you just don't know where they are.)
[+] [-] happywolf|6 years ago|reply
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.
[+] [-] jsilence|6 years ago|reply
Sorry, someone had to do it!
[+] [-] oftenwrong|6 years ago|reply
[+] [-] c-cube|6 years ago|reply
[+] [-] jwblackwell|6 years ago|reply
[+] [-] collyw|6 years ago|reply
[+] [-] asdfman123|6 years ago|reply
If you wanted to get fancier, feed a message queue into Azure Functions for the services.
[+] [-] antfarm|6 years ago|reply