While this question plagues many and myself, it is as frequently asked as it is frequently debated. Whether youβre looking to make a complete web application or your first web page, the technologies you choose to do it come with their own their pros and cons. Here I am to list my favouriteβs and why.
My personal favourites
With the amount of upcoming JavaScript frameworks and the new benefits they each have, they all define a new set of rules which can limit your projects scalability with other technologies. I remember trying to use Svelte with PHP and that did not go well. That said, here is how Iβd do it going into 2024.
- Typescript (for perfect JavaScript)
- Reactjs / Vuejs
- Postgres (Database)
- Redis (if needed)
With these fundamentals I would argue that you could achieve a fast and efficient website that doesnβt compromise the ability to look amazing. React has been a good framework for me to learn regarding front end development though it can be restricting when making multiple pages. In this case, I would lean more toward things like Next.js. In reality, many organisations arenβt even using frameworks. It remains true that 70% of pages make use of JQuery to this day and the era of frameworks is still a new one, an era some are choosing to adapt to rather than others. And not in all cases is it necessary to. However you put your page online, good luck to you in 2024. β€οΈ
Top comments (110)
Honestly, I'm that one person who would build it entirely with vanilla JS, vanilla CSS, and plain old HTML. If I needed a backend, it would probably be built in Flask or Deno. My database... well if I could, JSON, otherwise SQLite3 (it's built in to Python).
I'm the kinda guy who just likes the plain stuff without layers upon layers on top.
I think if you decided to with a web app with vanilla js you would end up building a web framework all over again, unless you just need a little bit of reactivity or interactivity in which case its fine, unless you mean using something like web components
Yes, but that's one of today's problems: too many websites are web apps when they should rather be traditional websites! Some devs and product owners seem to like to overengineer everything, maybe to make it look more important or maybe just because they have a backend mindset and never really understood frontend web development in the first place. But it's still much easier to build a fast, accessible and user-friendly website with progressive enhancement, separation of concerns, more HTML and CSS and less JavaScript.
I mean, you can probably sell a webapp for more than a plain ole' website is what I am thinking. I think a big part of today's tech business world is not making the best product, but making the most expensive one and then shoving it down laypeople's throats.
My sister has a small business and IT professionals/devs always try to sell her useless crap they do their best to convince her she absolutely NEEDS, or her business will go bankrupt/get hacked/lack the necessary productivity etc etc. They back off really quick when I start asking questions.
Right! like every second startup think they need an app, maybe because investors tell them that they would.
I might do something like this, to make it easier, if that's what you mean:
But I don't think I'd do much more.
You can use this cool function to create elements:
see also here, here or here.
I once thought "Wouldn't it be cool if I could just write
html.span("content")"Then I built that.
Then I thought "Wouldn't it be cool if I could add attributes in the same function?"
Then I built that too.
Then I thought "While I'm at it, why don't I make it so I can attach event listeners as well?"
And I built that as well.
Then I figured "It would be nice if I could pass in a listenable state container, instead of a static element, and have it update automatically"
And, even though it was a bit more complicated, I built that as well.
I don't know at what point I'd draw the line, but somewhere along the way, I stopped making "vanilla JS" more usable, and started building my own micro-framework.
This isn't to say there is no merit to minimalism; to me a micro-framework is still better than something like React, but I've given up on this idea that "vanilla is enough". Rather, I'd say "frameworks needn't be big and bloated".
Then you should have a look on VanJS, that implements all this. Tao - the author and a brilliant programmer - managed to pack all this in a very small lib of less than 1 kB.
I've had a close look at VanJS not too long ago, when I first found out about it and overall it seems cool. Overall it appears to have independently reached some of the same conclusions as I did with my own project, but to my personal taste, it's just lacking a variety of quality of life features like turning
myElementintomy-element.My own library is only a bit over 200 lines long, so it's not like I'm paying an unreasonable price for those few extra features anyway.
But still, if VanJS had appeared a few years faster, I would probably be using that right now. It's a cool project and I absolutely feel validated by someone else coming up with the same thing on their own π
You should not care too much about the library size. VanJS is increadibly small, but even the VanJS-Logo is about 17kB long. In real life size does not seem to matter so much.
I had a similar project three years ago named DML, which targets more on writing compact code. So I put anything useful into the library which was about 30 kB in the first version. But you do not recognize this in a real life application. The next version anyway would be much shorter and can be used with Rollup.js.
I would have been happy to combine my efforts with VanJS, but it was so important to Tao to save even the last byte, so he did not want any extension. Now there is only a very short wrapper that adds some basic DML features to VanJS. If you like, give me a hint where I can find your lib.
Maybe try out github.com/Uiedbook/cradova
What a pity! There are so many projects like yours (and mine...), but there is not a single one that has enough traction to focus all the effort.
A library provides only the core functionallity. It would be fare more interesting to create functions and classes, that provide more complex solutions, like a page structure or a complex ui element. See this post as an example.
From my experience, building the DOM from Javascript solves 90% of the problems most web designers have to struggle with.
It's a good thing PWA's exist... I veer away from frameworks unless it's a massive project. Progressively enhancing to support app-like or native app when necessary.
I think this is a good idea for many people to start with!
HTML, CSS and JavaScript are an awesome foundation and I love working with them. I think there is nothin wrong with that.
Sooner or later, you may encounter various problems. If you learn more about and understand these problems, you will appreciate many solutions that are available out there.
The fact that many people complain about complex solutions is, in my opinion, due to the fact that they don't understand the problems well enough.
In this context I remember this page vanilla-js.com/ π
Embrace tradition!
Sounds scary to me dude
Same. The only difference for me is I may or may not use SCSS and I wouldn't even think to use SQLite.
Good enough for one's hobby site, yes.
I'm with you. I feel that sometimes we do not need layers over layers for most of the things.
Exactlyyyy
When you say JSON for a database, do you mean something like MongoDB or literally storing the data in a JSON file?
Like @joshuaamaju said, I meant JSON file.
Oh ok. I don't think it really makes sense to call that a database, more just a constants file.
Have you implemented it in any production environments?
I've never been part of a production environment. I'm just a hobbyist :)
Have you tried using JSON as an alternative to database? If yes, how did it go?
I am working on a personal project that would require me to store some data. Its not too much, so I think using a database like MongoDB(which i have to learn about first) would be necessary for me. And like you said I also like things plain and with as much as required. π
I haven't tried, that's one of the next projects on my list :)
I've used JSON in a production environment many times. It's fast and easy. I've never had more than about 5,000 total users (and even that only on one of my apps) and it's worked great for storing user data and the like.
JSON file I think
If he/she is anything like me, it's just a JSON file, maybe encrypted.
I absolutely agree with you. Just keeping it clean!
That's just disgusting.... I doubt you work as a software developer. I'm guessing you're just a hobbiest because the way you code will never scale.
To be honest, I'm in love with this combo!
how can nextjs be full stack?
Source: Nextjs
βNext.js enables you to create full-stack Web applications by extending the latest React features, and integrating powerful Rust-based JavaScript tooling for the fastest builds.β
It is full stupid instead of full stack. Nextjs is merely an extension upon react.
true, and backed by a fully profit company that drive it in their favour.
This sounds solid! Is there a reason you prefer no-sql databases? I'm curious. Have a nice day β€οΈ
Nah, just hate SQL for no reason. Stupid me. π
Lol
i completely agree with this
Currently, I'm also enjoying this stack
Me too.
It feels really exciting to use this tech stack
It depends.
It depends if you actually have dozens millions of clients with huge expectations
And if yes, then please do lots of research.
If not, then YAGNI.
It depends then if you are alone or in a team.
If you are alone, I would choose the simplest thing that work and that you are comfortable with.
If you are in a team, I would choose the simplest thing that work and that you and your colleagues are comfortable with.
Your clients very much don't care about your stack.
They would like us to also focus on their problems, and if possible, solve them.
If your keep things easy and simple, you will have more bandwith to focus on what really matters.
At the end of the day, clients have no use for your code
Next is pretty bad performance wise for most use cases due to it being dependent on React which has awful boostrap performance (140 kB total JS code to parse, that is the size of
react+react-dom). Next also adds in even more code with it's client side router, slowing initial page load even more. Next appears to be snappy great perf once it's SPA is running (on a performant device), but when loading via native HTML page load it is never good, and on low end devices React apps struggle quite often.Astro would be a better choice for vast majority of cases people consider Next for as Astro allows to avoid requiring React for everything. Instead you can have a React SPA portion on your site where needed. The rest can be zero JS or light vanilla JS like HTML web components. It is pretty easy to make a 100/100 perf score site on Astro without even trying. That is something you never get on a full React stack site.
Astro also provides much better tooling for handling CSS scoping out-of-the-box than Next does. Next's best thing is probably CSS Modules, Astro supports that too but you can also throw
<style>on an.astrocomponent and it will become automatically scoped. You don't even need to spend time naming classes if you don't want to do that,article { ...styles here... }will be scoped appropriately to the component. You can have everything you need in one file.TypeScript is nice for backend code and for a complex SPA, but for the true front-end code that runs only on browser with events and DOM manipulation etc TS just gets in the way by being silly due to being unable to know the context well enough. Most of such code is also rather short and simple, so TS often just adds unnecessary verbosity and forces checks where they're not providing any meaningful value.
I don't claim Astro be the best though. It is just better for most use cases people use or consider Next for.
Astro is the best match for almost everything.
Astro + htmx + Alpine
I've never seen nothing simply, easy and optmized like AHA Stack
Websites in general: HTML, CSS, some JavaScript/TypeScript, and some server-side routes using either PHP or JS/TS, so that we can reuse header, footer, and other fragments.
To build content-heavy static websites, Jamstack is still a good choice (eleventy, gatsby, Hugo, etc.) or if you must make it editable by non-tech website owners, maybe even WordPress (with a hybrid theme, custom fields and custom post types so that they can't edit more than they need to!)
For building a complex, interactive, web app with a lot of client-side logic, we might use Svelte, Vue, React, or Angular, with or without an additional next/nuxt layer, but that still doesn't come with a standardized backend. So I would go for Symfony with PHP, Twig, Vue, TypeScript, and Doctrine - a database abstraction layer to prevent devs from writing naive or unoptimized SQL queries. Although I think that I know SQL, I would not recommend to use it directly for security and performance reasons.
As you mentioned jQuery, there is a lot of legacy code out there. Still, even worse, LinkedIn just launched a series of collaborative articles about topics like web development, obviously based on AI-generated content, so juniors reading those articles might be misled to think that jQuery and Flash (yes, Flash!) might be a valid option for web development in 2024. I didn't know if I should laugh or cry, so I added a cautionary paragraph. Here is the post: How do you become a Flash developer? Powered by AI and the LinkedIn community
Is youtube "a website"? Is amazon just "a website"
To build "a website" in 2024 you just need some HTML and CSS, this did not change over the last 30 years.
Maybe you should be a bit more specific in your title! What is "a website" in 2024???
A tech stack usually refers to the common baseline of technologies used. Sorry for any confusion β€
You are not confusing anybody, this is more a general topic. People are doing very different things on the web, but anybody seems to know what the best "tech stack" is.
The web is much more than just a collection of websites, that it was designed for 30 years ago. It is an operation system running distributed applications with a broad mix of technologies. If I want to create an amazing graphical artwork, React is probably not the best platform for me. And IΒ΄m not sure if it outperforms wordpress if you have a content heavy project. Depends on your skills, your task and also your team.
So, please ask for the task before recommending any tools. People can make a hole in the wall using a hammer, but it could be a far better advise to use a drill... Depends much on the hole you need.
Very well said. I am tired of these tech junkies who just want to make noise
This is very true. Using a framework for something that could be an HTML document is just as questionable if not more so than building large systems with complex state management in vanilla/jquery.
Know what the right tool for a job is π
@wii what was that micro-framework for js that you built?
There's no "perfect answer", but I do think Django is pretty dang good. Most stuff you need comes out of the box, and while getting it to play nice with a frontend framework can be tricky, it's certainly doable.
P.S: Don't prematurely optimize. That's the biggest mistake in any framework choice. If you need to create 3 info pages for a local business, do you really need React, React Router, Tailwind, PostgreSQL, etc?
Django is a great choice!
This is probably a "hot take" but I only use Javascript on the frontend. I'd pick a scripting language for the backend such as PHP, Python, or C#. I love Vue for the frontend components. I don't get the love for Javascript on the backend.
Personally, it's just about choosing anything that is mature enough for your requirements, has a nice DX and that you think is the easiest to migrate from to another stack once it's needed.
I've recently moved from a more agnostic NextJS (BFF) with .NET API implementation to a full stack .NET with Blazor one. It handles all my use cases and the DX is amazing. My productivity at least doubled.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.