6 ms·

The Industrial Hammer Complex

81 points by headalgorithm 3y ago

WJW 3y ago
> complexity makes a ton of money. Not for you, of course. Don’t be silly. It makes money for the cloud vendors, the evangelists, the influencers, and the whole industry that has spun up around these things. I don't like how this paints devs as blind followers without any opinion or agenda of their own. From my perspective many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends. The way an IC increases their income is usually either by being promoted or by job-hopping to another job with better pay. Getting promoted past a certain point is all about impressing your boss (or promotion committee in certain companies) and "developed a new architecture based on latest insights" is just inherently more impressive than "kept the decade old monolith online for another year". Similarly for job-hopping, hiring managers empirically seem more interested in people with modern tech stacks on their CV than in people who seemingly haven't learned anything in the last 15 years. Thus, devs have a strong incentive to learn and adopt new tech stacks and doing so during work time is clearly the most efficient way to do that. The jumps in pay between various levels (junior/senior/lead/principal/etc) can be incredibly significant. It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them.
- candiodari 3y ago
  This doesn't even just apply to developers. The same is true for managers, all levels of HR, ...
- TexanFeller 3y ago
  > many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends. I used to be more hesitant about whether it was a good idea to start out with microservices, then I started going on interviews. I would paraphrase the phone screens I was given as "Have you accepted microservices as your Lord and savior?". Call after call they wanted me to extoll the virtues of microservices before even considering me for an interview.
  - lumost 3y ago
    I wonder if this incentive is stronger at smaller startups. If I routinely work in small startups which are likely to fail, then spending time in aspects of the stack which are likely to be needed at future startups is a smart use of my time. Micro-services have fairly extreme upfront deployment/automation overhead relative to monoliths. This setup effort is common across many firms adopting microservices.
    - TexanFeller 3y ago
      I've for sure found myself thinking along those lines in the past. It's definitely possible it's a common enough thought to affect culture as you suggest.
  - whstl 3y ago
    Interestingly I had the opposite. The more recent interviews I did asked about the advantages and disadvantages of using monoliths vs microserviced, and how to overcome the common problems. I also had questions asking me how I would write frontend applications with and without central state management, or even for which cases I would start with a reactive frontend framework. In one of them I even had a huge disagreement with the interviewer. He still made a point to say I had passed. I think the main difference in this case was that I was interviewed by seasoned pros. When I had interviews with less experienced developers, the topics were as trivial as possible and just looking for confirmation.
    - eecc 3y ago
      I guess you and the parent are sampling the microserivce hype curve at different points in time.
- datavirtue 3y ago
  He didn't touch on the fact that the tech is predetermined by the hype. Most of us just have to work with whatever the CTO likes right now or whatever the team thinks is the "most modern."
  - brookst 3y ago
    I am jealous of your problems. Many of us have to work with the best obsolete tech that is still compatible with even more obsolete tech.
- lasereyes136 3y ago
  > It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them. Incentives matter, if you learn nothing else about economics learn this. People do things that they feel are best for them so companies need to align personal incentives with company outcomes or face sub-optimal solutions for the companies because the employees feel the solutions is optimal for themselves. With an average employee tenure at a company being a few years, how can longer term issues with software ever be a deciding factor for employees.
tudorw 3y ago
good observations and I'm in general agreement, sifting the genuinely novel from fish and chip wrapping is an evergreen activity, the article was a bit long though, maybe break it up into smaller chunks?
- dismalpedigree 3y ago
  You could make it a tweet stream! Its such a great format for when your entire thought thesis doesn't fit in 288 characters. /sarcasm
  - tudorw 3y ago
    i was thinking tiktok ;)
