I'm so tiered of these "Build your first REST-API with Express.js" articles.
Seems like, writing such an article is the first thing you need to do,...
The discussion has been locked. New comments can't be added.
Please see my last comment here: https://dev.to/sebastian_wessel/comment/274dk
For further actions, you may consider blocking this person and/or reporting abuse
This article has a huge problem, because you can write this article for all frameworks you mentioned. So your provided answer is not helpful. Why not describe the problem as that what is, and then can ask: "Is there a need for using dependencies in beginner tutorials?". All others are opinions and preferences, nothing more.
@webograph It's not my intention to provide an answer here, tbh.
The intention of this post is not to be polite, soft or smooth or even present the perfect solution 😈
It's about to kick people's a** to come out of this Express.js rabbit hole and take a look what happened the last 13 years.
It's my intention, that people are starting such discussions like here.
That they are taking this discussions to their co-workers & friends.
Because then, they might start thinking about something better, and they might invest their time to provide better articles.
Google "express rest api" = 47.500.000
Do we really need 47.500.001?
You're not going to accomplish anything that you intent like that
You want people to take a look at other technologies? Simply stating "this sucks, use this instead" is a child's take. Give reasons of why this stack is better than this one, and then you'll trigger a discussion
Also, btw, "I do not understand why people invest time over and over again on same things", really? When you're interviewing for a position you say "I want to use this cool technology and not whatever stack you guys work on because I won't learn old things"? How does that work for you?
I pointed it out:
Express.js is slower, callback based and there is no progress anymore.
The code you build now is simply deprecated while implementing.
Give me the point, why there is any need to write an article over and over again on how to use express for building a REST-API. See the other comment - google returns 47.500.000 results on this.
And in each article it is always the same - because nothing changed or will change here.
And about your other question.
It’s my job to directly say to clients and companies, that it isn’t a good idea to build something new based on latency dependencies.
All the guys are talking about “it worked for many years and will work for many upcoming years”. That fact is still valid, but it is the wrong mindset if you build something new for future use.
It’s building legacy systems which someone needs to maintain in the future.
Don't know why your limiting yourself to node technologies. Even so not sure why you didn't list nest and next. We started our app in next, moved it to express, the ssr was underwhelming with react that is a single page app, conflicting Abstractions resulting in full page load on everything. It's built for blogs and nothing more, hence we had to move or we'd be fighting the framework. There aren't thst many frameworks out there that are truely "modern"... meaning same language front and backend, shared code front and backend, not ones that I would trust enough to build ANY application optimally.
I didn’t list all frameworks because - as I said in the article - there are a lot of them.
I tried to select the ones especially related to REST-APIs here and the ones which are close to plain express.
nest.js uses express or if you like fastify under the hood and is a way more than “simple Webserver” framework.
Next.js I didn’t list here as it is some kinds of specialist for react.
Personally I try to not limit myself only to node/typescript, but as I’m a typescript developer for many years I’m kind of “in this universe”
But seriously - look at all the comments:
“it’s old, it’s proofed since years, we don’t change anything”
How to keep the speed with everything around - from frontend up to Infrastructure - with such “agile, modern, experienced, open minded” developer mindsets 😂
Now you know why you need to move to something and start fighting with stuff which should help you do become faster and make your life easier.
Yawn, nobody cares. Nobody likes a complainer that doesn't present a good alternative. You article has zero value and achieves nothing if it just complains for the sake of complaining without presenting a solid argument on why the proposed solution is objectively better. And no, "slightly faster and API you like more" are not good enough reason to justify expensive migrations.
Who was talking about migration? Not me!
I was complaining about these daily articles of "beginners guide to build REST API with express".
I only said, that there should be more article about other stuff, showed some examples which come into my mind.
I told my opinion, to not use express for new project...
...that's it.
People went crazy about this headline, as I like would try to burn their house & kill their family, but totally missed the point I made. 🤣
But yeah - 12.000 views will be shorty reach about this article.
It was not intended or expected, that they all went totally crazy about this 🤷♂️
Very intersting to see...
Your article's title is "Stop using express.js". Not "Stop using express.js for beginner articles".
If it's anyone's fault, it's yours for using such a bad title. And one that is clickbait heavy too. Hopefully you learned your lesson lol.
See the other comment - you're welcome! 😘
Maybe the reason not because of its being popular but the immature of other libraries. Express is not a framework by the way. You can find a numerous frameworks that use express. Now if you can’t give a legit reason why should we NOT use a stable library? What is the purpose of the sw you’re making? Then it will be still there for much longer time :)
I call express a framework, because if you take a look at the official website:
“ Fast, unopinionated, minimalist web framework for Node.js”
The core express package is a lib - that’s right. But express is a whole eco-system and the kind of mother of webframwork pattern in node universe.
The legit reason is for example, that it does not support async-await style.
And this means, you write code in a way, you shouldn’t anymore.
The other reasons like Performance and so on are coming on top.
I ask you more or less same question;
Why you shouldn’t use some other stable, mature and proven lib here, which allows cleaner code with performance benefits?
ok. but what's the objective criticism?
I prototype from scratch. Using express and socket.io, I can have secure messaging running over HTTPS in literally seconds.
It isn't broke, I need your help in understanding why I need to fix it, please.
It’s not about that something is broken or doesn’t work.
The thing I like to point out is, that you can’t expect any improvement or progress from express.
It will simply stay at same level as it is since years.
And this makes no sense for new projects.
In this article, if you replace express with some not so popular lib/framework, nobody would argue “it’s proven that it works - we never move forward to newer stuff”
Mostly everybody would argue “this is dead, you will need to migrate it future, you don’t get new features, no performance updates to expect”.
In your example - if you don’t need endpoints and do more or less only websockets - you don’t need express at all.
You can use plain node http(s/2)
Also, you can have a look at feathers for this example - maybe it fits best for your needs, as it is made for real-time communication over websockets. 🤷♂️
It’s about to be a bit more open minded and more focused on “what fits best” and on “does it make sense in the future”
With all due respect, you feel to be a bit close-minded about express.
This is not a jQuery vs. React or even jQuery v. Angular type thing,
The packages you mentioned are not objectively improved. As I stated, because I code from scratch, without many dependencies, it's much more efficient for me to use express than other more bloated frameworks.,
What are you thoughts on that context?
I personally prefer also the lighter ones in most cases.
I used micro in the past, sometimes plain node 🤷♂️, sometimes Fastify...
Over the time I got them all I guess.
Currently, I prefer (love) Hono.dev - it's fast, it's lightweight, cool approach, really nice and active contributes which are reacting instantly.
I mentioned the handful, only to show that there is much more out there, with the hope in mind, that people are commenting like "Hey you missed XYZ".
But, as you can see, it didn't work as expected 🫣.
Yeah, I agree.
I'm gonna bet though, if i'm stuck on an issue with Express JS and i google for it, i'm gonna find a lot more helpful/useful answers than i'm gonna find for any of these other tools you just linked.
At a glance, the code examples for all of them look pretty much like a basic express setup, so why would we bother switching?
And once you understand express and have working and reusable code, again, why would you switch?
The biggest problem in javascript world is that there are a thousand ways to do the same things and for some reason everyone assumes the newer ones are better.
I've got some 15 year old PHP code running flawlessly, untouched for over 10 years.
Some times old code runs just fine. Granted vulnerabilities may pop up, but the average isn't gonna draw in some serious hackers to actually abuse those, so you're fine as long as you block bots.
With your mindset, there will be no progress at all. Will simply stay in 2010.
Any of the mentioned frameworks outperform express.
Resources are simply money - especially in cloud environments.
They all are properly maintained (except koa). The communities are active and there are a lot of material available.
Sorry, but a can’t agree with any of your arguments.
If you buy a car, you wouldn’t choose the 13years old one only because it’s proofed that it worked, when you can have a new car with more features, better interior and lower fuel consumption for the same price.
Because new cars and appliances break down all the time. Old and reliable is a premium.
@thirdender Oh dear 🙈. Yeah, and if you take a horse, you can eat in worst case. 😂
That tells us you have zero experience with how real large-scale companies operate.
If a massive company is looking to buy a fleet of thousands of cars for their business, they will seldom just pick the "newest / shiniest car on the lot". Reliability & cost of maintenance matter HUGELY, even far more than things than fuel efficiency sometimes. Because of this, they have been known to buy older models from companies with an established track record of reliability.
By your logic, we should all be adopting the latest cutting edge software all the time, bugs and learning curve be damned "because reasons".
Change is hard and expensive. That is the reality of how real businesses operate. And to justify change, you need the new alternative to be better enough to justify the costs associated with such change.
It's true that there is often such mindset as seen here.
But, let me simply ask who is bringing this mindset to companies?
People like those who commented like "it worked before and will work - no need to change anything"
Companies do not have any opinion. The opinion comes from the people of that company.
You're right with "change is hard and expensive".
But does it become cheaper & easier or harder and more expensive if you simply wait longer until it becomes urgent?
And again!
My article is not about replacing all existing stuff!
It is focusing on building new stuff and the 45Mio+1 beginners guide about express+Rest-API.
Sorry to annoy, but async-await is no "latest cutting edge thing" and express is simply not evolving anymore. It stands still in time.
It's not about to use the recent, newest stuff.
It's about simply not to move forward, to not evolving and to use old stuff because of simply laziness.
Decades of knowledge of how technology works. There is no "someone" bringing this "mindset" to the table. It's simply common knowledge that change is expensive and that when done poorly, it can have disastrous consequences. A great example is Target's disastrous Canada entrance which failed due to a poor migration path to SAP as a software ERP implementation.
youtube.com/watch?v=DSGVlnFtSoo
Anyways, good luck convincing people. Though judging by the comments, most people are smart enough to not fall for hype driven development.
Nobody here is saying change is impossible or should not be done. We are just explaining you need strong enough reasons to justify it. And you clearly don't have these. And arguing any further is just a waste of our time.
Agreed, change happens all the time.
In this industry, change is literally the way of life.
We HAVE to learn new things to remain relevant.
My original comment was that these tools that Sebastian listed are barely used by anyone. I'm talking % of websites created in the last 5 years, it's probably less than 0.1% using all these tools combined versus express because Express is what pretty much every tutorial teaches.
Sebastian chose to ignore my first statement, which is when debugging these things, i'll find a lot more answers on how to fix and do things with Express than any of these other ones.
To add to that, i KNOW Express isn't going anywhere. Because it was so heavily adopted, its code will be there and functional for years to come. Those other new tools, if they don't get popular enough, their team will move on and it will sit there dead, some unmaintained repo amongst the millions of dead repos on github.
Use tools with wide support if you want your things to last. Don't use the latest and greatest libraries/framework/tool just because it's new. Most of them fail within a few years.
Then again, most websites should be rebuilt within 3-5 years, but budgets matter to businesses and they won't rebuild unless it's hurting their bottom line.
With today's flat designs, most sites don't need updating for much longer, but that varies from business to business.
Personally, i know how to use all of those tools, without ever installing them once.
Why? their code syntax is a ripoff of react/angular/vue. Nothing original to them.
It's "npm install thisthing" and then a few other commands, and NONE of them has tutorials on setting up proper SSL, proper security, proper input validation, configuring emails, etc etc etc.
You still gotta stack overflow all that to hopefully find one person who wrote it all down, versus cobbling together 5 different tutorials that all did it partially right in order to get things done right.
"oh they perform better"...that's nonsense. Show me one website where it even matters that they can do 1000 ops/s versus 995 ops/s or whatever their nonsense benchmarks are. Benchmarks have practically zero relevance to real world projects unless you're building google/facebook/twitter/youtube etc, and let's face it, almost none of us work on anything that big, ever. [thousands do, but there are millions of us, do the math]
And if you're working on one of those, you're not using any 3rd party tools either, everything is built in-house to the point where they even pushed their internal code out to the world so they could hire all the best devs who by interview time already knew their frameworks [React/Angular specifically]
anyway, end rant.
To have at least the final words in some proper English, which is hopefully not misleading as the headline of the article. And with the help of AI:
Thank you for your insightful and constructive comment. I appreciate your perspective, and I respect that you hold a different opinion.
While part of me would like to respond and engage in a debate about the points where we disagree, I have decided not to do so. I believe the comment by @ravavyr is a well-thought-out contribution and could serve as a final comment on this matter.
I have decided to close the comments now. It is time for all of us to put an end to this madness. The level of engagement this article has received is staggering and somewhat overwhelming.
To give you an idea of what I mean by "madness":
Since its publication, this article has garnered an astonishing number of views, reactions, and comments within a span of fewer than four days:
It has even consistently ranked in the dev.to TOP-Weekly-10 for now at least two consecutive days!
And the number of views continues to grow steadily as I write this comment.
Although I may be repeating myself:
I want to emphasize that my intention in writing this article was not to eliminate Express.js from every existing codebase or to cause any harm or controversy. The original intent and reason behind the article are explained in the first two sentences, not in the headline.
🙏 I apologize to any readers who had different expectations due to the misleading headline.
In the future, I will exercise greater caution and thoughtfulness in my approach. Thank you to everyone who participated in the discussions, arguments, and reactions.
As my final words on this article and topic, I want to share a few thoughts:
Please consider carefully whether writing yet another article on the same subject, adding to the existing flood of content, is truly necessary.
Instead, I encourage you to support and promote the open-source projects that you appreciate and perhaps already use.
Try out new tools and technologies, recommend them to your colleagues, and consider implementing them in your next project.
Only through active engagement and support can these projects gain popularity and become mainstream, rather than fading away on a forgotten GitHub repository, leaving frustrated developers behind.
Many exceptional repositories have become dormant because they lacked sufficient support from the community.
❤️ Let us be grateful for and show respect to developers worldwide who selflessly contribute to open-source software, without financial compensation, rather than simply going out and partying. This software is freely available and used by all of us.
My post is not about legacy and existing code base - it’s fine if it runs vor centuries.
But why should anybody start something new, based on legacy code? It makes no sense at all.
I dont understand why you think express is legacy. Look up the definition of legacy. Is angular and react legacy? Angular and react is about twice as old as all node technologies!!!!
It’s not about the age itself in numbers.
Older version of Angular and react are also legacy - even if they work.
Do you build node backends in plain JavaScript right now or do you use typescript on top?
Do you use async-await, and other features provided by newer version?
Why do you think it’s not legacy?
It's not legacy because it doesn't meet the definition of legacy: "A legacy system is outdated computing software and/or hardware that is still in use. The system still meets the needs it was originally designed for, but doesn't allow for growth". One example of legacy hardware would be vacuum tubes, for software it might be a guys pacemaker firmware he got installed 20 years ago. A mainframe that is still in use today and working fine is legacy. Legacy is rare in web software world, most applications die before it even becomes a consideration. To have something you design become legacy is a good thing... as engineers the best we can hope for long term is to have what we design put in a museum... but if it's legacy, it's still used and a it's a huge compliment to the engineer... 100 year old trains, the empire state building, the effiel tower, all legacy construction.
To put express in the legacy bucket, literally the most common node api framework, it's either an attempt to be intentionally insulting to node developers or it shows a real lack of knowledge, but i suspect its both... to make it worse, this is presented in an article that draws zero distinction between fact and opinion, its a teaching tone without really saying anything and without providing quantitative evidence for the facts or real qualitative justifications for the opinions... your just telling it like it is, as if your brain forms our reality... thats not how humans work, we have to be convinced not told.
So you didn't make any friends with this, I certainly won't be back... if you had not responded to angry readers, I would have assumed this was written by a really bad AI in india.
Javascript is not legacy, it's the backbone of every single framework we are discussing.
To be honest I love that Express.js is so incredibly stable. I may have to rewrite my frontend because Next.js wants to prioritize the app dir / RSC. Not so much with my backend API. In fact my Node.js/Express backend has served my frontend from Angular to Vue to React. I care about business value, not the flavor of the month.
Yeah I totally understand your point, but this is nothing around flavor or some hipster thing.
The business value here is not directly visible in terms of how fast or easy you can deliver.
It comes in terms of code quality (call-back-hell vs clean async-await) & maintenance costs and maybe on larger scale on runtime costs (cloud-price-per-sec and so on).
Express.js is working and will work in general, but because of the simply laziness of developers, there will be a future trade off and better approaches don't become mainstream.
Also if you use Feathers, it might fit better, when you need realtime communication to the frontend - something you need to implement in express.
If you want input-output-validation and OpenApi documentation, you can do it on express - no question. But there are other options which are faster, without any special thing which might also reduce duplication of defining typescript types, schema-validation and defining openapi separately.
If you read most con-comments its always "It's old, it's working".
This is simply laziness and closed mindset.
But how to move things forward with this mindset?
If you always write about same thing and always use the same thing, you stand still.
It's definately a trade-off between the old and boring and taking a bet on something shiny with less of a track record. As a side note, I do like the concept of Feathers.js and did some testing with it years ago. I however opted for using socket.io on express and not be confined by feathers.js rigid crud mappings.
Anyway, thanks for the article. It's good to ruffle some feathers every now and then.
Had same experience with fathers.
It’s simply made for exactly one purpose.
I mentioned it because of its cool concept, and didn’t use it for same reasons as you mentioned 😂
Who do I send the invoice to refund the time it took me to read this?
You’re welcome!
You could probably find the author of this article on the definition of a Hype Driven Developer on a dictionary lol.
Just like "React" articles
@spock123 You might be right here.
I do not understand why people invest time over and over again on same things, while there is so much interesting stuff going on
I think people are comfortable in what they know and know well, I guess.
Easy, because most companies/developers are smart enough to not fall into hype driven development like you are right now.
Smart & experienced developers don't fall for hype easily, and smartly assess hidden risks such as cost of adoption, established reliability, maintenance costs related to community size, etc.
What do you talking about "hype"?
I mean, I mentioned stuff that is years old and mostly a standard pattern.
I would understand your arguments, if I would promot the newest sh**, but don't.
And btw:
Smart developers think of building software that needs to be maintained and handled by someone in future.
Seem, youre going always for job-safety without care of how much money it costs 😜
Hype Driven Development doesn't just apply to "new" things, but any change that is "poorly justified for the sake of it". This mirrors the arguments you made for all those libraries "just because express is old". You are by definition a hype driven developer.
I wonder what developers will have an easier time maintaining? A codebase with a "newer, but less popular framework", or something using established framework like express with 10-100x the search results + documentation?
Lastly, I think you need to improve your English since that last point made no sense.
You don't see the point, that there will never be some alternative, as long as everybody is only using express, while express itself does not go in any direction?
And yeah, might be, that my English isn't so good and need some improvement.
But you know what?
I prefer to have a poor English, but be a bit more kind to other people.
I don't know why you need to start such bashing on personal level.
Maybe think about yourself, your mindset and behavior - it makes the world better, if we can simply have different opinions and arguments without trolling 😘
I am so glad that I and the company I work for have moved away from using JavaScript for backend development and started using a proper compiled language instead.
Can I ask what are you using now?
Would love to get here/read some experience about this.
Think the current progress regarding wasm will open the door here for other languages in future.
Typescript? 😛 Why do you think compiled languages are better?
Different discussion I guess.
But I don’t get it why everybody is so against something.
Let’s build cool stuff together!
We use typescript, someone provides some cool wasm build with compiled strong types in rust-C-C++ and someone else is using the data from this in Python to be presented in the frontend in browsers and native Apps!
That’s what we should do!
Just my 2cents here 😂
Agreed! It's not the ship, it's the captain! Not the tools, but how you use them.
OMG. So much hate in comments. Reading and wish to hug Sebastian to support all his intentions.
Yes, title is a clickbate and you may hate yourself reading it if you were expecting article about critical express.js issue. But...
Thanks to Sebastian to list few cool express.js alternatives for you to learn and maybe apply alternative patterns and even use them for your next project.
"Stable, reliable, bla... bla..." Yes, but only 20% of such frameworks are about request/response communication stability. Biggest part of it is about structuring your "mind"(code, project, team collaboration). I used to "all in middletiers" approach of express.js, but this article allows me to discover a "service" based approach provided in Feathers.js and I see how this could help my team to deliver a better API going forward.
"47.500.000" argument is valid, but it's within our power to get other framework to similar numbers and this article got us one step closer to this future.
Thanks for your support 🙏
Exactly that is my point!
And yes, I was not so much aware of the title - it was my 3rd article overall here.
I was never expecting to write an article which is running to 15.000 views, 7600+ unique visitors, 65 comments (without own comments), and straight climbing in the Top section into top-20 within 24h 🤯🫣🤣
I which my typescript open source framework (which doesn't go in direction of express & co) purista.dev would get half of this attention 🥹
I'm not sure why you think express doesn't support async/await. It's a JavaScript feature, express is a JavaScript framework, thus it supports async/await... Or do you mean something else?
When people post benchmark results for "express" what's usually the bottleneck is the json stringify call. Other framework use trickery to have faster serialization, which makes them faster. You can do the same thing in express and it would be just as fast. dev.to/samchon/i-made-express-fast...
To be more precise - express doesn’t support writing of asynchrony handlers.
You need to Jump between different styles or you need to stay on callback style.
With the rise of Deno and especially Bun, you will need to think about runtime agnostic.
It doesn’t matter if you deploy a docker container with bun, node or deno to Kubernetes. But the overall performance and Ressource consumption differs quite a lot here. And this is actual money in cloud environments.
This is why I love Hono. It’s future ready here and provides very similar patterns, async-handlers and so on.
Express apps will also work, but don’t benefit from new things here.
And your are right totally right with your last sentence!
But the point is, that nobody is integrating this into a new version of Express, because the development stands still.
And that’s my point overall.
Other frameworks are growing & improving. Express is not moving forward.
Express doesn't have an opinion about which JSON serializer you use and I doubt they will change that. I still don't really understand what you're getting at with asynchrony handlers and you mention deno and bun? Afaik Express works fine in deno and bun.
The thing with the async handlers is, that you simply can get a clean & consistent code style, which is very important for building understandable, clean software and maintaining software.
Especially when you work with multiple developers/teams.
And this is simply money, which someone has to pay here, only because of this laziness "I use the thing which I use since centuries".
And you pointed it out. There will no bigger change in express to improve something - like JSON serialization or other things.
And that's my point. Why to stay at express over and over again, to build something new for future usage, while express itself is simply not moving?
Yes, Express works, but it does not use the benefits of Bun or Deno in the way it could.
Both outperform node as platform in many cases.
From my personal view - Deno will never make it in a way Node has done.
But Bun will become a real player in future because it doesn't break with the whole eco-system and can be a drop-in-replacement.
It is somehow very scary, if I look into the comments and the mindset behind the comments.
How to make progress, move things forward and improve something?
Yes I agree with that. Eventually (soon) Node will have to evolve to stay relevant. I'm not so sure that they won't evolve though. Hono looks very interesting, syntactically its almost an exact copy of Express which could really help it to become the next big thing. The middleware pattern is still very popular. Unlike express though they are a little bit more opinionated with things like cors, compress and json middleware already included in the package. Imho that's a bad idea because those technologies might also evolve. This is one of the reasons why express is still so popular. Because of the middleware architecture and being unopinionated about which tools you use for json serialization etc, it can make use of any advances in those technologies.
You don't want to be standing in a desert when you need water. Everyone knows about alternatives of express.js tho they prefer to use it instead of something else.
Everyone has a demand to fulfill. And when building something that you want to work for the next 6-8 years atleast, you want it to be supported well.
Totally agree with your last sentence.
But in fact, something like Fastify, is for sure well-supported, has a lot of ACTIVE maintainers & supporters & community and is moving & pushing forward as you can see here platformatic.dev
And if you look at hono.dev, as an example, it might be new and might be not bulletproof as express.
But it takes a lot of advantages of newer node version, where you simply do not need additional plugins for some stuff, because they use plain node functionality like fetch streams.
Or something like IBM's Loopback can't be recommended & used in production?
My point is not "against express" - my point is against standing still and staying in that "express"-loop.
If we follow the arguments in many comments here:
We don't use alternatives because they are not so widely used in production by others and haven't become mainstream, write articles about alternatives or extend them with plugins/modules and so on...
...then, nobody does something, anybody is expecting that someone else is doing it, and anybody only wants to be on the safe side, waits to only consume some ready-made mainstream thing which must also be free without any costs.
What the point to have a mindset like:
Ohh a bug - someone (else) needs to fix it asap for me for free
Ohh a missing functionality - someone (else) needs to build it for me for free
Ohh it is not used in production - someone (else) needs to try it and make this mainstream
Ohh not so much documentation - someone (else) needs to write it, while I better repeat to write something about express for to be the 45Mio+1 one
We are developers!
We need to use stuff.
We need to try out a new thing - If something doesn't work, we simply fix it and get the learnings from it.
If there is something we need - we build it!
If something does not fit, we replace it with some BETTER solution.
And the argument, that big companies do not something before it is mainstream is some kind of invalid.
I was more than one project of big companies where they invested millions, only to try out new stuff and new ways - exactly to come out of such loops.
And they needed to invest millions because of that wrong mindset.
And if you work at a company, which has this "only mainstream" mindset - well, you are part of your company in the development department, right?
Who is deciding such stuff? Some CEO or you and your colleges?
I understand your point.
koa isn't dead at all, the repo is actually pretty active and they had a recent publish!
have you seen the commits?
bumping the version in package.json and changing the history markdown file because of the version bump and one fix in an alpha version - that's it.
20 open PR's - the oldest from 2017 and the youngest from 2022 + the github dep-bot-pr 2 Weeks ago.
Sorry, but this is not pretty active for me.
And that's what I mean here:
If more people wrote articles about koa instead of express, the community and contribution would become much more better.
It's 😭 to see that, because koa is definitely the better option.
More modern approach/style without breaking the general pattern, and you will reduce the maintenance pain in the future if you use it.
I wish koa would be much more mainstream than Express.
koa is still very solid and actually has an active community
otherwise just use fastify, i agree on what you say about express tho
Think the main issue back in the days was, to not simply deprecate express and put it in some kind of LTS mode and push koa as “new express” forward.
Or the other way around - migrate koa to express version 5
I agree and would suggest fastify and here’s why:
codigos.notion.site/Plugin-Based-A...
codigos.notion.site/Assessing-Proj...
codigos.notion.site/Fastify-vs-Exp...
codigos.notion.site/Middleware-vs-...
codigos.notion.site/Initialization...
I like to mention this new cool thing:
platformatic.dev/
Absolutely love it! I had the pleasure to work with Luca Maraschi on an idea similar to that (much simpler tho) once upon a time, which is one of the reasons why I love fastify so much!
I think the real deal for this post, is "Alternatives to express.js"
Everyone is not obligated to use express.js but "always" are a good things on any framework :D
There is only one reason which keeps us staying with Express is because of Mongoose.
For Hono: No info about it. Mongo Realm library can be run in Cloudflare Worker. That's all.
For Fastify: There are 2 libraries that support Mongoose but the DX is not good and not battle-tested.
Even though the code base is really small, I can change all the Mongoose code to the MongoDB driver in one day. But doing this doesn't bring any joy to me.
I'm using Fastify and love it than Express. But i have my own reason, with deep understand about both of them. If you persuade other people that all of above frameworks are better than Express, please prove by evidences, not your opinions.
For example, fast JSON deserialization of Fastify, plugin style ... and why they are awesome ?
After all, I only can see you are a guy want to do the same things cooler and follow the trend. C++ and C is still alive, despite of number of programming languages (include Rust) growing.
It's not a trend @phucvinh57 or about to do something cooler.
It is about building new stuff on legacy code and pushing newcomers into this direction.
Your comparison between C++ and C is not valid.
In this case, it is more about using C++ 17 from 2010 for new projects in 2023 when C++23 is available.
And, it's not an opinion, that Express.js does not and will not support async-await soon. It's simply a fact which I do not need to prove - it's proven since years.
It's also not my task to provide benchmarks here.
I want to trigger people to think about it, before they write the next 1Mio+1 Express.js beginners guide.
Invest the time to decide, if it is worth to invest the time for writing about something outdated.
I dont know man... ive been doing this for 30 years, I'm constantly evolving with the frameworks... every app is new framework... we select the framework based on needs and application. "What's newest" is an imprecise way of saying "what's future proof", that's what matters in reality.
Why do you think it is about “the newest”?
See the other comment I made. Most of the mentioned frameworks are also matured.
Do you think express is future proof with its code base, low contribution, call-back-style, promised version 5 since many years without any progress?
I dont really care about s.th new, just evaluate everything by cost and benefit.
An Express application has worked well for many years with several thousand users, can handle high workload, not only because of good framework, but also strong skills of developer like query optimizations, caching, queue, object reusing ... There is no need to convert to use new framework, just because your business has only limited amount of users, and doesn't need optimizing anymore.
Again: It is not about convert exciting code - it's about starting new stuff and providing beginners guides.
And if you focus on cost and benefit, than you should definitly not use Express.js 😜
Well the reason there are a lot of tutorials for express is because there are a lot of users of express. It's also pretty flexible. When you are trying to teach beginners the ropes you don't want to bog them down with excess tool choice. You want to pick one that is going to suit most general use cases and teach that.
The same reason there are millions of beginner java tutorials. It may not be the best thing for many tasks but you can cover concepts with it and it works on many systems.
There is also a ton of additional educational resources for express so when beginners run into a snag they have a good chance of being able solve their problem. You can say you want progress all you like but it won't happen if you teach beginners new stuff that they can't make work for their first project. Beginners become novices then average then expert. If on that journey, their accumulated knowledge demands a new tool it's at that point they should and likely will select one.
If you think otherwise then why don't YOU make these beginner tutorials that YOU claim need to exist to create progress instead of writing an article complaining that they don't exist? All these protester types like you screaming "progress" ad nauseum ironically makes no progress.
I would like to give your comment more than one ❤️, because you are one of only a few, which got the intention of this article right and providing some related comment.
You don't know how nice it is for me to read your comment!
It is a valid point, that beginners should start simple and so on.
And my post is not against this.
As you said - there are thousands of tons of articles available for this.
I simply don't see the need to write the same articles over and over again, when a Google search returns 45Mio results on this.
Also, you can start with some other, similar stack - which, very often, - adapts express patterns. This helps newcomers and might be interesting for pros and experienced devs too.
And about your last paragraph:
I don't make tutorials, but I try to push things forward and try to share knowledge and stuff as good as I personally can.
But in fact, these articles and stuff don't make 100 views over weeks and month, while this dump-a*-s* is going into dev.to Weekly-Top-10 with +27.000 views with less than 36h.
You might want to take a look at my open source project at purista.dev or my recent article at medium
medium.com/@sebastianwessel_de/the...
or this one here:
dev.to/sebastian_wessel/awesome-pr...
I personally use fastify for a little while and i am loving it. Maybe on weekend i can write some blogs on it. Fastify is just awesome 😎.
Hono and Elysia looks so promising to.
I tried nest but i don't think its for Pro Javascript/Typescript developers it's more oriented towards OOP like Java, C# guys.
Why people are not switching to express to other frameworks ?
If it isn't broke don't fix it.
This would be lovely!
Mate. Come on. Async and await are language features, nothing to do with express. Stop trying to tell us what to do.
Right it's a language feature.
And can you directly use it in your handlers on express?
Or do you need to mix styles, which is not ideal for code consistentcy and so on?
With a very high percentage, handlers do asynchronous stuff - writing/reading to database, calling third party apis...
Yes, you can use them in express... Maybe you're thinking of the lack of good async error handling? That's a good point but fyi, express 5 solves that problem, has very few breaking changes, and has been considered stable and production ready for a long time. Not sure why it hasn't been officially released yet
That’s the point! You’re right.
It’s not about express is sh***. It’s about not making any progress on express.
I really do not understand why the maybe most used node package at all simply stand still since years.
I could understand if it is a slow progress to not break things as huge amount of software is based on it - but no progress?
Seems a bit like the “never touch this monster it will break everything”
If it ain't broken don't fix it ...
Yeah. Here is an example. Seems fine to me.
You are barking on the wrong tree.
There is vicious cycle where companies use something as they can find devs which know it. And devs learning something because they can find projects with it.
There are so many projects which could be done with Next.js instead of react + express and be much simpler.
Same reason you would use learn Django+drf and React, instead of just using one of the many headless cms + react, or next or nuxt or ...
I can argue you can cover most express cases with FastAPI too...
Take it with management or the CTO, or the 4 year legacy mess you work on.
going to stick with nestjs
With underlaying express or fastify?
Tbh - I’m not so 100% familiar with Nest, because it’s not my preferred way how to code in typescript.
So, my question to you would be:
Can you simply replace express with fastify without touching other (business) code in nest?
Something like simply changing packages or is it more effort?
Do you know this or have experiences here?
nest is built on express but is nicer. Anotations, out of the box support for sequelize. Really fast development imo. I come from Java and I like this a lot
I already know it - if you say you use & like nest you probably come from the Java side 😂.
I always say: if I would like to develop this way, I would not go for node/typescript at all. Than I would go back to Java or Kotlin to get the benefits from this eco-system 😜.
It’s totally fine to stay at nest as abstraction level, because here - in worst case - it’s up to nestJs to replace express without breaking applications and you already have the modern patterns in nest.
This is totally different than doing something on plain express.
This is a naive way to see things that usually entry level software engineers tend to have. Similar to how they tend to optimize and over-engineer code that produces no value. I get it, you're passionate about your code but...
Some people create code, others create businesses.
As a business founder I care more about good long term support, better documentation and using well established frameworks than to always try the new shiny things that are going to be unsupported in one year.
What are "well established frameworks" for you?
Fastify first version 2018-03-06
Restify is older than Fastify - changelog goes back to 2017
Koa first version 0.1.1 / 2013-12-19
Feathers changelog goes back to version 4.0.0 at 2019-04-21
They are all mature, well tested, documented, with communities and so on for many, many years, and they are a way more active in comparison to express.js
And as business founder, you should be really, really be interested in, to have a good code quality, which will have lower maintenance effort in the future.
If you use express.js with callbacks & co you simply will not have.
Do an article on Nest.js I find it awesome, you can opt to choose between express and fastify on the background, if you don't like express
Agree! Might be also cool to have an article which is explaining how much effort it would be, to switch between express and fastify on an existing code base.
I regret spending those five minutes of my life reading this article and engaging with the author's contentious opinions. It seems like Dev.to is the new Medium for all these stupidity.
Thanks for taking or maybe wasting your time.
I'm kind of totally sorry 🙏 about it, because my intention was different.
My intention was to motivate others to write articles, which are not always the same published since years.
But somehow, this was going into a totally different direction end explodes, while there are articles here, with similar headline and more "contra express" totally invisible.
I don't know what was happening here 🫣
Maybe the best of all in terms of features and rear of use is NestJs. Insert the good you get express, but your never need to write in its outdated API..
Thanks for your information. It helped a lot in my study. I will switch to Hono.
My fav NestJS with fastify. Nestjs makes writing tests super easy and very organized. Nestjs also has huge number of plugins
Actually the same applies to the frontend for React.
I think the only small difference is, that itself React is moving forward.
Maybe not so fast as newcomers, but constantly.
There is a pretty cool new "framework" called VanJS, which is a real marvel. The core is only 1,2 kB minified, but it has very mature features including reactive state binding. It does not introduce ton´s of new features but makes the existing standards more accessible. And it integrates seamlessly with existing packages or Webcomponents. At least for small and medium sized applications this would be my favourite.
That’s a frontend lib right?
Here, it is about backend 😜
Sorry, there are so many approaches out there....
No worries - you're welcome!
Actual, an interesting link - might be, you want to write some article about it?
But as I learned - avoid some headline like "stop using express.js" 🤣
There is already a series about VanJS that outlines the basics.
But the bottomline is probably very similar: Stop reinventing the wheel - somebody has to learn all this stuff and will finally see that your wheel does not even turn properly.
Partially agree.
There is a difference between reinventing stuff und improving stuff and creating new stuff.
For learnings reinventing might fit, for consistency the improvement is important and for making progress the last one is important. IMO
For our business we need to have a good balance between these three things.
C-programmers have been creating new stuff all the time without inventing a new language every second day. But today everybody creates it´s own language. If you switch from React to Svelte, you probably start at zero again.
Stop using Express
Use:
It’s because the (dead) thing was added afterwards, but I didn’t want to remove Koa from the list, because it is in fact a real solid thing.
Just use pure Golang for most backend services, need no frameworks)))
😂 sure.
But how to argue that. You see what’s happening here, only because I said “please stop using express” for new projects 😜
And Nest?
See documentation of Nest:
Under the hood, Nest makes use of Express, but also, provides compatibility with a wide range of other libraries, like e.g. Fastify, allowing for easy use of the myriad third-party plugins which are available.
Loopback is the best, no questions about
Valid!
And also provided by the big blue IBM, so nobody should complain “not professional” 😂
Check moost.org/ It's TS native, decorator based framework to build any apps, web apps, APIs and even CLIs with one framework.
Here we go! 👀
I need to spend some time - I didn't know about it.
So, I probably will need to take a look into it.
👍 Thanks for sharing this one!
I heard nestjs grapgql is a great stack
Well, I’m really not a fan of nest for different reasons tbh.
But I think, they wrap Apollo by default, which is more or less “the reference implementation mother”.
So, I expect that this stack should work very good for everybody who enjoys working with Nest.
ah look another clickbaity article
It was not my intention tbh.
I was simply frustrated after scrolling through the article list full of “express.js beginners guides” 🤮
But, yeah - it is a trending thing here.
Didn’t expect to get 7400+ views, 65 comments and so on… within a few hours.
I wish my more relevant & serious articles would get half of this attention!
Yeah here's the problem with this. It doesn't address why people are still using express after all these years. It's not because it's the best. It's because the ecosystem is there. What's the equivalent of multer for Elysia? Does it even have one? What about passport-discord because I just want simple discord auth without having to rewrite an entire library from scratch?
Can you legitimately tell me that all these alternatives have all the features people expect from an http framework? No, you can't. And thinking that these are good alternatives shows a level of blindness that does not befit anyone with opinions on the matter.
First of all, you probably won’t need all things the eco system provides for your project.
Secondly, why should anybody provide something for other frameworks, when everybody arguments like you?
Why do you expect that some others do the work for you, instead of providing something and pushing things forward.
And finally see: elysiajs.com/patterns/file-upload....
You’re welcome 😜
I realise now that the vast majority of replies say the same thing I did so clearly, you need to reevaluate your message.
Kind of too late I guess.
This post will break the 16.000 views very soon 🙈🤯🙄
Again - this was definitely not my intention, but it very, very interesting how people react here ☝️
Some premature assumptions:
async/awaitNot at all!
Read the article correctly.
It's about the fact, that since 13? years the same articles with same content are produced.
I wish there would be more progess on express in some way - but it isn't.
I didn't say the mentioned ones are using all state-of-the-art features.
I simply said, that they are good alternatives which are enveloping much more than express.
Do you want progress on the articles or progress on express? Also, solving call back hell requires javascript concepts that should not be in beginner tutorials.
Both tbh! 😂
One solves the other.
If there would be more progress on express, the articles would become more valid or usefully.
If there is no progress on express, then the articles are - from my personal point of view - wasted time as there are thousands of them out there.
I don’t know if async-await or callback should be preferred for beginners. Both has valid arguments imo.
But to start new projects, which are more than “Hello world”, with callbacks isn’t something I would seen as way to go.
Well, callbacks can be handled by well architected express projects. But you will seldom find such articles online, because architecture is not a beginners plate of food. I have some really good maintainable express code, without callback hell.
Let's forget about beginner articles for now since TBH are mostly for marketing and other stuff that really doesn't matter to express. The title of this article really caught my eye, and I am still waiting for you to say why I should stop using express. I am assuming by progress you mean features, so what do you propose?
First of all - the things happened because of this title were totally out of my intention - as I said it was my third article.
So, I’m kind of sorry to trigger the wrong expectation. This - how is it called - clickbait? - was definitely not my intention!
It’s not so much about features itself. Ist more about growing, improving and so on.
If you read the comments here - most people are simply lazy, using stuff which was made by others without money and expecting all the time that someone else is doing smothering for them and their individual needs.
But this is not how it works, when you like to improve and make progress in any direction!
You should simply not use express, because then you use something else.
You make new experiences, get new knowledge and you push other projects forward. And if you’re really cool, then you give feedback to the contributors which are providing cool stuff just for free for you.
And if you’re really cool, than you contribute things, or write some review or similar.
This is how things can improve and new ideas come to life!
If you simply stay on express and lay on the existing stuff, you simply stand still.
Not great stuff man... you call express legacy, while suggesting we should try Koa which is dead.
Yes front-end has come a long way while backend has stagnated, but that is simply because data + graphics is always going to be orders of magnitude more complicated than data and assets front and backend.
I think your missing the most important factor when using a framework, community acceptance. Express is fine... just the default for node backends... but if one really cares about the backend framework, one shouldn't be using node or js or even ts to begin with, one should be using a true backend framework like spring boot or kotlin, c++... true strong typing not simulation in dev time... real classes not transpiled prototypes... actual compiled and optimized code for massive user bases and server costs. Nodes fine, but not cost effective.
Regardless, remember that these frameworks only matter to the developer not the computer, and the Abstractions can hurt the end result as much as help it, depending if designed and used right or not. In the end, all frameworks in a given domain can solve all problems, the goods just speed it up and make it superfast to reverse engineer and modify.
Node not cost effective? Care to actually share your sources on that one? Don't be just another mediocre backend dev, who feels threatened by JavaScript.
Strong typing on the backend doesn't do shit, when the connection between FE and BE is JSON without validation. Even if you have schema validation, you will find only with e2e tests if FE and BE are incompatible...
Unless you find a way to share schemas between them. TS and tRPC make this a whole lot easier.
Also you probably know this, but node is libuv under the hood, and the database drivers are also low level. So it's better optimized than 99 percent of devs can do. If you use it for IO heavy low computational cases, it will do a whole lot better than Java or python.
Node is actually very good for what is designed to do, or rather what libuv does. Basically you need a lot less threads to serve same amount of requests that python or Java.
Which makes express not having async error handling built in pretty ironic, since node s biggest strength is async io
You are not wrong with some of your points.
But to be clear:
I didn’t recommend to use koa. I listed it as younger alternative to express.
Both are from same developers, share many stuff and are both kind of living-death.
I only said, that koa is more modern.
It’s not at least this annoying “we use express because it works” thing, why koa never got some real traction.
About node vs Java vs C vs Rust vs Wasm vs Kotlin…
This is something where I say - it depends on your use case. There is no general “correct way” - there is only a language which fits for you, the project and the actual thing.
But as I said in other comments. Express pro-con is not like node vs C++ or similar.
It’s like using Java 1.0 in 2023, only because it’s proven that this is working.
This post has passed the test of time. By reading the comments I see where developers hearts are. Defending what they love and trashing what they don't know
There is too many things and stuff in this industry, too many tools, too many frameworks, too many databases. Im kinda glad that at least for the backed there's obvious choice to go to, makes things much simpler.
Is there a better backend framework for my problem that Im trying to solve ? Yeah probably
Can Express still solve it ? Yeah
Do I care then ? No
So thanks for making junior developers who are trying to get into the industry more frustrated with what technologies they should learn.
Now insert comment from Sebastian Wessel under this line, cause my god he likes to argue every comment 😂😂
⤵️
It's not about argue against or for something in first place, when I answer comments.
It's kind of being polite.
If someone takes the time, to read something from me, and has some opinion or comment posted, then it is only fair when I take my time to respond.
This is something where, I think, grown people should simply do respectfully. Don't you agree with that?
Also for your comment, which is more than 2 words - I simply say:
I do not agree with that - totally not.
But thank you for taking your time and to share your thoughts.
"leave battle tested armour and use this new ones in your Battles!"
reasons for this, i won't explain or elloborate, the only explanation i have is I am sick of your old armours, so do as I say
No!, Thank you
🤔 to pick up your example:
Use the stone, because it’s proven that it works if you hit the head.
Do not try out the 🔫 because it was never used in a battle before.
For the stone we have 45mio documents explaining how to use it.
For the 🔫, we only have the manual.
👍🏼 you made it!
To prove express stone and the framework you suggest as modern marvel, you need provide supporting evidence, we are ready to accept your conclusion, but so far you have not given enough explainations of how express is stone, and others are any better.
Might be the better option, if you try them out by yourself and do your own experiences, and maybe give feedback and let the community participate on your experiences, instead of expecting that I or someone else is doing it for you?
The community of open source developers already provides you the bunch of free tools. Move yourself a bit!
I’m not a priest who needs to do something to change your mindset or to convince you about something.
I’m only a that guy, who is telling you, to not be lazy, and to have a look around.
You need to provide the evidence, that there is nothing better on the planet than express. And this, you should do regularly!
Not for me or somebody else - simply for your own growing and expertise.
For me personally it doesn’t matter and I really don’t care, if you do monkey business with express for the rest of your lifetime tbh.
pretty crummy article in my opinion. the only real criticism of express provided is that async/await isn't tightly integrated into the API, which makes perfect sense when you realize that Express 4 was written at a time when async/await was not universally supported. and now that Express 5 is out this is a non-issue.
the main problem with the article is that it doesn't actually provide much (or really, any) meaningful info that distinguishes the frameworks you have chosen to promote. lots of hype, but no concrete discussion of how they stack up. it reeks of the naive "rewrite-it-in-" approach that has led so many projects to their doom.
speaking of that, i think it all ties back to the fact that your definition of progress based on your comments seems to be more frameworks (willfully disregarding the fact that all those frameworks are just reskins of the same few patterns). what exactly is gained by creating a dozen more frameworks? nothing!! frameworks are a means to an end. why don't you focus your efforts on actually building applications instead of reinventing the wheel?
Pls read the first 2 sentence of this article!
That’s the intention and that’s the thing the article is about.
And regarding your last sentence:
Have a look at purista.dev
Take some time to understand what it can provide - I can also any question here and feedback and ideas are welcome.
There you will see where my effort is going in.
Pffff feathers and hono are for smol boiis. You use substitutes because you are too afraid to use proper framework such as expressjs
For sure not - I used it a long time.
But the glory times are over here.
If you want to use it - feel free.
See you in call-back-hell, when you need to maintain this 🔥👺👹
I never used expressjs. I am a Java developer. I just checked the framework it seems to be actively developed. So by no means using express = staying in 2010. If you think it is bad, why don't you send a mail to the authors and request them to stop developing it anymore or better tell them how to improve it. As someone who worked frequently with enterprise applications frameworks which has premium support for 10+ years this article doesn't make any sense. You are having a wrong idea on frameworks.
And these frameworks with premium support over 10+ years you mentioned.
Do they catch up in some functionality, do they provide small features and enhancements.
Or do they only fix security issues?
And what is happening after these 10+years?
And would you start new projects with these version?
Those frameworks always evolve. I always start with latest versions sometimes even non LTS ones. The old ones get only security fix. The frameworks still get new functionality and stay competitive with the likes of younger frameworks from younger languages like golang.
See - this is the difference to express.
Here you get security fixes if needed - but that’s it.
And that’s my point the whole time here.
Why to start new projects with it, when you can’t expect some evolvement or progress and there are mature, stable, documented alternatives out there?
I would consider it unwise to tell new developers not to use one of the best, well-supported, and easiest to use Node.js modules in existence. Don't let your opinion get in the way of trying to "help" new developers. If you don't like it, then you don't have to use it. Don't lead new devs in the wrong direction by discouraging popular, well-documented modules.
Ok, but if I take your arguments and use them for the opposite:
Why to think it is ok or helps, to tell new, unexperienced developers to use a framework which is using not recommended way of writing code.
You know all these call-back-hell-bashing?
It is wise, to start learning the things in way you should do it, instead of learning the “old way” how we did it in the past - right?
Teach new ones the clean, readable & maintable code style and not the call-back-style you’re treated to use, only because of your framework choice!
It's not always about being cool. Express is proven tech. It works. And for the lack of native async support are easy solutions. There's a reason why express 5 doesn't ship, and yet express is still remains the industry default.
So, you mean, it’s better if we never change or improve here and we still start new stuff with express 4.x until end of days? Waiting for someone else to build and release express 5 or whatever for use, while we are browsing cat pics on Twitter?
I only pleased in this article, to not write the next beginners guide for express because there are already 45mio out there and nothing has changed since many years here and reached out for support other stuff.
People arguing, that they do not move from express, because others don’t have so much documentation, articles and this kind of eco system and it is proven to work since years.
Ok valid argument for production critical stuff - maybe.
But also arguing, that they write the next tutorial about express because there is a lot of other material around for this, with the knowledge, that this is is already written in thousands of articles, books and so on?
It’s waste of time.
Simply not using something different, to try it out, and prove that it works as expected - or maybe better - because of the fear, that there might be a bug or a problem?
And the expectation in case, something is not working, someone else needs to fix it?
And someone is meaning everybody except your own - it’s meaning the guys, which are building the stuff for free, while the other ones are laying in the sun - right?
Sorry, but this is not development in my eyes.
It’s standing still, while only consuming stuff from others like vampires with the expectation that someone else should do the job, without money, while they receiving their payment regularly for using the stuff which they get for free.
So here is my question:
What is the expectation here? That somehow, magically over night something new appears and that are magically 45Mio articles and documents for this appear and all others have proved in production, for years, that this magically appeared thing is working?
If no one tries new things out and no one is writing new stuff and no one is fixing and improving something, then there will be nothing new! And bathing will become ever mainstream.
This article is just clickbait. There is not even a reason on why to stop using Express.js. It even looks like the creator has zero experience on the real world business applications. It is just trying to force new users to not learn a legacy/stable library which has support for everything you need to create micro services. It even mentions libraries that are written over the same Express.js... When I read Koa in the article, I knew this is just a joke of opinion. HOW would it come to a developers mind to suggest a beginner to implement a solution in a DEAD project with no support? Even trying to make new developers to use new and barely documented or with a really small community technologies.
Also for you - pls read the first two sentence of this article and don’t feel triggered only by the headline.
It’s about these 45mio articles every day “beginners guide express”!
Well, the headline was maybe somehow to much “catchy”. It was not intended this way…
Unfortunately, I didn't really learn much here or see any new or exciting Frameworks.
Might as well have suggested http/https package, pretty similar to Express. Perhaps as an expert, you can create this new framework.
Simply because this was not my intention.
My intention was to trigger authors of these “express beginners guides” to write about the things you expected to read here. Other frameworks, different technics and solutions.
So I’m really sorry, because this is also the thing I like to read more often. And this is the reason why I write this article.
Seems that this was going in the wrong direction 😂
But maybe you like to have a look into my open-source-project.
It’s a framework which is focusing on the things happening after the endpoint.
Feel free to check out purista.dev and to ping me in any case for questions and feedback.
Didn't realize Koa was dead... Really liked it a lot.
Me too!
Not official dead - but more or less same as express, while koa didn’t get the same attention as express. So it might be disappear more quickly than express.
Now the question is what advantages these frameworks have over express
👍
Stop writing "Stop using x" articles. You look like a silly child.
You didn’t get the main intention as well - right?
What’s are the first sentences of this this article? Read the first two and not only the headline 😂
Stop using express and use feather. Why? "Because it's Pretty cool concept and simple to use." I think you were joking when you wrote this article.
No, I didn’t.
My intention was a totally different!
Read the first 2 sentences.
It was mainly about writing always same articles and pleasing authors to write about something different. For this, I suggested express alternatives.
Read the headline as “stop writing about express.js” 😜
Man this reeks of junior engineer puffing up their social media presence with "hit takes" for recruiters.
It's not about the framework, it's the software architecture that matters. Unless you're creating the next Facebook, it's doesn't matter that much which framework you choose.
Isn't choosing a framework not part of software architecture?
There is a big difference if you choose Nest or if you choose Fastify or plain Express from the software architecture point of view.
As a repeatedly say:
It's not all about performance here.
And in fact, if you're not the next Facebook, you need to be more curious about question like how to maintain things in future, how to build somthing clean with low resources and which dependencies you have.
I am still using express.js because there is an easy library to add socket.io capabilities on top of it.
Is there any other library you mentioned that offers such functionality?
I mean socket.io is a rock solid, matured lib, which is working on plain node http sockets.
So any framework should work here and most of them provide plugins/modules/documentation to provide some helper.
See:
socket.io/docs/v4/server-api/
And
socket.io/docs/v4/server-initializ...
L take