I think it's pretty drastic to say "everyone here has imbibed" that Kool-Aid; I work in embedded, and am not super familiar with the frameworks he's complaining about, but I found the blog post entertaining nonetheless.

Sometimes I feel like the people who are deep down in this "full stack developer" land should come up for air and look around at the bigger picture. There's a much bigger world of software development out there and actually I think this post was kind of an attempt at that.

The web-facing industry seems to have dug itself down into a very deep rabbit hole of frameworks-on-frameworks-on-buzzwords, in a way it wasn't 10 years ago when I last played in that space.

It looks very weird over there from over here :-)

You should come join the fun!

In order to deploy a web app in 2020, one must write his frontend using react and typescript that would transpile the code into a nicely bundled and minified javascript and css files along with thousands of your 3rd party dependency libs. Yes, you heard that right! I just counted the number of libs on the node_modules in one of my small side project and it's over 1000s. You might also wonder why the typescript code would produce css when transpiled. That's because in 2020 we no longer write stylesheet directly into a css file. That's so 90s! We write the css as javascript objects now, then let the transpiler generate css from that. Isn't that neat?!

For the backend, you can choose one of the many cool frameworks and languages. Heck, why not use 5? In 2020 the backend should be written as a collection of microservices that talk to each other over grpc. Of course you still need http or how else would your react frontend talk to your microservices? So your microservices now talks multiple protocols, which is very cool!

Now pack each of those service into a collection of docker images, then write 4000 lines of yaml files to orchestrate them on kubernetes, and you're ready to go! Now you have a glorious, scalable app with 99.999% sla that can withstand your show hn frontpage traffic thanks to kubernetes, until you eventually screw up that yaml config and the whole house of cards collapse, but that's on you because you're bad at kubernetes orchestration!

I think we're indeed in a deep trench but damn it's quite an impressive trench we got here!

> Of course you still need http or how else would your react frontend talk to your microservices?

Don't forget GraphQL on top of that, otherwise you're not really in 2020.

I'm genuinely curious - do you really have to do all of that? Why not just ignore the frameworks and technologies that overcomplicate things and use what works best for you?

I am wondering why someone just hasn't forked etcd if it is truly so awful now.

Yes. If you don’t, and scp a Perl script to run under supervisord that meets the business requirement in three days instead of three months of microservices strategy, you are accused of being so hopelessly junior that you are unemployable.

I have witnessed that firsthand. Despite the anecdote being backend, I’d bet my 401(k) it’s the same up front.

Being a complete newbie on the scene a few years ago, the choice of frameworks and tools was so incredibly overwhelming (coming from C/C++ land). There are strong opinion pieces both for and against basically everything too.

When you are still trying to figure out exactly what HTML and JS should be responsible for, having React, Vue, PHP, Elm and many more as options for "just making a simple web page" can slow down the learning process by an order of magnitude.

I'm not sure what the solution is here- clearly each of these tools has a niche which requires them, but making a basic webapp without a web-engineering degree is quickly becoming an impossibility.

Forking is the answer, if you don't like the where a particular group is going with an open source project. Fork an old version, and perhaps you will find some others who prefer it that way.

Nope! The original group will sue you for trademark infringement, despite that they're the ones peddling a broken knockoff version. (See, eg Python, Firefox, GIMP, etc; I don't pay much attention to webapp-related stuff, so I don't have more proximate examples.)

So just give it a new name.

yes, but that generally doesn't stop someone from feeling annoyed.

While I do like cheering for annoyed people to fork projects it's not always practical for a number of reason like:

- The project is large and really requires multiple people to maintain.

- It's written in a programming language that the person is not familiar with, or interested in (they might even dislike it).

- License issues.

- Their work might prevent them from working on open source projects due to intellectual property concerns.

Unfortunately yes. I'm a freelancer so I have to keep up with the latest tech, at least just enough so I can debug issues when working on my clients' projects. You probably don't need to do this on your niche and can just keep using whatever stuff that works for you.

And here I am, making a career writing LOB web apps in Rails, and getting to MVP in weeks instead of months (or even years). Guess I'm really missing the boat!

My pet theory is developers crave challenges. If their project is not challenging enough to stimulate their mind, they will introduce more and more complexities until the project is hard enough to keep them intellectually stimulated. Thus, software development will never converge into a single tech stack as smart developers that got bored as hell working on crud apps will invent new stuff to make their work more interesting and meaningful.

In 5 years react and kubernetes will be considered legacy tech and we will march on to other new shiny tech.

Rest assured that I am firmly in your camp, and I've been tirelessly making the argument to policymakers that Big Web is not the resident innovative force in computing any more, despite the Obama administration's rapid adoption of their ideals and philosophy to salvage Healthcare.gov. In both the legislative and executive branches I have found many, many sympathetic ears who have been burned by ballooning budgets to handle public cloud and all the concerns that came with it, which folks who advocate for cloud-first deployment tend to overlook when addressing people who genuinely don't know (concerns endemic to Big Web operation of cloud actually need explaining when addressing a sector that's never touched it).

There is a watershed coming where Big Web/FAANG will lose this mantle, and DevOps, half-baked Agile because nobody ever bakes it all the way, framework engineering, and a complete fundamental ball-dropping around security and exploitation of user data are rapidly ensuring it.

At some point, Big Web/FAANG and everybody delivering Web services of some kind got the idea that the Web was computing. I think the prototypical version of this thinking led to Rob Pike's observations about systems research in the early oughts. This forum tends to operate with that underlying assumption about the lens to view computing through no fault of anyone in particular, which is why I say that.

