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, and the first application you need to implement is an Epress.js application.
But why?
There are so many real cool frameworks out there, which might do a much better job than Express.js, with support for state-of-the-art patterns like async-await and great communities.
Express.js 5 with async-await is announced since years, and the widely used version 4 is legacy code.
Even if version 5 becomes available in some years or centuries, you probably will need to migrate your code base.
Because of this, I will share some cool frameworks with you. Maybe you like to try them out and write your next article about something, which was not written a hundred times before.
Feathers
Feathers is some kind of unicorn and is focusing on build REST-APIs and real-time applications.
Pretty cool concept and simple to use.
Hono
My lovely Hono!
If you're looking for some lightweight and fast way to build HTTP server, you must definitely try out Hono.
If you know Express.js or similar, you will exactly know how to use Hono.
It also supports different runtimes like Bun and Deno and allows you to write software, which benefits from the runtime benefits, without the need to re-write things.
Elysia
Build to get the benefits of Bun runtime, it is a real promising framework.
Fastify, Restify, Hapi
If it comes to REST-API, you should definitly look into the "Three-Kings".
They are made for building REST-APIs, and they are also some kind of "way-to-go" with all these features, modules, plugins and communities.
Koa (dead)
Koa was a more modern version of Express.js developed by the team of Express.js developers. It provides support for async-await.
But it seems to be no longer maintained by someone
And much, much more is out there!
So please, if you write beginners tutorials, don't stick to legacy Express.js.
If you come around some cool framework - please let me and the world know about it!
The Frontend guys are having so much progress with React, Angular, Vue, Svelte & Co over the last years, and we backend guys are sticking still in 2010?
Top comments (173)
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
Some comments may only be visible to logged-in visitors. Sign in to view all comments.