Live data from Hacker News

Ask HN: What tech stack would you choose for a serious, long-term business app

news.ycombinator.com

41–50 of 80 posts

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#41
Consider not doing an SPA. A classical web-app will get you to market sooner with fewer bugs. Here are some big issues with SPAs:

- Unsubmitted form input is not automatically saved in history by the browser, so you must write code to cache it and restore it again if the user leaves the page. A classical web app can identify all the form elements before rendering, so this functionality is free with a non-SPA.

- If you use the browser History API to allow navigation within your SPA, you'll have to write code to cancel async requests upon navigation. With a classical web app, the browser will cancel them all for you and provide a handy UI for the user to do it themselves.

- If you have lots of views within your SPA, it's going to get big and then you'll have to structure your project for code-splitting.

These are the top three issues that I've had with building my SPA and I've spent way more time putting together all the infrastructure instead of building user-facing views and logic because I won't ship a broken app. At this point, I might as well pivot my app to be a developer tool for building SPAs! (No kidding - I'm actually considering throwing away months of work to start over with a classical web app after all this.)

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#42
post #6

As we're talking business and long lifetime... First point: nothing Microsoft. Done that show for 20 years and been through all the marketoid schizophrenia promoted rewrites for no business value. Now the new "start again" is .Net core and a big chunk of stuff just isn't portable and never will be. Plus the price gouging, licensing hell etc when you have to scale up. Entire ecosystem is a wasteland of unmaintained cr…

Wow, that's pretty hardcore...borderline badass! Interesting thing is this stack was doable probably 13+ years ago, so I see your emphasis on stability. Anyway, it's similar to what I'm using and surprised to see it here. Biggest tweaks are that I'd consider Vue/Webpack if starting today and do believe PaaS to be far superior to on-prem/colo. Also, not big on Hibernate or too much abstraction at the data access layer…

It's possibly a summary of my frustration with the last 20 years or so.

I've never used vue/webpack so can't comment. I've been shot too many times by javascript framework churn over the years. I wrote a relatively small and powerful abstraction over DOM that doesn't hide it away, merely makes the hard things easy and less verbose and allows simple templates to be used.

Hibernate is essential if you ask me. One of the problems I see a lot is relying on features of the underlying storage engine. This, while it has advantages, has more disadvantages such as coupling and vendor lock in. These have been significantly costly when you have to scale something commercial up like SQL Server.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#43
post #6

As we're talking business and long lifetime... First point: nothing Microsoft. Done that show for 20 years and been through all the marketoid schizophrenia promoted rewrites for no business value. Now the new "start again" is .Net core and a big chunk of stuff just isn't portable and never will be. Plus the price gouging, licensing hell etc when you have to scale up. Entire ecosystem is a wasteland of unmaintained cr…

For me at least, I'd definitely go .Net Core. And I'd not have issues using MySQL either. True, there are fads and fashions that come and go, but over the last 15 years I've not had an issue building and maintaining applications of all varieties built on MS technology. Plus, given the current owner of Java, I'd stay well clear of it. Already moved anything that was MySql over to MariaDB.

Plus .net core supports async and runs on linux.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#44
post #6

As we're talking business and long lifetime... First point: nothing Microsoft. Done that show for 20 years and been through all the marketoid schizophrenia promoted rewrites for no business value. Now the new "start again" is .Net core and a big chunk of stuff just isn't portable and never will be. Plus the price gouging, licensing hell etc when you have to scale up. Entire ecosystem is a wasteland of unmaintained cr…

For me at least, I'd definitely go .Net Core. And I'd not have issues using MySQL either. True, there are fads and fashions that come and go, but over the last 15 years I've not had an issue building and maintaining applications of all varieties built on MS technology. Plus, given the current owner of Java, I'd stay well clear of it. Already moved anything that was MySql over to MariaDB.

I couldn't possibly consider .Net core on a number of reasons I didn't discuss above. Opt out telemetry, constant direction changes, who is in charge of the project and the general abusive nature of the company running the show towards its customers and end users over the last decade. The list is endless.

I have actually tried to get things fixed on MSFT open source projects as well and even when you get up to Scott Hanselman poking it on github, nothing tends to happen. On top of that many crippling bugs remain unresolved for so far 9 years. We have unreliable tooling, portability problems, all sorts.

On a larger team and product, it's a non trivial time and cost sink.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#45
We're 99% Python but for an internal app I would probably go with Postgres, Memcached and Phoenix/Elixir as that's probably where we want to end up in a few years time. For the front end I'd go with HTML and vanilla JS. Front end dev has gotten so mad that picking any framework at this point could turn out to be a bad decision.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#46
post #29
post #12

Earlier quoted context omitted.

Definitely agree with memcached. This has been entirely bullet proof for us for years. We have had lots of nodes with billions of hits each running non stop for 3 years without a reboot on CentOS 5. Zero maintenance required. Amazing bit of software.