zokier 3y ago
Maybe its just my bubble but somehow I seem to encounter far more commentary railing against these sorts of trends than actually genuinely promoting them, nevermind people claiming them as silver bullets. As such I can't really empathize with statements like: > I wish I could say this was merely the problem our industry has, but it’s far worse than this. What we actually have is an industrial complex bent on manufacturing only hammers, committed to convincing you that only nails exist, and motivated to sell you a lifetime hammer subscription
- whstl 3y ago
  Microservices are definitely on the way down, but make any comment here or in a startup in the vein of "You don't need AWS/the cloud" and you'll see what's the real zeitgeist. SPAs also get a lot of criticism here at Hacker News, but talk to a team of frontend developers and you'll get puzzled looks for suggesting rendering HTML directly in your C# or Rails monolith. Please notice that I'm not criticizing or advocating anything, I'm just saying that there are trends and they're strong to the point of almost becoming laws. IMO this is what the article criticizes.
  - incrudible 3y ago
    SPAs get flak because some people have strong opinions on what a website should be, completely ignoring that many if not most software companies make client-server applications where the browser just happens to be the software distribution method, and none of the big web ideas matter. SPAs fit right into what already was there in the form of desktop clients. In that space, MPAs were a trend borne out of the limitations of the browser, but there is no reason to go back now.
    - red_admiral 3y ago
      Yes, for example drawio.com is an application that happens to have a version that runs on the web (not affiliated, but use it a lot). That's a very different situation from e.g. developer.mozilla.org, which is more text-centric and where being able to send someone a link to a particular section on a particular page is extremely useful.
