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...