4 ms·

Mojo.js is a port of Perl's Mojolicious to TypeScript

73 points by petesergeant 4y ago

no_wizard 4y ago
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
- kraihx 4y ago
  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.
- latenightcoding 4y ago
  not the same but torch -> pytorch comes to mind
metadat 4y ago
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
- ofrzeta 4y ago
  The Mojolicious homepage https://mojolicious.org 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.
  - kraihx 4y ago
    That's a good point, we should probably dial down the nostalgia a bit and give it a more distinctive identity.
- sciurus 4y ago
  Mojolicious reached 1.0 in 2010. https://github.com/mojolicious/mojo/blob/main/Changes#L4345 https://github.com/mojolicious/mojo/blob/main/Changes#L4345
  - metadat 4y ago
    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 :)
newaccount2021 4y ago
sarabob 4y ago
It has been interesting watching this develop, if for no other reason that Express is somewhat stuck after TJ left to make koa[0] and hasn't changed much since 2014. Express 5 has had no commits for 9 months - it's not dead, but it's not exactly thriving either. While there are alternatives to Express, none seem to have huge amounts of traction or do far more than a backend framework (nextjs, sveltekit), so maybe there is room for another framework. 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 https://github.com/expressjs/express/issues/2844 [1]https://twitter.com/kraih/status/1392405140406210560 https://twitter.com/kraih/status/1392405140406210560
- ofrzeta 4y ago
  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 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."
  - christophilus 4y ago
    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.
arrakeen 4y ago
i hope this ends up supporting `app.shagadelic();` like the parent framework
- kraihx 4y ago
  Wow, that's a reference i've not seen in a long time. :) I think that Austin Powers joke has not existed anymore in the parent framework for like 8 years!
trinovantes 4y ago
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.
- christophilus 4y ago
  > 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.
  - trinovantes 4y ago
    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
- kraihx 4y ago
  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 https://github.com/mojolicious/mojo.js/issues/66
rcron 4y ago
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
cranberryturkey 4y ago
shubham_sinha 4y ago
How does it perform wrt to Fastify ?

73 points by petesergeant 4y ago

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

kraihx 4y ago
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.
latenightcoding 4y ago
not the same but torch -> pytorch comes to mind

metadat 4y ago

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

ofrzeta 4y ago
The Mojolicious homepage https://mojolicious.org 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.
- kraihx 4y ago
  That's a good point, we should probably dial down the nostalgia a bit and give it a more distinctive identity.
sciurus 4y ago
Mojolicious reached 1.0 in 2010. https://github.com/mojolicious/mojo/blob/main/Changes#L4345 https://github.com/mojolicious/mojo/blob/main/Changes#L4345
- metadat 4y ago
  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 :)

newaccount2021 4y ago

sarabob 4y ago

It has been interesting watching this develop, if for no other reason that Express is somewhat stuck after TJ left to make koa[0] and hasn't changed much since 2014. Express 5 has had no commits for 9 months - it's not dead, but it's not exactly thriving either. While there are alternatives to Express, none seem to have huge amounts of traction or do far more than a backend framework (nextjs, sveltekit), so maybe there is room for another framework. 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 https://github.com/expressjs/express/issues/2844 [1]https://twitter.com/kraih/status/1392405140406210560 https://twitter.com/kraih/status/1392405140406210560

ofrzeta 4y ago
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 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."
- christophilus 4y ago
  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.

arrakeen 4y ago

i hope this ends up supporting `app.shagadelic();` like the parent framework

kraihx 4y ago
Wow, that's a reference i've not seen in a long time. :) I think that Austin Powers joke has not existed anymore in the parent framework for like 8 years!

trinovantes 4y ago

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.

christophilus 4y ago
> 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.
- trinovantes 4y ago
  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
kraihx 4y ago
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 https://github.com/mojolicious/mojo.js/issues/66

rcron 4y ago

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

cranberryturkey 4y ago

shubham_sinha 4y ago

How does it perform wrt to Fastify ?