Brendinooo 3y ago
His take on React as some kind of marketing-driven conspiracy just seems odd to me. React became popular because it solved problems that everyone in the frontend was having, did so in a way we could understand, and it did this so well that we were willing to put up with shortcomings like being forced into a SPA, CSS-in-JS, etc. We could jump in with just a little corner of our site or go all-in to a robust ecosystem that was continually evolving to meet the needs of the modern Web, and the resulting code was far more likely to be understood by a new employee than the bespoke jQuery soup that we replaced. And critically, this was all free and open source. No lifetime hammer subscriptions involved. No lock-in, no monetary sunk costs, so why not try it out? > I was deeply connected into the valley culture, watching what was happening from the Google side when it all started. It wasn’t money Facebook was looking for, it was talent and mindshare (i.e., power and control). ...Okay? But I'm guessing that most people who adopted and use React on a regular basis have zero interaction with Facebook or Google (the companies that is, not the product). I dunno. Seems like the critique is a hammer looking for a nail. I get the concerns about using React in places it doesn't need to be used, and I'm glad that the ecosystem has matured and innovated to allow us to keep what's great about React while also getting back SSR (though there's still work to be done here) and figuring out the best ways to work regular CSS into it.
- d0100 3y ago
  > His take on React as some kind of marketing-driven conspiracy just seems odd to me. To me it's so out of reality that it tainted his whole article Granted I'm not in the US tech scene, but I chose React because AngularJS was horrible (it took one project to never again touch it) and Backbone was arcane and confusing, and I really clicked with JSX
  - Brendinooo 3y ago
    Yeah. Pick your analogy: - React is the iPhone of the frontend library world. Not the first, some will never say it's the best, but it put things together in a way that resonated with people and organically conquered a ton of mindshare. - React is the Model T. Before the Model T there was a massively fragmented landscape full of mechanical wizardry and bespoke manufacturing. After the Model T the industry was larger, more consolidated, and standardized. I don't believe that React will dominate forever. But I do believe that, 50 years from now, people talking about the history of the frontend will view React as the defining thing from the era we're in now.
NorthOf33rd 3y ago
I was hoping this was going to be about this kind of industrial hammer. https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of-the-worlds-largest-counterblow-hammers-the-85-hammer-in-cudahy https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of...
OliverJones 3y ago
The most important sentence in this article: "Remember that you are a problem solver before you are a technologist." (Almost) everything we make has users. The most important criterion we have for deciding how to build things is "will it make life better for our users?"
- jagged-chisel 3y ago
  It took sooo much arguing on my part with the others on the frontend team about exactly this. “We can improve email validation on the client by shipping a TLD list with the other logic …” To what end? How does the additional complexity help the user? They can fat-finger any part of their email address and we can’t validate whether the user name should contain a g or h. Who’s going to maintain the list? So rather that listen to reason little ol’ me, we had to set up a meeting involving The Architect … He made the call that the complexity wasn’t worth the effort, that the UX wouldn’t be improved, and we shouldn’t add TLD validation in the client. That’s when they finally dropped the idea.
boredumb 3y ago
I think there was a point where the default was microservices+massive cloud infrastructure and it was a massive disservice to everyone. Everyone 'built to scale' and it's also easy to assume your next project will service a few thousand requests per second eventually and you'd love to just change the replica count in k8 instead of take the day to spin up some new machines and balance them when that time comes.
kodah 3y ago
This just in, a mans opinion is that others opinions are all made up! All kidding aside, life is full of choices just like programming is. It's also full of, at times, cascading tradeoffs. Following popular patterns isn't new to technical fields, even if they can have sharp corner cases. When your income is dependent on delivery then you'll often side with whatever presents a high-confidence score in terms of success. There are also very few definitely right decisions to make in software architecture and much more definitely wrong ones. How many times have you heard, "I shouldn't have used x full stack framework because I wanted to do y" or "I shouldn't have written x from the ground up because I could've used y". Many of these decisions you can only fully know what category they fit into after the deed is done. A lot of this derives from the fact that most of these things are learned on the job. There is no course you can take that will succinctly teach you to migrate a hulking, interconnected monolith to microservices or vice versa. You just have to have been the sad sap who's done it before and have enough knowledge of the standards and innards involved. What I take some umbrage with is just labeling everyone snake oil salesmen.
fnord77 3y ago
ugh. I'm going to guess this guy never worked on a microservice project in earnest. I work on two large cloud products. One is a monolith, one is microservice-based. The microservices and the connections between them are easier to reason about than the free-for-all connections and dependencies between components in the monolith. We have a far easier time adding new features to the microservice product. And somehow, the microservice produce requires less maintenance and is far more reliable than the monolith. I could go on and on, but then I'd have more own blog article
chrisco255 3y ago
> When Facebook introduced React, that act transformed the font-end space into a hype-driven, cult-of-personality disaster zone where folks could profit from creating the right image and narrative The author must have barely been paying attention to JS scene pre-React. The churn of tooling from 2010-2015 was far worse than anything since. A large part of this was due to the shortcomings of pre-ES2015 JavaScript itself. ES5 JS had no module system. It had no package manager. Even if you used server-side rendered PHP, Ruby, Java, or C# (the default in those days), JavaScript ended up becoming a massive part of any code base. What started as a few JQuery selectors adding dynamic/interactive behavior to forms would quickly evolve into an unmanaged mess of tens to hundreds of thousands of lines of code. I worked for an enterprise shop that pitched itself as a C# .NET stack, but when you analyzed the ten year old code base, we had more lines of JS than C#. When every page imported its own version of JQuery or some plug-in, even updating a package across your code base would turn into a hot mess (and might unpredictably break things, as each page independently managed its own dependencies, often imported from some CDN somewhere). The desire to build a SPA was rooted in the fact that none of these server-side languages had a good native way of managing JS. It was always treated as some afterthought that was injected into some god awful HTML template somewhere. The JS ecosystem had to create these tools, and there were lots of attempts at wrangling various parts of the architecture from Backbone, Ember, Grunt, Gulp, Bower, Knockout, Flight, Eve, Angular, Dojo, Closure, Ext JS, Moo Tools, etc (and more that I've forgotten) all pre-dating React.
- meekaaku 3y ago
  Oh. He is well aware. He created a JS framework called Aurelia. It is actually very good and was doing 'just write js' long before svelte came along. It is not that popular and hence lack the ecosystem.
  - chrisco255 3y ago
    I vaguely remember Aurelia. Didn't catch the author's name when I first read it. I used Durandal back in the day (which was a sort of Angular-like framework built on KnockoutJS), which he also created, before deprecating for Aurelia. So the author was one of the primary contributors to early 2010s JS framework churn and bemoans React "winning", I guess. Either way, after writing JSX components, I'm never going back to a proprietary HTML template syntax.
jsunderland323 3y ago
tldr of article; engineering is about trade offs. As humans we are susceptible to hype cycles and financial influences. Now let me tell you about a bunch of things I have personally decided are not worth considering the trade offs of under any circumstance.
Accujack 3y ago
I've always thought of the practice of salespeople selling software that "does everything" and "makes everything visible to management" as selling the metaprogram. The metaprogram is an all in one piece of software (or hardware) that replaces all of IT with a system that is easily understood and controlled by management, is relatively inexpensive, easily expandable to new purposes, and solves whatever problems the target company seems to be having at the time. I've seen IT department middle managers and CIOs try to do this over and over again. When a good solution to a problem is presented that's practical, affordable, and effective, their very next thought is "but what if it also did XXXX". I guess that's how they "add value" or something, by suggesting ideas that have already been discarded for reasons of scope, funding, or time. So far in my career I've seen salespeople use the idea of solving any pain points for the target company including reducing costs and increasing reliability by selling: * Desktop Microcomputers * Peer to peer networking * Dedicated internet lines (when they were still phone company lines) * Minicomputers (transition from Mainframes) * Java machines everywhere * Clustering software and hardware * Physical and virtual partitioning of systems * Thin Clients * Cloud everything * Containerized data centers ...and there are many more. I find it's mostly sales people and middle managers that benefit from the hype cycle. As with any new technology in any industry, things become part of the tool box. The main reason a lot of modernization projects get launched is the same reason that business re-orgs happen - they're a way for managers with no other ideas to show they're contributing.

81 points by headalgorithm 3y ago

WJW 3y ago

> complexity makes a ton of money. Not for you, of course. Don’t be silly. It makes money for the cloud vendors, the evangelists, the influencers, and the whole industry that has spun up around these things. I don't like how this paints devs as blind followers without any opinion or agenda of their own. From my perspective many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends. The way an IC increases their income is usually either by being promoted or by job-hopping to another job with better pay. Getting promoted past a certain point is all about impressing your boss (or promotion committee in certain companies) and "developed a new architecture based on latest insights" is just inherently more impressive than "kept the decade old monolith online for another year". Similarly for job-hopping, hiring managers empirically seem more interested in people with modern tech stacks on their CV than in people who seemingly haven't learned anything in the last 15 years. Thus, devs have a strong incentive to learn and adopt new tech stacks and doing so during work time is clearly the most efficient way to do that. The jumps in pay between various levels (junior/senior/lead/principal/etc) can be incredibly significant. It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them.

candiodari 3y ago
This doesn't even just apply to developers. The same is true for managers, all levels of HR, ...
TexanFeller 3y ago
> many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends. I used to be more hesitant about whether it was a good idea to start out with microservices, then I started going on interviews. I would paraphrase the phone screens I was given as "Have you accepted microservices as your Lord and savior?". Call after call they wanted me to extoll the virtues of microservices before even considering me for an interview.
- lumost 3y ago
  I wonder if this incentive is stronger at smaller startups. If I routinely work in small startups which are likely to fail, then spending time in aspects of the stack which are likely to be needed at future startups is a smart use of my time. Micro-services have fairly extreme upfront deployment/automation overhead relative to monoliths. This setup effort is common across many firms adopting microservices.
  - TexanFeller 3y ago
    I've for sure found myself thinking along those lines in the past. It's definitely possible it's a common enough thought to affect culture as you suggest.
- whstl 3y ago
  Interestingly I had the opposite. The more recent interviews I did asked about the advantages and disadvantages of using monoliths vs microserviced, and how to overcome the common problems. I also had questions asking me how I would write frontend applications with and without central state management, or even for which cases I would start with a reactive frontend framework. In one of them I even had a huge disagreement with the interviewer. He still made a point to say I had passed. I think the main difference in this case was that I was interviewed by seasoned pros. When I had interviews with less experienced developers, the topics were as trivial as possible and just looking for confirmation.
  - eecc 3y ago
    I guess you and the parent are sampling the microserivce hype curve at different points in time.
datavirtue 3y ago
He didn't touch on the fact that the tech is predetermined by the hype. Most of us just have to work with whatever the CTO likes right now or whatever the team thinks is the "most modern."
- brookst 3y ago
  I am jealous of your problems. Many of us have to work with the best obsolete tech that is still compatible with even more obsolete tech.
lasereyes136 3y ago
> It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them. Incentives matter, if you learn nothing else about economics learn this. People do things that they feel are best for them so companies need to align personal incentives with company outcomes or face sub-optimal solutions for the companies because the employees feel the solutions is optimal for themselves. With an average employee tenure at a company being a few years, how can longer term issues with software ever be a deciding factor for employees.

tudorw 3y ago

good observations and I'm in general agreement, sifting the genuinely novel from fish and chip wrapping is an evergreen activity, the article was a bit long though, maybe break it up into smaller chunks?

dismalpedigree 3y ago
You could make it a tweet stream! Its such a great format for when your entire thought thesis doesn't fit in 288 characters. /sarcasm
- tudorw 3y ago
  i was thinking tiktok ;)

