Tech Stacks - old school vs. new school
How important do you think is the tech stack upon which you've built your product or service?
One of the questions I'm often asked as a tech founder is what tech stack I used.
By "new school", I mean building an API layer and a separate front-end architecture built with React/Vue/etc or a Single Page App (SPA). The back-end could be Node/C#/Laravel/etc . These are usually deployed to a cloud/distributed services environment on AWS.
By "old school", I mean a monolithic app that is more self-contained and can be run on a single machine/VM. Code may well be organized using the MVC pattern, but it's not broken up into a back-end and front-end. Plain old JavaScript and/or jQuery.
My viewpoint is that the "new school" approach is not as important to build with as it's made out to be. In fact, it can be more fragile because of dependencies and reliance on a single eco-system (looking at you, Amazon). The "old school" approach is more boostrappable and one can go a lot farther than a lot of "new schoolers" may realize - i.e. ramp up your VM as needed to meet demand.
I think a "new school" implementation really shines when your service needs to scale to millions of concurrent users. At that point, a rewrite, if a complete one is actually necessary, is a "good problem" to have and the money to do so shouldn't be an issue, right?
Think you nailed it 👍
By the time you get to millions of users, you'll probably have rebuilt your app a couple of times, so you can decide on the best stack to use at that point. Start small and move quickly, which is often easiest with old boring tech.
I'm using the boring tech stack. rails, mysql, turbolinks, jquery, bootstrap for all my apps. If you ask me why? It's easy to maintain in the long run(>3 years) compare to JS heavy app.
I do have several rails SaaS apps from 2010, and running with no maintenance at all.
I was late to the switch over. One of my most popular side hustles is still written in an “old school” stack, but I quickly realized the limitations to the “old school” stack, and since then I have been building everything in a “new-school” stack.
My current stack of choice is PHP/Laravel for the API layer and either VueJS (for SPA), NuxtJS (for a Universal WI), and Flutter for mobile. But I am also doing some Golang for serverless functions.
If I had the time, Laravel + Vue would be my preferred stack.
My latest project is LAMP + jQuery, because I had heaps of code I could reuse from nearly a decade of previous project work. I was able to bring the idea to fruition in less than 90 days. Not having to rewrite it right now saved me MONTHS.
What limitations did you hit?
Despite being into new school languages and frameworks, I'm definitely in the "old school" camp in your framing since MVC frameworks are productive and as an indie that's what I want.
When working as an employee or even contracting, I've pretty much always used a SPA and often the whole AWS mess. Unlike indie me, companies that could employ engineer me, have lots of money, at least a small team and expensive office space. They get more of a return on marginal improvement and they can mostly afford to ignore infrastructure costs.
IMO I'm not sure it's as much of a new school vs old school debate, when you're at the start you should just use whatever gets the job done and you know how to use.
It's hard, I catch myself coming up with cool ways to make a product more efficient and/or scalable and I really have to force myself to be disciplined - I guess it's something that gets easier with time
A few thoughts...
The only principle that is really important and "new-school" is:
That's because you might want to support (mobile) native app and/or 3rd party integration.
Great thoughts, thanks for sharing them. You add excellent points.
Could you clarify what you mean when you say front and back end are always separated?
I consider DBA code (queries to the database/data store) as part of the back-end. It’s possible to build something without doing proper MVC (or no do it at all), in which case the only separation is the database/data store. Perhaps this isn’t properly considered part of the “back-end” and my confusion is semantical.
SPA to me implies virtual DOM, which I’d categorize as (very) new school.
There are really two "applications" in any webapp (or Internet-connected native app for that matter): The application that runs on the client (which you, as a service provider do not pay for usage) and the application that runs on the server (which you pay hosting cost for).
In the very early days, the client application was a non-modifiable program, called a browser (HTML, no CSS, no Javascript). By abuse of language, we considered in those (very) old days the application to be the code running on the webserver.
As soon as a virtual machine (Javascript) was introduced in the browser, then an application was really two applications, the one running server-side in an environment we, service providers, trust (backend) and the one running client-side in an environment we don't control nor trust (front-end).
Along as it is non-zero, the amount of logic being run client-side doesn't really matter, you have to architecture for front-end, backend and a communication protocol.
Now, once we pass the current technology limitations and we have a server that can optimize code and decides automatically what runs client-side and what runs server-side, maybe dynamically based on latency, etc. we could write a single app. We will still have to mark what data is sensitive and what data is OK to process client-side in an untrusted environment.
Thinking front-end and backend will always matter, but it should be done in terms of mutually-distrustful environments, rather than it terms of web frameworks or technologies.
Ah, ok, thanks for that great exposition.
I guess I should have been more specific when I wrote "it's not broken up into a back-end and front-end" and said something more like "the front-end and back-end parts of the application can be developed more independently of each other".
It is a very interesting trade-off. The more the front-end and backend are developed independently, the easier it is to scale teams of engineers (front-end and backend). The more front-end and backend are integrated, the easier it is for an optimizer (old-school; new school would say AI:)) to make the right choices in terms of performance, scalability, and reliability of the system as a whole.
Hybrid between new school and old.
Take what works.
I think the most important is not "old" vs "new", it's more "choose the right technology for what you're trying to do". The right technology means the simplest ones, without a lot of dependencies.
The biggest problem you could have is using so many libraries crippling your app with bugs at each update. Don't update them and you will have serious security issues.
I find VueJS simpler than jQuery or plain old Javascript for example. You could go with Laravel for the backend, but I think Golang is simpler as well to use at a early stage.
AWS is definitely not really useful for early stage.
Fast to write and to use, simple to scale and debug. This is what you should go after.
Use whatever stack that'll launch your project the fastest.
If your goal is to learn some new technology, or build new skills — by all means experiment and try a new stack/library/etc.
Personally, I've found if I start adding new library/stacks, my focus gets distracted from shipping a project, to just tinkering around.
It doesn't matter. Pieter Levels has got rich from one file PHP websites.
Woah, thanks for letting me know about this guy, just checked out his website and Twitter. Cheers
no worries!
I think you are from "old school" generation that's why you are pushing "old school". Remember "new school" can be great too.
For example, Prisma wrote there v1 in Scala but now they have to do the same thing again in Rust for v2 which is taking a heck of a lot time because even a simple Prisma v1 application required you to spend ~$20/month.
I think rather than looking it at "old school" vs "new school", think about what you are proficient at & use that. Sometimes it helps to use "new school" because they are improvements over "old school". React is a better improvement over jQuery. Amplify is a better improvement over writing your own database.
And I don't think it has to do anything with this. Sometimes development speed matters too. Writing in React has to be much faster than vanilla DOM manipulations using jQuery. Trust me, I was writing vanilla JS a few days back for Chrome Extension & it told me again the superpowers of React. It was taking a lot of time to find DOM manipulations & this wasn't even a big project.
Anything works "old school" or "new school" if you know the technology well. The only gripe is think about development costs if you have to later rebuild the whole thing because sometimes it takes a lot of time. See Prisma for example :)
I entered the industry making SPA and did that professionally for years before really learning a back-end MVC and completely disagree. Rails and a sprinkle of JS is far more productive than a React SPA for me, even though I have at least 5000 more hours of experience working with the latter than the former.
That's completely okay. Meanwhile, I never learned Rails & I don't have to because I am a lot productive with React & Node. Of course, I went this way because I liked JavaScript. And I get it IH audience disagrees with me for the same reason 😂
But my point is it's never "Old School" vs "New School". It's first, use whatever you know & you are productive with; second, don't get burned if the thing you are productive with will backfire later so spend at least some time thinking about that too :)
I think this post shouted "Old School" is a lot productive but some of us never learned "Old School" way & "New School" is totally fine. Not just for, as stated in the blog post, "millions of concurrent users" which is totally false.
I had the same belief for 3 years, while working as a JS dev in SF/SV. I just didn't realize I could be more productive with something else! If you've never even tried the alternative for a few weeks, maybe you'd be more productive with an MVC, too 😉
I come from the "old school" era, that's true! But, I think you misunderstand my view on "new school". I agree with you: it's great!
I just think that it's wrong to emphasize it as the "only way" to do things going forward. I think that all too often when one learns the "new school" first, and it's advantages over the "old school", then one evangelizes it as the "only way".
I am familiar with both "schools". I think it's valuable to learn both; their pros and cons. And choose the best approach for a particular project, keeping in mind the developers' proficiencies, as you and others have mentioned.
I thought you were pushing go "Old School". Apologies if it wasn't your intention but this statement is untrue "I think a 'new school' implementation really shines when your service needs to scale to millions of concurrent users.". That even "old school" (Ruby, PHP) can give & sometimes probably simpler than the new tech (Node).
But I have to disagree with you that "it's valuable to learn both" because I don't think so if I know React & Node, I would wanna learn Ruby & jQuery at this point :)
This comment was deleted 5 years ago.
This comment was deleted 6 years ago.