[iamsb]

As a counter point, I was almost fired for not choosing to build a SPA for an internal app which was going to be used by 3-5 people, 5-10 times a month, if that many.

I worked at large accounting software provider, and internal billing system used static pricing which was changed once a year. The company wanted to move to a more flexible system where pricing can be setup based on few rules like customer type. For this the ui and backend system needed to be developed. Design I proposed was a single "monolithic" service which did everything including UI and UI was supposed to be a old style mustache templates and some minor jquery. Instead they went with pub-sub systems, 4 different microservices, a react based UI, api which used json-schema, even to send data back to UI. When I left a team of 6-7 people was working full time on this and they were about 20% done.

[erlich]

If you join an early stage startup today, it will only be a matter of time until a developer comes in who builds a microservice for what would normally be a single function calling a third party api and then discovers that Kubernetes is necessary. Its almost impossible to stop this happening because business folk want microservices, or they might have heard microservices were going out of fashion but still want Kubernetes...which is only really necessary for microservices.

Devs like to have fun, learn new things, play with complicated things - that's all it is. It counteracts the dull features that most developers have to ship.

[randomdude402]

I have met enough devs that don't necessarily love to make everything Dockerized microservices on Kubernetes, just that if we don't learn this stuff we risk becoming unemployable.

[UseStrict]

Are you me? We had an (admittedly more complex) monolith application for customer contracts and billing. It wasn't ideal, and was getting long in the tooth (think Perl Catalyst and jQuery), so the powers that be wanted to build a new service. But instead of decomposing the monolith into a few more loosely integrated services, they went way overboard with 20+ microservices, every DB technology imagineable (Oracle RDBMS, Mongo, MariaDB), a full message bus via RabbitMQ, and some crazy AWS orchestration to manage it all.

What could've been an effort to split the existing service into manageable smaller services and rewrite components as needed turned into a multi-year ground-up effort. When I left they were no where near production ready, with significant technical debt and code rot from already years out of date libraries and practices.

[mixmastamyk]

"old style" from the horse-and-buggy-olden-days of 2010+ :D.

[khalilravanna]

come hop up on the horse with yer pappy and let me tell you about the days of server-siiiide renderin’ child’s eyes widen in wonder

[sli]

Oh the long lost days before "server-side" needed to be added.

[worik]

https://youtu.be/ljPFZrRD3J8

[marcosdumay]

It feels like a millennium if you have the attention span of a goldfish.

[sli]

Sounds like my current project. I was tasked to start working on a project and was told I could use "whatever [I] want." So me and the other frontend guy started working using Clojurescript with Reagent and Re-frame (highly recommend). Save for a few hiccups along the way the project was stable and fast.

It went swimmingly right up until QA was more or less told not to file any issues found, and then those issues were used as a reason we needed to use a TypeScript and Material-UI app he wrote over a weekend and said was "almost done." The bugs in question turned out to be minor visual bugs, and like I said, none of them were filed or even mentioned until this replacement got dropped in our lap. In fact, no problems of any kind were reported until this moment.

Instead it took another 6-8 months to get to feature parity with the app we'd already developed and now thrown away (or feature "parody" as my boss put it), it was full of bugs, development is slow and pretty directionless, my boss gets bored and contributes code that runs in the O(n^12) range (yes, really) before languishing in a draft PR for months and then getting dumped on us to actually implement for real, and it's been a year and a half with no end even remotely in sight.

I really want to find somewhere else but that doesn't seem like a realistic goal right now. Not to mention my enjoyment of programming died years ago and I haven't written code for fun in as long as I care to remember.

[bpodgursky]

IMO the real failure here was not having an internal administration website with all the auth and API plumbing already set up, which you could tack a new page onto with minimal fuss, and a backend to tack a new API endpoint onto with no hassle.

If you're building a new internal webapp from scratch for a small internal use-case, you just end up with a hundred different poorly-maintained apps.

But in the situation where you're adding a page to an internal app, it's trivial to make that new page a SPA React app, since the framework is already there waiting for a new component.