zokier 3y ago

Maybe its just my bubble but somehow I seem to encounter far more commentary railing against these sorts of trends than actually genuinely promoting them, nevermind people claiming them as silver bullets. As such I can't really empathize with statements like: > I wish I could say this was merely the problem our industry has, but it’s far worse than this. What we actually have is an industrial complex bent on manufacturing only hammers, committed to convincing you that only nails exist, and motivated to sell you a lifetime hammer subscription

whstl 3y ago
Microservices are definitely on the way down, but make any comment here or in a startup in the vein of "You don't need AWS/the cloud" and you'll see what's the real zeitgeist. SPAs also get a lot of criticism here at Hacker News, but talk to a team of frontend developers and you'll get puzzled looks for suggesting rendering HTML directly in your C# or Rails monolith. Please notice that I'm not criticizing or advocating anything, I'm just saying that there are trends and they're strong to the point of almost becoming laws. IMO this is what the article criticizes.
- incrudible 3y ago
  SPAs get flak because some people have strong opinions on what a website should be, completely ignoring that many if not most software companies make client-server applications where the browser just happens to be the software distribution method, and none of the big web ideas matter. SPAs fit right into what already was there in the form of desktop clients. In that space, MPAs were a trend borne out of the limitations of the browser, but there is no reason to go back now.
  - red_admiral 3y ago
    Yes, for example drawio.com is an application that happens to have a version that runs on the web (not affiliated, but use it a lot). That's a very different situation from e.g. developer.mozilla.org, which is more text-centric and where being able to send someone a link to a particular section on a particular page is extremely useful.

