DEV Community

Sebastian Wessel
Sebastian Wessel

Posted on

Stop using express.js

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.

Feathers.js

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.

Hono

Elysia

Build to get the benefits of Bun runtime, it is a real promising framework.

Elysia

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.

Restify & Fastify
Hapi

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

Koa

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)

The discussion has been locked. New comments can't be added.
Please see my last comment here: https://dev.to/sebastian_wessel/comment/274dk
Collapse
 
dermorzi profile image
DerMorzi • Edited

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

@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?

Collapse
 
marcosmarp profile image
Marcos

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?

 
sebastian_wessel profile image
Sebastian Wessel • Edited

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.

 
gunslingor profile image
gunslingor

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.

 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
sgarciadev profile image
Sergei Garcia

The intention of this post is not to be polite, soft or smooth or even present the perfect solution

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.

 
sebastian_wessel profile image
Sebastian Wessel

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...

 
sgarciadev profile image
Sergei Garcia

Who was talking about migration? Not me! {...} I only said, that there should be more article about other stuff, showed some examples which come into my mind.

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.

 
sebastian_wessel profile image
Sebastian Wessel

See the other comment - you're welcome! 😘

Collapse
 
maixuanhan profile image
Han Mai

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 :)

 
sebastian_wessel profile image
Sebastian Wessel

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?

Collapse
 
jamesdoe profile image
JamesDoe

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.

 
sebastian_wessel profile image
Sebastian Wessel

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”

 
jamesdoe profile image
JamesDoe • Edited

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?

 
sebastian_wessel profile image
Sebastian Wessel

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 đŸ«Ł.

Collapse
 
nima_lalaj profile image
yasin cengiz

Yeah, I agree.

Collapse
 
ravavyr profile image
Ravavyr

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
thirdender profile image
thirdender

Because new cars and appliances break down all the time. Old and reliable is a premium.

 
sebastian_wessel profile image
Sebastian Wessel

@thirdender Oh dear 🙈. Yeah, and if you take a horse, you can eat in worst case. 😂

Collapse
 
sgarciadev profile image
Sergei Garcia

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.

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.

 
sebastian_wessel profile image
Sebastian Wessel

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.

 
sgarciadev profile image
Sergei Garcia

But, let me simply ask who is bringing this mindset to companies?

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.

 
ravavyr profile image
Ravavyr

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.

 
sebastian_wessel profile image
Sebastian Wessel • Edited

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:

  • 38.128 views
  • 73 reactions
  • 172 comments

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel • Edited

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.

Collapse
 
gunslingor profile image
gunslingor

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!!!!

 
sebastian_wessel profile image
Sebastian Wessel

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?

 
gunslingor profile image
gunslingor

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.

 
gunslingor profile image
gunslingor

Javascript is not legacy, it's the backbone of every single framework we are discussing.

Collapse
 
jamesvanderpump profile image
James Vanderpump • Edited

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
jamesvanderpump profile image
James Vanderpump

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.

 
sebastian_wessel profile image
Sebastian Wessel

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 😂

Collapse
 
richardsefton profile image
RichardSefton

Who do I send the invoice to refund the time it took me to read this?

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

You’re welcome!

Collapse
 
sgarciadev profile image
Sergei Garcia

You could probably find the author of this article on the definition of a Hype Driven Developer on a dictionary lol.

Collapse
 
spock123 profile image
Lars Rye Jeppesen

Just like "React" articles

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

@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

Collapse
 
spock123 profile image
Lars Rye Jeppesen

I think people are comfortable in what they know and know well, I guess.

Collapse
 
sgarciadev profile image
Sergei Garcia

I do not understand why people invest time over and over again on same things, while there is so much interesting stuff going on

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.

 
sebastian_wessel profile image
Sebastian Wessel

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 😜

 
sgarciadev profile image
Sergei Garcia

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.

Smart developers think of building software that needs to be maintained and handled by someone in future.

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.

 
sebastian_wessel profile image
Sebastian Wessel

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 😘

Collapse
 
vody profile image
Vlad Leonov

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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 đŸ„č

Collapse
 
old_mate_jim profile image
Old Mate Jim

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
brense profile image
Rense Bakker

Typescript? 😛 Why do you think compiled languages are better?

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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 😂

 
brense profile image
Rense Bakker

Agreed! It's not the ship, it's the captain! Not the tools, but how you use them.

Collapse
 
frulow profile image
Frulow

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel • Edited

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?

Collapse
 
frulow profile image
Frulow • Edited

I understand your point.

Collapse
 
f34th3r profile image
Jafet

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

Collapse
 
maumercado profile image
Mauricio Mercado
Collapse
 
sebastian_wessel profile image
Sebastian Wessel

I like to mention this new cool thing:

platformatic.dev/

Collapse
 
maumercado profile image
Mauricio Mercado • Edited

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!

Collapse
 
brense profile image
Rense Bakker

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...

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
brense profile image
Rense Bakker

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.

 
sebastian_wessel profile image
Sebastian Wessel

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?

 
brense profile image
Rense Bakker

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.

Collapse
 
emilianomaccaferri profile image
Emiliano Maccaferri

koa isn't dead at all, the repo is actually pretty active and they had a recent publish!

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
emilianomaccaferri profile image
Emiliano Maccaferri

koa is still very solid and actually has an active community

otherwise just use fastify, i agree on what you say about express tho

 
sebastian_wessel profile image
Sebastian Wessel

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

Collapse
 
ragnarok001 profile image
Colter

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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...

Collapse
 
phucvinh57 profile image
Nguyễn PhĂșc Vinh

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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.

Collapse
 
gunslingor profile image
gunslingor

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.

 
sebastian_wessel profile image
Sebastian Wessel

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?

Collapse
 
phucvinh57 profile image
Nguyễn PhĂșc Vinh

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.

Collapse
 
sebastian_wessel profile image
Sebastian Wessel

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 😜

Collapse
 
thinhvu profile image
Thinh Vu • Edited

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.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.