What does "real-time" mean in terms of a web framework? As a web developer for over a decade, I don't recall seeing a web framework described with that before and have no idea how to interpret it.
I've not really thought about that before, but looking through the commit history it actually seems very likely that we were the first. Back then the WebSocket protocol looked very different from today. https://github.com/mojolicious/mojo/commit/a1a7060e35a6a0965...
That was the first public release. There used to be a History.md file in the repo with the January date. There was a lot of experimentation even before that - browsers started adding experimental WS support on the second half of 2009, right as node was gearing up. Some artifacts from that era:
Another thing to keep in mind is that the precursor SSJS environments like Jack/Narwhal, Helma etc probably added it even earlier. Hard to tell since GitHub itself was new and many of these sources are hard to find today.
It's fine for this project, like others, to have a turn on HN every now and then, but could you drop the promotional voting and commenting? It's happened several times and we usually ban accounts that do this.
Congrats on the release! I've used mojolicious for several of my personal projects and it's been wonderful.
@kraih I applaud your work ethic as the frequency of your commits and releases show you are dedicated to the project and keeping it moving forward. Thank you!
Thank you. I've been very fortunate to have found an employer that enables me to keep contributing to open source projects this actively. So SUSE also deserves a big thank you for making Mojolicious 8.0 possible! :)
Just recently trying to get into Perl (trying to bone up for a specific position that requires it) and Mojolicious has been an incredible discovery: the "lightweight" Rails/Django replacement (somewhere between Rails and Sinatra in terms of ceremony and structure) I've always wanted.
Mojolicious is a mind-blowing framework, doubly so with Mojolicious::Plugin::OpenAPI. Unlike Catalyst, there's very few dependencies.
For a beginner, I'd recommend reading "Learning Perl" by Randal Schwartz first, then read a couple of the online Mojolicious tutorials/blogs.
Also, beginners should note that there's 2 framework approaches, Mojolicious::Lite (a wrapper) and the full Mojolicious, and mixing up the examples or documentation will confuse you.
Yep I'm tearing through "Learning Perl" and "Intermediate Perl" (aka the "llama book" and "alpaca book") while also trying to do some "practical" projects in Mojolicious (https://github.com/ctindall/hotseat is the closest to an actual releasable project, which also has a client in Racket (which I'm just trying to get into, though just for fun)) to apply what I'm learning.
Yes, Cpanel::JSON::XS can be configured to be closer to the original Mojo::JSON behaviour. And the maintainer has historically been more cooperative with efforts to make Perl JSON modules compatible with each other.
>And the maintainer has historically been more cooperative with efforts to make Perl JSON modules compatible with each other.
Indeed, MLEHMANN's (JSON::XS maintainer) difficult personality was one of the main reasons why Cpanel::JSON::XS was created and why it has gained so much popularity despite being almost identical functionally.
I would rather point out that JSON::XS simply refused to fix its most important bugs, and rather blamed upstream. I simply fixed those bugs and kept maintaining it. I also added many new features, just streaming support not yet.
The name is a bit unfortunate though as Cpanel itself still refuses to use it for political reasons. There is a high-profile jerk there running an agenda for his own personal profit.
So I rather want to persuade Lehmann to give me his namespace and continue with it under the original name.
My company uses Mojolicious for all our webdev and Perl for all our in-house stack. Full disclosure, it was my decision ;) but the work is so fast and smooth, I can't imagine switching to anything else.
Since it is built from the ground up around an event loop, asynchronous requests and responses as well as websockets work much more naturally. With Plack-based frameworks the PSGI spec is not built for asynchronous behavior, so you have to rely on hacks and use specific PSGI servers like Twiggy.
And the “deployment” was suprisingly painles. Thanks for that and congratulations for the new release!