Brendinooo 3y ago

His take on React as some kind of marketing-driven conspiracy just seems odd to me. React became popular because it solved problems that everyone in the frontend was having, did so in a way we could understand, and it did this so well that we were willing to put up with shortcomings like being forced into a SPA, CSS-in-JS, etc. We could jump in with just a little corner of our site or go all-in to a robust ecosystem that was continually evolving to meet the needs of the modern Web, and the resulting code was far more likely to be understood by a new employee than the bespoke jQuery soup that we replaced. And critically, this was all free and open source. No lifetime hammer subscriptions involved. No lock-in, no monetary sunk costs, so why not try it out? > I was deeply connected into the valley culture, watching what was happening from the Google side when it all started. It wasn’t money Facebook was looking for, it was talent and mindshare (i.e., power and control). ...Okay? But I'm guessing that most people who adopted and use React on a regular basis have zero interaction with Facebook or Google (the companies that is, not the product). I dunno. Seems like the critique is a hammer looking for a nail. I get the concerns about using React in places it doesn't need to be used, and I'm glad that the ecosystem has matured and innovated to allow us to keep what's great about React while also getting back SSR (though there's still work to be done here) and figuring out the best ways to work regular CSS into it.

d0100 3y ago
> His take on React as some kind of marketing-driven conspiracy just seems odd to me. To me it's so out of reality that it tainted his whole article Granted I'm not in the US tech scene, but I chose React because AngularJS was horrible (it took one project to never again touch it) and Backbone was arcane and confusing, and I really clicked with JSX
- Brendinooo 3y ago
  Yeah. Pick your analogy: - React is the iPhone of the frontend library world. Not the first, some will never say it's the best, but it put things together in a way that resonated with people and organically conquered a ton of mindshare. - React is the Model T. Before the Model T there was a massively fragmented landscape full of mechanical wizardry and bespoke manufacturing. After the Model T the industry was larger, more consolidated, and standardized. I don't believe that React will dominate forever. But I do believe that, 50 years from now, people talking about the history of the frontend will view React as the defining thing from the era we're in now.

NorthOf33rd 3y ago

I was hoping this was going to be about this kind of industrial hammer. https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of-the-worlds-largest-counterblow-hammers-the-85-hammer-in-cudahy https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of...

OliverJones 3y ago

The most important sentence in this article: "Remember that you are a problem solver before you are a technologist." (Almost) everything we make has users. The most important criterion we have for deciding how to build things is "will it make life better for our users?"

jagged-chisel 3y ago
It took sooo much arguing on my part with the others on the frontend team about exactly this. “We can improve email validation on the client by shipping a TLD list with the other logic …” To what end? How does the additional complexity help the user? They can fat-finger any part of their email address and we can’t validate whether the user name should contain a g or h. Who’s going to maintain the list? So rather that listen to reason little ol’ me, we had to set up a meeting involving The Architect … He made the call that the complexity wasn’t worth the effort, that the UX wouldn’t be improved, and we shouldn’t add TLD validation in the client. That’s when they finally dropped the idea.

boredumb 3y ago

I think there was a point where the default was microservices+massive cloud infrastructure and it was a massive disservice to everyone. Everyone 'built to scale' and it's also easy to assume your next project will service a few thousand requests per second eventually and you'd love to just change the replica count in k8 instead of take the day to spin up some new machines and balance them when that time comes.

kodah 3y ago

This just in, a mans opinion is that others opinions are all made up! All kidding aside, life is full of choices just like programming is. It's also full of, at times, cascading tradeoffs. Following popular patterns isn't new to technical fields, even if they can have sharp corner cases. When your income is dependent on delivery then you'll often side with whatever presents a high-confidence score in terms of success. There are also very few definitely right decisions to make in software architecture and much more definitely wrong ones. How many times have you heard, "I shouldn't have used x full stack framework because I wanted to do y" or "I shouldn't have written x from the ground up because I could've used y". Many of these decisions you can only fully know what category they fit into after the deed is done. A lot of this derives from the fact that most of these things are learned on the job. There is no course you can take that will succinctly teach you to migrate a hulking, interconnected monolith to microservices or vice versa. You just have to have been the sad sap who's done it before and have enough knowledge of the standards and innards involved. What I take some umbrage with is just labeling everyone snake oil salesmen.

fnord77 3y ago

ugh. I'm going to guess this guy never worked on a microservice project in earnest. I work on two large cloud products. One is a monolith, one is microservice-based. The microservices and the connections between them are easier to reason about than the free-for-all connections and dependencies between components in the monolith. We have a far easier time adding new features to the microservice product. And somehow, the microservice produce requires less maintenance and is far more reliable than the monolith. I could go on and on, but then I'd have more own blog article

chrisco255 3y ago

> When Facebook introduced React, that act transformed the font-end space into a hype-driven, cult-of-personality disaster zone where folks could profit from creating the right image and narrative The author must have barely been paying attention to JS scene pre-React. The churn of tooling from 2010-2015 was far worse than anything since. A large part of this was due to the shortcomings of pre-ES2015 JavaScript itself. ES5 JS had no module system. It had no package manager. Even if you used server-side rendered PHP, Ruby, Java, or C# (the default in those days), JavaScript ended up becoming a massive part of any code base. What started as a few JQuery selectors adding dynamic/interactive behavior to forms would quickly evolve into an unmanaged mess of tens to hundreds of thousands of lines of code. I worked for an enterprise shop that pitched itself as a C# .NET stack, but when you analyzed the ten year old code base, we had more lines of JS than C#. When every page imported its own version of JQuery or some plug-in, even updating a package across your code base would turn into a hot mess (and might unpredictably break things, as each page independently managed its own dependencies, often imported from some CDN somewhere). The desire to build a SPA was rooted in the fact that none of these server-side languages had a good native way of managing JS. It was always treated as some afterthought that was injected into some god awful HTML template somewhere. The JS ecosystem had to create these tools, and there were lots of attempts at wrangling various parts of the architecture from Backbone, Ember, Grunt, Gulp, Bower, Knockout, Flight, Eve, Angular, Dojo, Closure, Ext JS, Moo Tools, etc (and more that I've forgotten) all pre-dating React.

meekaaku 3y ago
Oh. He is well aware. He created a JS framework called Aurelia. It is actually very good and was doing 'just write js' long before svelte came along. It is not that popular and hence lack the ecosystem.
- chrisco255 3y ago
  I vaguely remember Aurelia. Didn't catch the author's name when I first read it. I used Durandal back in the day (which was a sort of Angular-like framework built on KnockoutJS), which he also created, before deprecating for Aurelia. So the author was one of the primary contributors to early 2010s JS framework churn and bemoans React "winning", I guess. Either way, after writing JSX components, I'm never going back to a proprietary HTML template syntax.

jsunderland323 3y ago

tldr of article; engineering is about trade offs. As humans we are susceptible to hype cycles and financial influences. Now let me tell you about a bunch of things I have personally decided are not worth considering the trade offs of under any circumstance.

Accujack 3y ago

I've always thought of the practice of salespeople selling software that "does everything" and "makes everything visible to management" as selling the metaprogram. The metaprogram is an all in one piece of software (or hardware) that replaces all of IT with a system that is easily understood and controlled by management, is relatively inexpensive, easily expandable to new purposes, and solves whatever problems the target company seems to be having at the time. I've seen IT department middle managers and CIOs try to do this over and over again. When a good solution to a problem is presented that's practical, affordable, and effective, their very next thought is "but what if it also did XXXX". I guess that's how they "add value" or something, by suggesting ideas that have already been discarded for reasons of scope, funding, or time. So far in my career I've seen salespeople use the idea of solving any pain points for the target company including reducing costs and increasing reliability by selling: * Desktop Microcomputers * Peer to peer networking * Dedicated internet lines (when they were still phone company lines) * Minicomputers (transition from Mainframes) * Java machines everywhere * Clustering software and hardware * Physical and virtual partitioning of systems * Thin Clients * Cloud everything * Containerized data centers ...and there are many more. I find it's mostly sales people and middle managers that benefit from the hype cycle. As with any new technology in any industry, things become part of the tool box. The main reason a lot of modernization projects get launched is the same reason that business re-orgs happen - they're a way for managers with no other ideas to show they're contributing.