Ask HN: What is a “boring” web stack?
There have been threads recently lamenting how many in the web community often chase new and shiny. Many advocate choosing "boring," tried-and-true technologies for the web. What are the "boring" stacks that you see successfully used for the web? If you were starting a new web project today, what would your "boring" stack look like?
49 comments
Ye old "LAMP" stack (Linux, Apache, MySQL, PHP) is pretty boring, and widely used. Very stable, very performant (and lots of options for caching / indexing / tweaking code when you encounter bottlenecks). Lots of competition in the hosting space as well, and you're not locked into any one company's flavor of "cloud computing platform".
I second LAMP (although you can consider changing Apache for Nginx).
For PHP it depends on what you want to do, but Laravel (or Lumen) may help you A LOT!
It is super boring by these standard:
- You can find setup tutorials everywhere
- Almost every question you might think of has been already answered
- It will do what it says it will do
(Also don't forget to install phpMyAdmin, because who wants to write SQL in a terminal)
For PHP it depends on what you want to do, but Laravel (or Lumen) may help you A LOT!
It is super boring by these standard:
- You can find setup tutorials everywhere
- Almost every question you might think of has been already answered
- It will do what it says it will do
(Also don't forget to install phpMyAdmin, because who wants to write SQL in a terminal)
But then you have to use PHP.
You upload PHP file to your server, done. No deploy task and stuff.
That's fine for experimenting but sounds terrible when you want to track down where problems came from and rolling back.
There are plenty of testing, deployment and analysis tools for PHP apps.
Ruby on Rails or Django for the backend, some basic JS (JQuery and other libraries of similar complexity) for the front-end. Choice of JS tools mostly depends on how much front-end features you need.
The persistence layer is also a thing, and the boring choice is something like Postgres or MySQL.
At least at the persistence layer, there's a clear default: Postgres will do everything you want, and it'll be hard to outgrow.
What things would you say make Postgres a "clear default" over MySQL?
Honestly, features & stability wise, MySQL is a toy compared to Postgresql. I still feel Postgresql does not have as big a market share as it could, mainly because of how difficult it is to pronounce it right. On the other hand, MySQL got away with a rather sweet name. But for any serious work, I would trust Postgres (there, I did it!!) more than any variant of MySQL.
I think especially in the context of a "boring" web stack, MySQL is the clear winner.
Postgres has lots of shiny features on the SQL side, but MySQL's storage and especially replication has always been more reliable for me. I've seen a couple failed MySQL -> Postgres migrations because it's the shiny thing people chase, but the operational reality is that MySQL is still better.
Postgres has lots of shiny features on the SQL side, but MySQL's storage and especially replication has always been more reliable for me. I've seen a couple failed MySQL -> Postgres migrations because it's the shiny thing people chase, but the operational reality is that MySQL is still better.
As an application developer, I remember wrestling with some really annoying stuff on the application side to deal with MySQL. IIRC, it was something like the default ORM for a python-based framework requiring a reflection API that Postgres and SQLite have and MySQL doesn't. This and other war stories probably generalizes to many other application developers preferring Postgres, but there's a ton of people using MySQL, so that probably means that it solves a bunch of the problems that the wizards in operations have.
That's why I listed both. I'd use and recommend Postgres as a default in a heartbeat based off personal experience, but I wouldn't have personal experience with MySQL's strengths and people use and recommend it as well.
That's why I listed both. I'd use and recommend Postgres as a default in a heartbeat based off personal experience, but I wouldn't have personal experience with MySQL's strengths and people use and recommend it as well.
For the lowest barrier to entry and pure "Getting shit done" MySQL is perfectly fine for most projects, when you start needing to think about enterprise level data then Postgres is way forward!
Why is that? All Postgres ever needed for me was "apt-get install postgres", and it was ready to go.
Its more the ecosystem around it than the name. When I was first getting into web development all the tutorials were around setting up MySQL. phpMyAdmin was a friendly front end where I could actually see what I was doing.
Postgres has gotten better and friendlier over time, but its still much easier to ramp up with MySQL.
Postgres has gotten better and friendlier over time, but its still much easier to ramp up with MySQL.
I still love phpMyAdmin. Got it on all my docker development containers. Knocks the socks off MySql Workbench.
What was the last version of MySQL you gave a serious shot? Have you used the replication features of both? What kind of scale have you run postgres at?
Postgres certainly wins in terms of features, though most of those features aren't required by the vast majority of web apps, so "more features" isn't necessarily a reason for most people to favor Postgres by default. Which features of postgres which aren't present in MySQL would you not want to live without?
You also called MySQL a toy in terms of stability compared to Postgres. What experiences shaped this opinion?
For an anecdote, I work at a relatively large SaaS company which runs over 300 MySQL servers in production, over 600 if you include QA. We specifically run percona-server because it's basically the enterprise version of MySQL, and percona makes some great tools. (We use the free version of percona and do not pay for percona support). We have a single DBA who manages all of those servers full time. I work in ops/SRE and touch MySQL here occasionally, but mostly just to touch the OS, monitoring systems, automation systems, etc on those machines. So overall, our ratio of admins to MySQL servers is basically 2:600, which makes me consider it not a toy (especially in comparison to the number of people it take to manage the other data services we run). As far as stability goes, we were rock solid on MySQL 5.6, but hit a few serious bugs on MySQL 5.7 (two memory leak bugs in plugins, and one in the core that caused a crash), all of which have been resolved as of 5.7.12. 5.7 is an extremely major release in terms of features and performance, so I'm willing to let a few bugs slide here.
We run many different types of data services, mysql/hadoop/hbase/kafka/redis/zookeeper/elasticsearch/etc, adding postgres to the mix has always been of interest to some devs who want a postgres feature here and there. I personally like both MySQL and postgres, but it seems that MySQL may be more mature in terms of operations (tooling and replication/HA) and performance. I love ops work, so to me, more services means more fun and I've advocated to add postgres in the past, but it's tough to find reasons to push for it.
Unfortunately, now I've gotten away from the topic of "boring" stack to use, but in general, I think the choice for a "boring" database would be MySQL, while postgres is shinier and more advanced. There are a lot more people using MySQL in the wild and virtually every language and framework supports it. I typically view postgres as a more hip open source database, due to its interesting features and niche of developers who really really love it, whereas MySQL is the popular option, that gets the job done, and mostly lacks enthusiastic supporters. People just use it because it's easy and works. That said, it's easy to see how people could have different opinions on which of these is the "boring" choice because both are perfectly reasonable choices. When not operating at a big scale, mostly default installations of both MySQL and postgres will get you quite far and are pretty comparable to manage.
Postgres certainly wins in terms of features, though most of those features aren't required by the vast majority of web apps, so "more features" isn't necessarily a reason for most people to favor Postgres by default. Which features of postgres which aren't present in MySQL would you not want to live without?
You also called MySQL a toy in terms of stability compared to Postgres. What experiences shaped this opinion?
For an anecdote, I work at a relatively large SaaS company which runs over 300 MySQL servers in production, over 600 if you include QA. We specifically run percona-server because it's basically the enterprise version of MySQL, and percona makes some great tools. (We use the free version of percona and do not pay for percona support). We have a single DBA who manages all of those servers full time. I work in ops/SRE and touch MySQL here occasionally, but mostly just to touch the OS, monitoring systems, automation systems, etc on those machines. So overall, our ratio of admins to MySQL servers is basically 2:600, which makes me consider it not a toy (especially in comparison to the number of people it take to manage the other data services we run). As far as stability goes, we were rock solid on MySQL 5.6, but hit a few serious bugs on MySQL 5.7 (two memory leak bugs in plugins, and one in the core that caused a crash), all of which have been resolved as of 5.7.12. 5.7 is an extremely major release in terms of features and performance, so I'm willing to let a few bugs slide here.
We run many different types of data services, mysql/hadoop/hbase/kafka/redis/zookeeper/elasticsearch/etc, adding postgres to the mix has always been of interest to some devs who want a postgres feature here and there. I personally like both MySQL and postgres, but it seems that MySQL may be more mature in terms of operations (tooling and replication/HA) and performance. I love ops work, so to me, more services means more fun and I've advocated to add postgres in the past, but it's tough to find reasons to push for it.
Unfortunately, now I've gotten away from the topic of "boring" stack to use, but in general, I think the choice for a "boring" database would be MySQL, while postgres is shinier and more advanced. There are a lot more people using MySQL in the wild and virtually every language and framework supports it. I typically view postgres as a more hip open source database, due to its interesting features and niche of developers who really really love it, whereas MySQL is the popular option, that gets the job done, and mostly lacks enthusiastic supporters. People just use it because it's easy and works. That said, it's easy to see how people could have different opinions on which of these is the "boring" choice because both are perfectly reasonable choices. When not operating at a big scale, mostly default installations of both MySQL and postgres will get you quite far and are pretty comparable to manage.
Which features of postgres which aren't present in MySQL would you not want to live without?
Here's a few:
1. Check constraints.
2. INTERSECT and EXCEPT operators.
3. Common table expressions.
4. Sort-merge join.
5. Serializable snapshot isolation.
Here's a few:
1. Check constraints.
2. INTERSECT and EXCEPT operators.
3. Common table expressions.
4. Sort-merge join.
5. Serializable snapshot isolation.
Standards compliance and sane defaults.
Any examples for MySQL in regard to lack of sane defaults? I'm also curious which standards you're referring to that would be applicable to boring web apps
I've heard quite a few complaints over Unicode handling, but it's possible that these were past issues that just are hard to fix when migrating to newer versions.
The standard tuning MySQL comes with is a good example, pretty crappy for anything other than a small website! However that's what it excels at and I would guess 90% of its userbase! Anyone who needs it for something bigger will know how to tune it :)
I think "boring" is another word for "not frustrating".
I recently did a project where I wrote the same API in Ruby/Sinatra, Node/Express and PHP/Slim; Connected it to S3, GCloud and Azure for assets and MongoDb for data; and then deployed each permutation to Heroku, Azure, App Engine and EB.
For "under the api barrier", Heroku was the only one that ran everything smoothly; S3 is the easiest to interact with, and as I worked through the project, I switched from Ruby to Node as the prefered platform.
For "over the api barrier", where users actually use the project, it depends on the project requirements. In this case no dependancies was a hard requirement, hence Vanilla JS. But if you have a lot of UI, you'd need a lib for both JS and CSS and it depends on teammates pref, organization pref and legacy.
My 2 cents.
I recently did a project where I wrote the same API in Ruby/Sinatra, Node/Express and PHP/Slim; Connected it to S3, GCloud and Azure for assets and MongoDb for data; and then deployed each permutation to Heroku, Azure, App Engine and EB.
For "under the api barrier", Heroku was the only one that ran everything smoothly; S3 is the easiest to interact with, and as I worked through the project, I switched from Ruby to Node as the prefered platform.
For "over the api barrier", where users actually use the project, it depends on the project requirements. In this case no dependancies was a hard requirement, hence Vanilla JS. But if you have a lot of UI, you'd need a lib for both JS and CSS and it depends on teammates pref, organization pref and legacy.
My 2 cents.
Server side rendered HTML, simple forms with POST redirects. Little to no CSS or Javascript. Pick your back-end of choice: Java Spring, Python Django, Common Lisp (wink wink). Use a well known SQL server for persistence. Might be boring, but there are still a lot of cases where this is actually desirable, and it's insanely performant.
At this point, isn't a site without CSS only suitable for tenured academics who don't care about their personal websites?
Have you seen this? No CSS, but it looks OK.
http://motherfuckingwebsite.com/
Using absolutely no CSS at all probably isn't what you want, unless you have a fetish for serif fonts. But a little can go a long way.
http://motherfuckingwebsite.com/
Using absolutely no CSS at all probably isn't what you want, unless you have a fetish for serif fonts. But a little can go a long way.
Java, the Microsoft stack, Django, RoR, anything that's been around for more than five years. I don't include PHP there because I don't think the language is predictable/consistent enough, same as JS.
ASP.NET MVC5 C# + Angular 1, because that's what we do at work and what I'm currently most familiar with. It's a pretty solid way to go if you don't mind Microsoft technologies, either. Although ASP.NET Core is probably more future-proof.
+1... ASP.NET / ReactJS.NET has been great for me. I've done so many small->med projects on ASP.NET MVC / EF / SQL with some F# mixed in for fun and it just works. Toss in ELMAH for easy error logging.
Testing + deploying to either Azure/IIS is also one-click simple and very easy to teach Jr. Devs to step into a solution and become productive with very little guidance.
Testing + deploying to either Azure/IIS is also one-click simple and very easy to teach Jr. Devs to step into a solution and become productive with very little guidance.
I know this doesn't truly really answer what you're asking, but: GitHub Pages, static HTML, no or plain JavaScript, plain CSS, no frameworks.
You can do a lot with just that. Here's an example of what I've done with just that:
http://www.planimeter.org/grid-sdk/
http://www.andrewmcwatters.com
You can do a lot with just that. Here's an example of what I've done with just that:
http://www.planimeter.org/grid-sdk/
http://www.andrewmcwatters.com
Pick anything that's still heavily used today, that has been around for 10+ years, and it's hard to go wrong.
The only caveat to this is on the front-end JS side of things. jQuery is still solid, but the language and ecosystem has been so not great over the last decade that something a bit newer might be worth looking at (maybe look at 3-5 year old libs/frameworks instead).
The only caveat to this is on the front-end JS side of things. jQuery is still solid, but the language and ecosystem has been so not great over the last decade that something a bit newer might be worth looking at (maybe look at 3-5 year old libs/frameworks instead).
In the enterprise world, a boring stack is usually Java 7, 8 if you're adventurous, with Spring as the backing framework, running on a Tomcat server, talking to a SQL database (Mysql, Postgres, Oracle) through a Hibernate layer.
None of these are really great technologies, but they work, have infinite documentation, and it's easy to find people who know them.
None of these are really great technologies, but they work, have infinite documentation, and it's easy to find people who know them.
Can you name any "great" technologies in place of each of these?
That's in the eye of the beholder, and definitely depends on the situation. The good thing about the boring tools is that they have really wide applicability.
For a small REST api, I really like Dropwizard on top of something with a solid raw driver, like Redis or Cassandra. If you want to go relational, I like the MyBatis model of persistence over the Hibernate style ORM, it gives you so much more flexibility and power over modeling, while still giving you an easy out for swapping out datasources.
I don't really know of a good drop-in replacement for what Spring does, unfortunately, because Spring is really a conglomeration of so much different stuff. My big issue with it isn't so much what it does, as the fact that it encourages really bad mindsets in developers who start their career with it. I can't count the number of times I've asked someone to describe what annotations are, and the only answer they can give is about Spring (the worst part is when they attribute things from Jersey or JPA to Spring), or how they reduce the need for XML configuration (in Spring, yeah, that is true).
For a small REST api, I really like Dropwizard on top of something with a solid raw driver, like Redis or Cassandra. If you want to go relational, I like the MyBatis model of persistence over the Hibernate style ORM, it gives you so much more flexibility and power over modeling, while still giving you an easy out for swapping out datasources.
I don't really know of a good drop-in replacement for what Spring does, unfortunately, because Spring is really a conglomeration of so much different stuff. My big issue with it isn't so much what it does, as the fact that it encourages really bad mindsets in developers who start their career with it. I can't count the number of times I've asked someone to describe what annotations are, and the only answer they can give is about Spring (the worst part is when they attribute things from Jersey or JPA to Spring), or how they reduce the need for XML configuration (in Spring, yeah, that is true).
Angular/Bootstrap on the front end.
Java with Spring Boot on the server.
MySQL for storage.
Deploy on AWS.
Nobody's idea of excitement.
Nobody's idea of excitement.
Haha, but there is always a way to make this less vanilla than people would expect. Ie adding Spring 5 (alpha) reactive web layer & I still love hateoas (spring/data-rest) but adds a little too much extra complexity for the benefit (on the client).
I miss well tested and 'best practice' pattern derived systems...
I miss well tested and 'best practice' pattern derived systems...
Java, Ruby, PHP - all safe bets for server-side language. They're all easy to find developers for, stable, and easily supported by all major IaaSes (AWS, Google Cloud Platform, Azure) and PaaSes (Cloud Foundry, Heroku, Kubernetes, Docker).
Javascript - either no Javascript, or very simple vanilla Javascript. No transpiling, no Typescript, no JSX, no ES2015.
CSS - Regular ol' CSS. Set a limit on number of lines of CSS you're willing to introduce per controller action and try and keep your project honest to that number. Avoid frameworks if possible, pick a simple framework for grid layout if you really need it.
Javascript - either no Javascript, or very simple vanilla Javascript. No transpiling, no Typescript, no JSX, no ES2015.
CSS - Regular ol' CSS. Set a limit on number of lines of CSS you're willing to introduce per controller action and try and keep your project honest to that number. Avoid frameworks if possible, pick a simple framework for grid layout if you really need it.
Is picking a a "boring" for the sake of "boring" stack really all that sensible? How about we choose things because of tangible reasons, like test coverage, infrastructural/operational simplicity, availability of development resources, industry/enterprise adoption. IMHO these are the things that make sense when choosing a framework/language. Choosing something just because it's old and boring is illogical.
"boring" means "of low technical risk" in this context.
PHP with some template library. Pretty much gets the jobs done and stays out of your way. RainTPL[0] is the best template engine I've ever used since it is just so simple to understand what's going on.
[0] - https://github.com/feulf/raintpl
[0] - https://github.com/feulf/raintpl
Plain Django with Postgres.
Django templating and bootstrap to make things look OK.
Django templating and bootstrap to make things look OK.
I did most of my website dev with PHP, js, css and html, no framework (except jquery at one point). Boring but did the job well
I'd call a stack using Golang, Postgres, jQuery, and SASS/Less boring. It doesn't do much of anything magical, and as a result you can reason about every part of what you're writing.
My boring stack is: Spring, Hibernate, Postgresql, but sometimes when nobody watches and I feel really nasty, I use the Play framework.
[deleted]
Well Java is boring...
Actually language doesn't matter so much as choice of frameworks. Basically choose what you know works and avoid hype.
Also minimalism is a better indicator than age. A brand new simple framework is better than something old but over engineered.
Actually language doesn't matter so much as choice of frameworks. Basically choose what you know works and avoid hype.
Also minimalism is a better indicator than age. A brand new simple framework is better than something old but over engineered.
bottle.py + Postgres + Nginx on Ubuntu on a VPS is my go-to boring stack.
I recommend just using SQLite for the MVP. Launch then iterate.
I recommend just using SQLite for the MVP. Launch then iterate.
the word stack itself is quite boring.