Ask HN: Go-To Web Stack Today?
30 comments
I don't think there is one. React is the most popular on the front-end side but you can pick Vue or Svelte without taking risks too.
On the backend it's very open and you can select what is the best for your use case. Maybe golang, Ruby on rails, Django, express.js, Apollo Server, Hasura.io, Java spring, .net just to name a few.
On the backend it's very open and you can select what is the best for your use case. Maybe golang, Ruby on rails, Django, express.js, Apollo Server, Hasura.io, Java spring, .net just to name a few.
Pick the hyped stack if you want to learn.
Pick the tools that you're comfortable with if you want to finish.
Pick the tools that you're comfortable with if you want to finish.
Thanks for the brutally honest reply :) I guess part of my question is Django still as relevant today or is it losing 'market share' and finding devs to help out in the future is going to prove a lot more difficult.
I agree with OP, pick the hyped framework if you want to learn or get a job. If you want to build then use tools you are comfortable with. Django is not going away, I would say it would still be around in 10 years but latest hype framework is less likely to be around in 10 years.
Even Nicolas Taleb talked about it in more general terms. Bible is more likely to be around in 2000 years than latest bestseller.
Even Nicolas Taleb talked about it in more general terms. Bible is more likely to be around in 2000 years than latest bestseller.
It's python, any competent dev can pick it up very quickly.
I would additionally advise dropping the front end Javascript stack. Serve rendered HTML and CSS as much as possible.
I would additionally advise dropping the front end Javascript stack. Serve rendered HTML and CSS as much as possible.
Django is still relevant and will be in the future. I wouldn't worry about that honestly.
Getting revenue is problem nr° 1, so focus on that.
Getting revenue is problem nr° 1, so focus on that.
>>analysis paralysis trying to decide on a stack.
Yeah, I went through that a few years ago. I went to "TodoMVC.com" and started going over their demos. Spent over a month on that and then a couple more weeks fretting over which one to use. I finally realized I didn't want to invest in any of them.
Instead I use these off the shelf toolkits: Bootstrap for the front end and jQuery, Mustache.js, Accounting.js, Chart.js, and PouchDB.js on the client side along with CouchDB and a bit Perl or Python where needed on the server side.
This is really a pretty sweet way to go. First off, I didn't have to invest in learning how use a "framework" or set up anything on my web VPS except a web server (Apache) and the CouchDB database (also made by Apache).
It's really pretty impressive how much those tookits can do, and how easy they are to use, and how well they work together. That is a really powerful toolset that's rock solid.
PouchDB.js makes working with CouchDB so sweet and easy, and you can configure it to use the web browser's built-in IndexedDB so you don't even need a CouchDB to get started building your app. You change one line of code to switch from the web browser DB to the CouchDB.
And you can install CouchDB on your desktop PC and point your app at it. When you do that, and configure a "Service Worker" for your app you can make an "Offline-First/Local-First" app that runs at near native app speed that can "Live-Sync" with your Cloud based CouchDB on your web server.
The real beauty in this set up is the flexibility. You can drop in any JS toolkit you need to add features and mix it up with plain vanilla JS to create feature rich "single page" web apps that are easy to maintain and use very little bandwidth.
Unless your working with huge amounts of data you can run the web server and the CouchDB on a $20 a month DigitalOcean VPS and it will never break a sweat.
It's worth checking out PouchDB.com and going over their intro and API docs to get an idea of what PouchDB.js does. They have a demo "Todo app" there you can build to get a feel for it.
I have an app you can also check out at https://pugilis.com/app.html
It's a boxing scorecard and boxer database app.
Yeah, I went through that a few years ago. I went to "TodoMVC.com" and started going over their demos. Spent over a month on that and then a couple more weeks fretting over which one to use. I finally realized I didn't want to invest in any of them.
Instead I use these off the shelf toolkits: Bootstrap for the front end and jQuery, Mustache.js, Accounting.js, Chart.js, and PouchDB.js on the client side along with CouchDB and a bit Perl or Python where needed on the server side.
This is really a pretty sweet way to go. First off, I didn't have to invest in learning how use a "framework" or set up anything on my web VPS except a web server (Apache) and the CouchDB database (also made by Apache).
It's really pretty impressive how much those tookits can do, and how easy they are to use, and how well they work together. That is a really powerful toolset that's rock solid.
PouchDB.js makes working with CouchDB so sweet and easy, and you can configure it to use the web browser's built-in IndexedDB so you don't even need a CouchDB to get started building your app. You change one line of code to switch from the web browser DB to the CouchDB.
And you can install CouchDB on your desktop PC and point your app at it. When you do that, and configure a "Service Worker" for your app you can make an "Offline-First/Local-First" app that runs at near native app speed that can "Live-Sync" with your Cloud based CouchDB on your web server.
The real beauty in this set up is the flexibility. You can drop in any JS toolkit you need to add features and mix it up with plain vanilla JS to create feature rich "single page" web apps that are easy to maintain and use very little bandwidth.
Unless your working with huge amounts of data you can run the web server and the CouchDB on a $20 a month DigitalOcean VPS and it will never break a sweat.
It's worth checking out PouchDB.com and going over their intro and API docs to get an idea of what PouchDB.js does. They have a demo "Todo app" there you can build to get a feel for it.
I have an app you can also check out at https://pugilis.com/app.html
It's a boxing scorecard and boxer database app.
Thanks for the input oblib! Will check it out
I recommend giving Actix Web a try, was able to use the knowledge of Python Flask to build it. Rust has sum types which makes development much nicer especially with all the inevitable business logic that is associated with backend web dev.
Important Caveat: As you implied, this is a Flask analog... ie it's minimal, and is missing features most websites use. Unlike Flask, there aren't great third-party add-ons for these, so you'll end up doing wheel reinvention for websites.
Actix is nice for non-website servers that don't need auth, email, templating, admin, auto migrations etc.
Actix is nice for non-website servers that don't need auth, email, templating, admin, auto migrations etc.
I have been using Actix Web as an excuse to learn Rust recently.
I like the fact Actix Web is lightweight and fast. You can deploy it on cheap $5 VPS's and get single-digit millisecond response times and memory usage.
For API type work, it takes little to get going.
The one thing I've taken away is it's still very early days for web frameworks in Rust and Rust in general, so you need to be committed to putting in extra work building libraries/integrations yourself.
I.E. non of the cloud platforms have officially supported SDK's. AWS have a beta SDK they are working on with big bold letters in the readme saying "Do not use this SDK for production workloads" , Azure has an unofficial SDK it looks like staff are work on in their spare time. Google doesn't look to have anything.
Things like live reloading for templates isn't there. I found myself setting up a Webpack build to iterate templates and the frontend quickly with live reloading. I take the Webpack HTML template I produced + CSS assets and move/link to them into my Actix project. I really like the MAUD template engine for compile-time HTML so I find myself rewriting HTML I produce in Webpack to MAUD and just linking to the css / js asset bundle paths from the Webpack build. If I used something like Mustache templates in Webpack that admittedly would make things easier as I can reuse them as is.
The Actix middleware layer isn't well documented, so I looked at existing middleware to figure out how to use it. There's some useful middleware for CORS + logging, but the user auth stuff didn't work for what I needed, so I found myself rewriting my own auth middleware.
The latest stable version of Actix Web is 3.3.2, which uses the old version of the Tokio framework. This will cause issues if using some libraries that rely on a new version of Tokio i.e. the beta AWS SDK's. This means you need to update to Actix Web 4 beta, which then breaks some Actix integrations which do not support Actix Web 4.
All the issues stem from the Rust ecosystem being young. You need to invest extra effort for functionality that exists and is quite mature in other languages/tools. In my current personal project, I could have written it 10x faster using a different stack just because in Rust/Actix I've had to build a lot of basic functionality other web frameworks provide already. It's a pet project, and I choose Rust/Actix for learning purposes, so that's ok. If I had something I really needed to deliver and it wasn't just a REST API I'd probably not use Rust/Actix right now unless I was on a team/company who where willing to spend the extra time for the performance / hosting cost savings.
I like the fact Actix Web is lightweight and fast. You can deploy it on cheap $5 VPS's and get single-digit millisecond response times and memory usage.
For API type work, it takes little to get going.
The one thing I've taken away is it's still very early days for web frameworks in Rust and Rust in general, so you need to be committed to putting in extra work building libraries/integrations yourself.
I.E. non of the cloud platforms have officially supported SDK's. AWS have a beta SDK they are working on with big bold letters in the readme saying "Do not use this SDK for production workloads" , Azure has an unofficial SDK it looks like staff are work on in their spare time. Google doesn't look to have anything.
Things like live reloading for templates isn't there. I found myself setting up a Webpack build to iterate templates and the frontend quickly with live reloading. I take the Webpack HTML template I produced + CSS assets and move/link to them into my Actix project. I really like the MAUD template engine for compile-time HTML so I find myself rewriting HTML I produce in Webpack to MAUD and just linking to the css / js asset bundle paths from the Webpack build. If I used something like Mustache templates in Webpack that admittedly would make things easier as I can reuse them as is.
The Actix middleware layer isn't well documented, so I looked at existing middleware to figure out how to use it. There's some useful middleware for CORS + logging, but the user auth stuff didn't work for what I needed, so I found myself rewriting my own auth middleware.
The latest stable version of Actix Web is 3.3.2, which uses the old version of the Tokio framework. This will cause issues if using some libraries that rely on a new version of Tokio i.e. the beta AWS SDK's. This means you need to update to Actix Web 4 beta, which then breaks some Actix integrations which do not support Actix Web 4.
All the issues stem from the Rust ecosystem being young. You need to invest extra effort for functionality that exists and is quite mature in other languages/tools. In my current personal project, I could have written it 10x faster using a different stack just because in Rust/Actix I've had to build a lot of basic functionality other web frameworks provide already. It's a pet project, and I choose Rust/Actix for learning purposes, so that's ok. If I had something I really needed to deliver and it wasn't just a REST API I'd probably not use Rust/Actix right now unless I was on a team/company who where willing to spend the extra time for the performance / hosting cost savings.
This might help: https://github.com/secretkeysio/jelly-actix-web-starter
I've really enjoyed Flask and Quart (asyncio Flask) for my smaller tool sort of web services as the backend. It can run either self-contained, via uwsgi.
For the frontend component, I'd probably be looking at Vue in the future, I haven't done much on that front.
My most recent toy was replacing the backend of MailHog with Python, the existing one has been flaky for us I'm not the right guy to fix Java. So I built a Quart app with aiosmtpd to make a single program that could process SMTP and HTTP to show the incoming messages in a browser. Used for dev/staging environment to capture and view the messages our system would send out.
For the frontend component, I'd probably be looking at Vue in the future, I haven't done much on that front.
My most recent toy was replacing the backend of MailHog with Python, the existing one has been flaky for us I'm not the right guy to fix Java. So I built a Quart app with aiosmtpd to make a single program that could process SMTP and HTTP to show the incoming messages in a browser. Used for dev/staging environment to capture and view the messages our system would send out.
Say you wanted to recreate hackernews as a toy project - what stack would you use nowadays to achieve that most efficiently?
If at all possible, I'd find something someone else has done and use that. :-)
That's fair enough haha! I guess just looking for a pet project to get started with.
HN is actually a great example.
Look at the old source of it and admire it's simplicity.
https://github.com/wting/hackernews
Look at the old source of it and admire it's simplicity.
https://github.com/wting/hackernews
Yeh, I had actually briefly looked into after writing that comment and found the same - interesting that Paul came up with his own version of LISP to do it in.
If you wanted to remake it in a modern framework though, what stack would you personally opt for? I think Postgres or MySQL for the database is a no-brainer, but what about the quickest approach for the rest (bar of course simply cloning the repo ;) )
If you wanted to remake it in a modern framework though, what stack would you personally opt for? I think Postgres or MySQL for the database is a no-brainer, but what about the quickest approach for the rest (bar of course simply cloning the repo ;) )
The tool i best know is dotnet.
Perhaps controllerless, similar to : https://github.com/ServiceStackApps/RazorRockstars
But, as mentioned. That's because I know that tool, that knowledge is not transferable through a comment :p
Perhaps controllerless, similar to : https://github.com/ServiceStackApps/RazorRockstars
But, as mentioned. That's because I know that tool, that knowledge is not transferable through a comment :p
Yeh, definitely - I appreciate the input nonetheless!
React & Java
I write all kinds of low-volume webapps (e.g. for my personal use) that I use for things like workflow applications, classifying objects and controlling IoT devices.
I think it is fun to do this with asyncio in Python, particularly building systems that (say) communicate in real time listening to websockets, AQMP and some other sockets at the same time.
Every team I've been on for the last 10 years or so has used the JVM (either Java, Scala, or Kotlin code) for the back end. The strength of the JVM is that it handles parallelism and concurrency. It doesn't just claim to exploit processors with a many cores, it really does. (Before that I worked on a C# project which is almost the same.)
Python, node.js and similar things don't have a good multicore story so they are not going to hold up to heavy use.
I think it is fun to do this with asyncio in Python, particularly building systems that (say) communicate in real time listening to websockets, AQMP and some other sockets at the same time.
Every team I've been on for the last 10 years or so has used the JVM (either Java, Scala, or Kotlin code) for the back end. The strength of the JVM is that it handles parallelism and concurrency. It doesn't just claim to exploit processors with a many cores, it really does. (Before that I worked on a C# project which is almost the same.)
Python, node.js and similar things don't have a good multicore story so they are not going to hold up to heavy use.
It is worth keeping in mind that "every team I've been on..." is a bias. Your skillset on one team will drive your success getting hired on the next. I recommend that people find a tech stack that they enjoy, because you will be anchored to it until and unless you actively seek to move off of it in future jobs.
Sometimes I have done back end coding w/ the JVM in those jobs, sometimes I haven’t.
Interesting, thanks for the feedback. Didn't even consider the whole innate multicore support.
Having looked into it a bit, I was thinking something along the lines of Vue.js / Django / PostgreSQL to leverage my familiarity with Python.
On the other hand, React & Next.js on Vercel seems to be buzzing. Is that just me or is something similar what webdev is moving towards?