You've enjoyed it, but those hours cost your business, and is that really worth it?

Some beliefs which are frequently displayed in these parts:

> Money on chairs / desks / PCs are no object because developers cost money, not those things

> Ship quickly and iterate

> Make it, make it work, make it fast

> Write code your successor can maintain

And then HN goes ahead and upvotes a boast about spending their (expensive) time unpicking libraries from code.

The point of "you might not need X" is to encourage package maintainers to keep their sub-package footprint small, not that end-users shouldn't use X.

I'm sure you'll be back to suggest that you've delivered "500% speed-up" or some other nonsense metric and I look forward to that.

Ultimately, custom business owned code which attempts to deliver the value of angular is just a future maintenance nightmare, and I say that as someone who really doesn't like angular.

If you really replaced angular with a "javascript one-liner" I'd like to see that line!

I'm going to take a guess and say he won big in maintainability and performance on low-end devices.

If it will operate with no js at all, then it is also more compatible with some security requirements I have. Don't get me wrong, I've always been a big fan of JavaScript, warts and all. However, in this particular instance, what should have been a simple server rendered login page was written with a full SPA application development mindset.

I see where you are coming from, there rarely is any reason to reinvent the wheel, but at some point reducing libraries is beneficial for the long run when and if you can afford it.

I think the "enjoyed" part was definitely meant facetiously.

Ultimately, custom business owned code which attempts to deliver the value of angular is just a future maintenance nightmare, and I say that as someone who really doesn't like angular.

I suspect the problem the commenter is hinting at concerns situations where people think they need the "value of {angular,react,bootstrap,whatever}" when really they don't.

Just because you can't give a $ amount for the costs saved by reducing complexity, doesn't mean it doesn't have value. Simple is good.

We all do things that aren't objectively "worth it". Was the time you took to type this post really worth it?

I wouldn't think someone's livelihood depends on worthiness of this post. In businesses, however, that often is a case.

Depends if they are on HN at work...

What about the money lost because people don't wanna use your app because it's bloated and slow?

Who said anything about it being bloated and slow?

JS is the bloat here.

I wonder what the % of people in HN would be unemployed if more businesses relied on small, static or server rendered web apps instead of huge SPAs.

I strongly believe that the big line of business app I worked on for a number of years would have employed fewer people if we had designed it as an SPA backed by APIs instead of a traditional Rails app. Path dependency is real, and by the time we realized that people wanted a lot more web application behavior than we originally thought, it was time consuming to make it happen.

To be sure, lots of projects have the opposite problem, but SPAs aren't some make-work conspiracy, they have real use.

Isn't increased complexity as codebase grows a basic rule of all computer programs? And don't say microservices are exempt - you'll have the same complexity on the tooling side.

Yes, but my conclusion in this case is that the way we started building the application - traditional full-page-load Rails with custom javascript - resulted in more complexity than if we had started with a "single page app" using a framework like Backbone (which, in fairness, was very new at the time).

I didn't actually say anything about microservices. I think that may have also been a win, but it is much less clear-cut. Backing the front-end with a single monolithic API server would have been an improvement over the hybrid page generation / API approach we ended up with.

These are all just my own personal conclusions, and others who also worked on the project may not agree with me, but I'm just not convinced by the backlash against js-heavy web apps, because I believe I've felt the pain of going the opposite route in the wrong case.

In my experience the clean separation between UI and backend code that a SPA enforces is an enormous maintainability boost.

Add to that, that you then have by necessity an API you can use for other systems to interact with yours (or just to build some quick one off scripts) and the advantages are even clearer.

That's a false dichotomy. Business apps become huge codebases due to lack of engineering discipline and cutting corners to make deadlines. It happens regardless of whether the code is written for the browser or the server because there is no environment that will substitute for the skill that is necessary to control complexity in businesses which are inherently unpredictable.