What would you say is the "resident innovative force in computing" now?

I'm a little confused by the reference to healthcare.gov: if Big Web is not the right paradigm to handle a... big web site, then what is?

Perhaps I disagree with the implied assumption that a big web site was the answer. I don’t have an answer for you beyond that, because step one is challenging the increasing belief that Big Web has computing figured out and we need not evaluate the decisions and foundational technologies and delivery models that have led to where we are. Step one is a mountain, as you can imagine, and it’s possible to start the conversation of climbing it with only a handful of ideas of what could be over it. Many smart people with quadruple my intelligence and foresight have toed these waters throughout computing’s history. They just lose to hype and marketing.

I realize that’s an underwhelming answer, but if we asked that everyone who disagreed with the status quo simultaneously proposed a perfect solution to fix it, we would be nowhere in any sense. I assure you that thinking about the answer to your question is a significant part of my life, and talking to people who use computers to shape that thinking is key. Government was largely responsible for setting the computing agenda and spurring all of the right technologies in the beginning, and I believe there is merit to revisiting that thinking rather than ceding computing to engineers on the West coast.

At some point in the early-mid-00s we as engineers just "gave up" on the web as it was formulated as a document/resource transfer system with hyperlinking, and turned it into this ungainly mess of DOM manipulation, rampant RPC calling, database abusing, JS bound bloat. Finding the HTML document under the weight of ... stuff... on top has become impossible.

There were precursors to this... GWT was an early example of abuse of the web browser stack to accomplish something very non-webby. But it's really gone full bore now.

Back in the mid-90s when I made web pages for a living when some designer came to us with a photoshop mockup in a PSD and said "make the page look like this" we felt perfectly fine saying "no, the web can't do that. design for the web, not photoshop"; no such luck now. And so here we are...

You should also consider that the contrarian nature of HN would set it up to exactly the opposite reaction had the post expressed the reverse of its current positions. The big irony is that it's not inconceivable that it would involve some of the same actors voicing different opinions.

> "the incentives of modern software engineering value complexity to artificially strengthen a software engineering job economy"

Not sure I would agree. Hanlon's razor comes to mind. To me, the referred complexity is reminiscent of a number of other complex patterns that somehow found their ways in software engineering, out of possibly good intentions. Regardless, an idea needs to be sold and when the marketing is well executed the community will ingest the kool-aid. Which it then tries to digest for a few years. Then begins a game of chicken that consists in not being the first to admit that you're in pain, out of fear of being branded an infidel, or out of sunk cost bias. Eventually a few courageous and influential souls finally spit it out in disgust and scream "wtf is this shit?!?" Then the rest awakes from the common stupor and a holy war ensues. I still remember SOAP. I still remember with what verve I was sold Scrum.

As for Kubernetes, only time will tell.

> " that somehow found their ways in software engineering, out of possibly good intentions"

It seems that systems and principles invented for some specific situations get rapidly entrenched as "best practice" due to the wild success of their root corporations. That's twisted much like fashion - "that dress looks great on that model, maybe if I wear that dress, I would look good too".

There's some truth in that, but there's more to it. Successful tech companies build good tech that is often worth adopting:

- the companies' successes are often predicated on strong ability to develop technologies

- good (well-maintained) technology requires resources and the successful tech companies have those resources.

Valid. The "fashion" point was more about P(adoption worthy tech | successful originator) != P(successful originator | adoption worthy tech)

I'm alarmed by the way you've brought up Mikey Dickerson completely unprompted (both here and in the OP's comment section), and that your account is just two hours old. It's fine if you take issue with the Silicon Valley mindset in government IT, but there's no reason to make it personal.

The reason it seems like an attack is due to the hostile tone of your comments, the burner account, and the unfounded/unsourced accusation that USDS left its partners behind.

I apologize if you just wanted to discuss the merits of a startup-minded approach to government IT, but I'm honestly skeptical of your motivations. USDS ruffled many feathers among the entrenched IT interests, and I've seen what the propaganda response looks like first hand.

If you really believe that you're fighting the good fight, then I'd welcome a direct conversation. Even a phone call if you like. I promise that I'm not in any way similar to a QAnon believer.

Perhaps my beef with your cadre is assuming that questioning its merits is AFS propaganda coming from someone who’s never set foot south of Embarcadero and assuming everyone who mentions principals has an axe to grind. You’ve painted a lovely caricature of who you think your opposition is, but you’re looking in entirely the wrong direction. Hint: Two FAANGs.

I don’t speak on the telephone with underhanded accusations, sorry.

Perhaps because I’m a government lobbyist and consultant formerly of FAANG with 24 years of experience trying to warn the Web industry that the exact thesis of the article is turning non-Web sectors against them? Couldn’t possibly be that, no, I have to be schizophrenic or a troll. The reason I know you don’t have schizophrenia close to you in your life is how willing you are to throw it at an anonymous commenter with a dismissive gesture toward “schizo”. You’d shut up if you knew what it’s like.

And you and “a proper response to accusing you of being a conspiracy means I’m being trolled when really I have no response” wonder why I change HN accounts like I change socks. Perhaps it’s because I hold this community in the utmost contempt precisely because of you and people like you, and I have zero interest in building a reputation among the harmful, toxic people who don’t realize how wrong they have it that I am working to excise from the conversation.

Take it or leave it. The good news for you is that you’re on the comfortable side of the argument so you will never get flagged or chastised by dang. Flagrantly accusing someone of psychological defect due to not liking their opinion is okay depending on the target and beliefs.

cool story bro. I have no idea what you think I "sold" Washington, but anyone who has kubernetes never talked to me.