While memcached is great. I feel like its hard to argue for both redis AND memcached. It seems like redundant infrastructure unless you have very specific needs.

Yes I agree there. I would err towards redis these days myself as well, not necessarily using it for anything persistent unless you need to.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#47
I think a crucial part of the equation is the context. I'll give my answer with that in mind:

DB engine:

Postgres or otherwise MySQL, unless I'm planning to do something specific that clearly warrants the use of something else. Too often I've regretted using something more 'exotic' for no really good reason.

API layer:

If this is something I'll mostly be building myself, definitely Phoenix/Elixir, unless the Rails/Ruby or Django/Python ecosystem has something that I 'need'. If hiring 'cheap' bodies is at all a concern, I'd go for Django/Python or Rails/Ruby. But at this point I'd rather hire that one developer (remote or nearby) who is itching to use Phoenix/Elixir over five of the alternative. And I think any decent Python/Ruby programmer could pick up what I started with pretty quickly.

Frontend SPA:

Just myself: React. If I need to work with others, possibly Vue, but most likely React still. I would probably start out with TypeScript right away, and go for the most 'vanilla' possible everything else (Webpack, Redux, React-Router, Babel, bits of Lodash perhaps).

That said, while last year I would never consider this, I'd probably go for a 'good old' server-side templating approach (w/Phoenix) with some React/Vue components sprinkled in. Even with the best of devs and the best of tools, front-end just strikes me as still too fiddly, too labor-intensive, and too expensive (front-enders often cost more than back-enders, or am I wrong with that impression?) to be worth the effort. Obviously this depends entirely on what's being built though.

Caching:

With Phoenix, possibly none at first. Otherwise I guess something on the nginx side? Not sure if I can see this mattering too much until later in the process.

PaaS:

No. unless there's a good justification for it. I still lean towards using a VPS or something like that, at least until things get out of hand.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#48
post #44

Earlier quoted context omitted.

For me at least, I'd definitely go .Net Core. And I'd not have issues using MySQL either. True, there are fads and fashions that come and go, but over the last 15 years I've not had an issue building and maintaining applications of all varieties built on MS technology. Plus, given the current owner of Java, I'd stay well clear of it. Already moved anything that was MySql over to MariaDB.

I couldn't possibly consider .Net core on a number of reasons I didn't discuss above. Opt out telemetry, constant direction changes, who is in charge of the project and the general abusive nature of the company running the show towards its customers and end users over the last decade. The list is endless. I have actually tried to get things fixed on MSFT open source projects as well and even when you get up to Scott…

What was the bug that remained open for 9 years? Was it part of the .net framework or a Windows SDK issue?

What sort of projects did you have the most trouble with? Where were your pain points?

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#49
post #45

We're 99% Python but for an internal app I would probably go with Postgres, Memcached and Phoenix/Elixir as that's probably where we want to end up in a few years time. For the front end I'd go with HTML and vanilla JS. Front end dev has gotten so mad that picking any framework at this point could turn out to be a bad decision.

I agree 100%, but I'm curious how you feel about the state of Phoenix/Elixir when it comes to popularity.

I'm perhaps too inexperienced/young to know how these things tend to shake out.

That said, my impression is that it has enough of a foothold, and with Erlang enough of a solid base, that I wouldn't end up in a situation, say, 10 years from now where the whole ecosystem is a ghost town and I need to move to some other language/framework. And based on my research it's even quite possible that Elixir might end up becoming a formidable player.

But I don't feel certain enough about this to recommend Elixir to a new startup, for example. I'd love to hear other people's thoughts on the matter.

Re: Ask HN: What tech stack would you choose for a serious, long-term business app

#50
post #44

Earlier quoted context omitted.

I couldn't possibly consider .Net core on a number of reasons I didn't discuss above. Opt out telemetry, constant direction changes, who is in charge of the project and the general abusive nature of the company running the show towards its customers and end users over the last decade. The list is endless. I have actually tried to get things fixed on MSFT open source projects as well and even when you get up to Scott…

What was the bug that remained open for 9 years? Was it part of the .net framework or a Windows SDK issue? What sort of projects did you have the most trouble with? Where were your pain points?

Sorry was 8 years ... ClickOnce refused to launch on over 2000 machines when they removed download prompting from IE9. This sits between the .net framework and the IE team, neither of which would take responsibility for fixing. Eventually we got a registry fix out of them from bottom line support which turned download prompting back on which was removed from the IE UI but still left in there. The registry fix we had to deploy to hundreds of clients and had a massive support cost. This is still broken in IE11. It was reported on an IE9 beta.

Pain points: large project performance, high concurrency projects, IDE reliability, cost, odd time sinks, bugs in the framework, lack of automation possibility for a vast number of project types (try building VSTO applications on a CI server), deprecations (WWF/WCF changes, AppFabric, Velocity etc) all sorts.

Post reply on HN