Mojo.js is a port of Perl's Mojolicious to TypeScript(mojojs.org)
mojojs.org
Mojo.js is a port of Perl's Mojolicious to TypeScript
https://mojojs.org/
24 comments
Hi, Mojolicious founder here. The "Perl grade" is meant to be a cheeky callback to Perl's famous backwards compatibility (you can run pretty much any Perl code written in the past 30 years with the latest Perl unchanged...yada yada). Perhaps it is a bit too subtle.
Back when i started with Node, one of the first problems i constantly ran into was some NPM module deep down in my node_modules folder breaking its API in a minor version bump and causing hours of cleanup work. So pretty early on avoiding this issue became a priority for the mojo.js port, and i see it as one of the main niches for us to corner. You want to write a fast JS/TS web service that still works in 10 years? Use mojo.js!
Maybe you've got a suggestion for how to better communicate this idea?
Back when i started with Node, one of the first problems i constantly ran into was some NPM module deep down in my node_modules folder breaking its API in a minor version bump and causing hours of cleanup work. So pretty early on avoiding this issue became a priority for the mojo.js port, and i see it as one of the main niches for us to corner. You want to write a fast JS/TS web service that still works in 10 years? Use mojo.js!
Maybe you've got a suggestion for how to better communicate this idea?
You seem to have followed the development, but anyway in this blog entry they explain the motivation and the plans for the TS version:
https://mojojs.org/news/mojo.js-1-released
Among other things I find this quite interesting:
"Software supply chain attacks around NPM are a hot topic right now. And it can be quite problematic to audit your whole dependency tree. Thankfully, while the Perl version has no dependencies at all, in JavaScript we only have 23 trusted third party dependencies. And we are prepared to replace every single one of them if necessary, with a port of the battle-tested Perl implementation."
https://mojojs.org/news/mojo.js-1-released
Among other things I find this quite interesting:
"Software supply chain attacks around NPM are a hot topic right now. And it can be quite problematic to audit your whole dependency tree. Thankfully, while the Perl version has no dependencies at all, in JavaScript we only have 23 trusted third party dependencies. And we are prepared to replace every single one of them if necessary, with a port of the battle-tested Perl implementation."
I’ve been slowly working on a 0 dependency framework in Bun for similar reasons. The size of the average package-lock.json is absurd and nerve wracking.
I know there is still a tendency to choose Express as a de-facto standard, but I have been using Adonisjs more thesedays. For me it feels more familiar since it follows much of the Laravel principles and patterns, but I also like it because it does come with a lot of boilerplate stuff filled out, but not enough to overwhelm you.
[0] https://adonisjs.com
[0] https://adonisjs.com
It looks interesting. Some observations/metrics of the repo I use for a preliminary judgment of a project:
- comparatively large community
- only a handful of open issues while approximately a thousand issues have been closed
- on the downside it seems driven (and developed) by a single person (same as with Nest.js) which imposes a comparatively high risk in my opinion
- includes a lot of "first party packages" for things that already exist in the ecosystem, such as their own Lucid ORM. Depending on your point of view might be a good (less dependency on NPM ecosystem) or bad (NIH)
- comparatively large community
- only a handful of open issues while approximately a thousand issues have been closed
- on the downside it seems driven (and developed) by a single person (same as with Nest.js) which imposes a comparatively high risk in my opinion
- includes a lot of "first party packages" for things that already exist in the ecosystem, such as their own Lucid ORM. Depending on your point of view might be a good (less dependency on NPM ecosystem) or bad (NIH)
Interesting pivot! I've never seen a framework for one language pivot into another like this. I like this approach, too often good frameworks just die with the language.
I hope its an opportunity for the Mojolicious team to do things they just couldn't do their Perl framework due to legacy constraints etc and they get to take on fresh new ideas and see them through! I've heard good things on the peripherals for years about Mojolicious
I hope its an opportunity for the Mojolicious team to do things they just couldn't do their Perl framework due to legacy constraints etc and they get to take on fresh new ideas and see them through! I've heard good things on the peripherals for years about Mojolicious
Being able to use features like async/await consistently has definitely opened many doors for the port and made a lot of APIs more elegant. It's also quite fun trying to make more parts of the framework compatible with WHATWG APIs.
not the same but torch -> pytorch comes to mind
The first thing I consider when looking at Express-alternatives is if the API is fully compatible because almost every other 3rd party library/package (e.g. sentry) expects the Express object. This doesn't look like the case as I have no idea what the mojo context object is.
On a side note, I'm surprised to see frameworks trying to use benchmarks against Express as a key feature. Framework overhead is insignificant when requests delays are mostly due to the database/network.
On a side note, I'm surprised to see frameworks trying to use benchmarks against Express as a key feature. Framework overhead is insignificant when requests delays are mostly due to the database/network.
> Framework overhead is insignificant when requests delays are mostly due to the database/network
It really depends. When every part of your app is concerned with performance, it tends to hum along. When every part of your app tends to think, “the bottleneck is the database, so this doesn’t matter”, you get modern systems.
It really depends. When every part of your app is concerned with performance, it tends to hum along. When every part of your app tends to think, “the bottleneck is the database, so this doesn’t matter”, you get modern systems.
In the case of Express vs alternatives benchmarks, you're looking at differences in the sub 1ms range as these benchmarks simply test how much "hello world" you can return per second
Express middleware support is on the planned feature list for 2.0 and beyond. Could also be implemented as a 3rd party plugin using the existing hook API though. https://github.com/mojolicious/mojo.js/issues/66
I'd never heard of mojolicious, and now wishing this had existed 20 years ago! It is quite elegant, but looks like the first release was dropped in 2015.
https://metacpan.org/pod/Mojolicious
https://metacpan.org/pod/Mojolicious
Mojolicious reached 1.0 in 2010.
https://github.com/mojolicious/mojo/blob/main/Changes#L4345
https://github.com/mojolicious/mojo/blob/main/Changes#L4345
Oh, thanks for the correction. I was looking at the versions listed on the CPAN page.
Now I feel ROMO, though (Regret on Missing Out :)
Now I feel ROMO, though (Regret on Missing Out :)
The Mojolicious homepage https://mojolicious.org actually looks almost like the Mojo.js homepage (or the other way round). So much that I first suspected some kind of parody until I realized they were indeed the same people.
That's a good point, we should probably dial down the nostalgia a bit and give it a more distinctive identity.
I was really excited with the first benchmarks but I ended writing a new APIs using nestJs instead. maybe if mojo.js goes towards zero deps and start running in bun, we could use it on microservices where speed is really important but don't want to add another language on the stack (eg: go/rust)
I actually feel kinda sorry for the perl, I've been programming it for 10 years now (lots of projects with mojo and catalyst) and after a while getting use to not so good ORM (like dbic is) I'm no longer interested in writing any new perl for brand new code. typescript with the static type check is too good
I actually feel kinda sorry for the perl, I've been programming it for 10 years now (lots of projects with mojo and catalyst) and after a while getting use to not so good ORM (like dbic is) I'm no longer interested in writing any new perl for brand new code. typescript with the static type check is too good
How does it perform wrt to Fastify ?
I'll never forget seeing this tweet[1] - what I considered a core pillar of the perl community discovered that after a short period of familiarization, a perl developer of many years could write code that is many times faster just by switching from perl to js. No deep voodoo, no special tricks - just write code in JS and handle 3x as many reqs/s. I'm glad to see that the rest of the mojo ecosystem is coming along - Minion is a really nice, simple job queue that can piggyback on your existing postgres database without depending on redis or anything. Would be awesome to see a dynamodb backend someday. Hmmm.
Unfortunately I'm not sure who the target market is - a typescript web framework selling itself as "Perl-grade" anything is not a good look for 99% of JS/TS devs. Maybe it's positioning itself as the logical migration path for companies moving away from perl?
[0]https://github.com/expressjs/express/issues/2844 [1]https://twitter.com/kraih/status/1392405140406210560