Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Mojolicious 2.0: Modern Perl For the Web 132

Posted by Soulskill from the new-and-shiny dept.
Kvorg writes "After a year of rapid development, newly released version 2.0 of Mojolicious, the new generation real-time Perl web framework written by Sebastian Riedel and many others, offers a versatile and elegant web framework that is as good at web scraping and simple scripts as it is at building complex, interactive real-time applications with HTML5 and websockets. It supports easy 0-dependency installs, excellent developer mode, multiple deployment scenarios, many CPAN modules and plugins."
This discussion has been archived. No new comments can be posted.

Mojolicious 2.0: Modern Perl For the Web More

Mojolicious 2.0: Modern Perl For the Web

Comments Filter:

  • But is it prettier than regular Perl?

  • Yet Another (Score:3)

    by bragr ( 1612015 ) * on Monday October 17, 2011 @11:22PM (#37746574)
    Because clearly what we need is _yet another_ way to develop web applications.

    • Re:Yet Another (Score:4, Insightful)

      by grcumb ( 781340 ) on Tuesday October 18, 2011 @12:35AM (#37746932) Homepage Journal

      Because clearly what we need is _yet another_ way to develop web applications.

      Frankly, yes. As long as we're advancing and improving, yeah, it always makes sense to keep trying new approaches. I'm using Mojolicious for two apps currently in development. One of them was already in progress using other modules, bit with the Mojolicious::Lite module, I was able to cut my code base nearly in half.

      I'll tell you what - why don't.you try it first, then complain about it if you still don't like it.

    • Because clearly what we need is _yet another_ way to develop web applications.

      Well, why not?

      Doesn't matter to the end users what language was used for the back-end, and some programmers will be more familiar or comfortable with Perl. Maybe you don't need this, and I personally have no intention of using it, but some people might find it interesting.

    • I still can't figure out how it's actually called. If it lets you use mod_perl then it has a reason to exist. But it probably doesn't.

      • mod_perl is out - no reason to use it any more, especially since its tied explicitly to Apache. Yuk. Who wants to write a web app that requires a specific web server?

        Mojo runs on PSGI, like most new generation web frameworks for perl. Its similar to WSGI (Python).

        There's some really cool stuff happening in the PSGI world. Check out Plack [plackperl.org].

      • Re:Yet Another (Score:5, Informative)

        by MadMartigan2001 ( 766552 ) on Tuesday October 18, 2011 @08:25AM (#37748602)
        Mojolicious is a complete HTTP 1.1 stack. No mod_perl required. It has its own built in webserver, hypnotoad which can be used in production. You can install Mojolicous with a single curl command

        sudo sh -c "curl -L cpanmin.us | perl - Mojolicious"

        And three lines can make a complete "hello world" application....

        use Mojolicious::Lite;
        get '/' => {text => 'Hello World!'};
        app->start;

        Part of what make Mojolicous so powerful is Perl's syntax and expressiveness. I know it's hip to beat up on Perl these days, but perl is still way ahead of most languages in its ability to be expressive. The author of Mojolicous is a really good programmer and insanely picky about well structured code, consistency and test driven development. Hence, the framework is very easy to use and understand. This framework is definitely worth a look.

        • OIC. Well that is nifty I guess, although frankly, I would prefer something that I could use with Apache, because I already use Apache, and nonstandard ports suck. I guess if you're doing anything real you can probably dedicate a box.

  • Perl is the most refreshing programming language (Score:5, Funny)

    by Anonymous Coward on Monday October 17, 2011 @11:27PM (#37746604)

    Every time I look at a script I've written that's at least a year old, it's like the first time I've ever seen the code.

    • So true! Even if you use strict;, apply liberal comments, and avoid $_ and @_ whenever possible.

      • Re:Perl is the most refreshing programming languag (Score:5, Informative)

        by arth1 ( 260657 ) on Tuesday October 18, 2011 @01:04AM (#37747080) Homepage Journal

        Don't avoid $_ and @_; use them when they are useful, even in implicit form. Perhaps especially in explicit form.

        What's more elegant?

        # Declare variable $mystring
        my($mystring);
        # Get rid of $_
        $mystring = $_;
        # Strip line endings from string
        # We use chomp because it will only delete CR and LF,
        # unlike chop which will delete any character.
        $mystring =~ chomp($mystring);
        # We do it twice in case the string ended in CR+LF
        # which is common in MSDOS
        $mystring =~ chomp($mystring);

        or

        require 5.9.0; # avoid ugly $foo =~ chop $foo
        my $mystring = $_;
        # Strip newlines
        while ($mystring =~ m/[\r\n]$/) {
          # String has CR or LF at end, strip it
          chop $mystring;
        }

        or

        # chop any number of CR and LF from end of string:
        chomp while chomp;

        I have seen far too much misguided code of the first and second type.

        Have the comments explain what the purpose of the code is, not how it does it. The way to fix perl code isn't to read and understand the actual code, but replace the part that doesn't work as expected with code that does. If you understand your comment and know how to write perl, you don't really need to understand how a cryptic line does something - it's faster to rewrite it from scratch to do what you want.

        • Assumptions (Score:5, Insightful)

          by CadentOrange ( 2429626 ) on Tuesday October 18, 2011 @07:46AM (#37748418)

          If you understand your comment and know how to write perl, you don't really need to understand how a cryptic line does something - it's faster to rewrite it from scratch to do what you want.

          That assumes that the comment correctly describes what the code intends to do. This is a very big assumption to make and I've worked on numerous projects where the comments were significantly different from what the code did. Looking through the change logs, this situation always arises because someone updated the code but didn't bother to update the comments.

          This brings me to my point: The code doesn't lie.

          If you can't understand a piece of code, you're going to be working off assumptions. Refactoring code based on assumptions is dangerous unless you have very rigorous unit tests. I've found that the level of code obfuscation is negatively correlated with the quality (or even presence!) of unit tests. YMMV.

        • What's more elegant?

          mystring = mystring.rstrip()

          (or mystring = mystring.rstrip('\r\n') if you're pedantic about only removing EOL chars)

      • apply liberal comments

        Don't do it - liberal comments always lie! Comment conservatively instead. ~

  • Wasn't that supposed to be Ruby? (Score:3, Interesting)

    by Sarusa ( 104047 ) on Monday October 17, 2011 @11:32PM (#37746624)

    Not to take anything away from this framework, but now I'm curious since at first I took the post title too literally. Wasn't Ruby supposed to be modern Perl for the web? Whatever happened to that? People get bored? Web developer ADHD?

    • Yes [jwz.org].

    • Re: (Score:1, Interesting)

      by Anonymous Coward

      Hard to do serious web apps in a language that can't even handle the basics of unicode.

      And once you got past scaffolding, rails turned out to be a toy MVC framework that 1) monkeypatches base classes and breaks other libraries, 2) has a toy ORM that can't generate joins properly, and 3) has a template language that basically amounts to script-in-page.

      • Sounds like you haven't touched Rails in 10 years. It handles unicode extremely well now, arguably better than any other framework out there, and even has an extended set of localization options that are way more accessible than probably anything else. As for your other arguments:
        1. Monkey patching is dangerous in any language - luckily with modern Rails there is significantly less need for it and it's generally discouraged
        2. ?? Sounds like you were doing something wrong
        3. You don't understand what the C in

        • Re: (Score:2)

          by Rysc ( 136391 ) *

          Sounds like you haven't touched Rails in 10 years. It handles unicode extremely well now, arguably better than any other framework out there,

          I invite you to consult Unicode: Good, Bad, Ugly [98.245.80.27] and then make that statement again. Full disclosure: Yes, it was written by a Perl guy, but I've not seen any dispute about the facts.

          • Yeah, read slide #26, 27, 28 - note how they basically point out Ruby deals with real world situations pretty damn nimbly. Just because you don't understand how the Ruby Unicode system works doesn't mean it's bad. The comment about "han unification" in the slides is proof whoever wrote those slides has idealogical issues that totally don't take into account the reality - probably because he doesn't deal with CJK and thusly doesn't understand its necessity. As someone who deals with multi-locale Ruby code (

            • Comparing frameworks in terms of Unicode handling is not all there is to it, because a thing like that really needs to be either in the language or in the core library. Otherwise, even if your-favorite-framework handles it fine, my-absolutely-necessary-library (that I want to use alongside your-favorite-framework) might not. In that sense, Unicode support in Ruby 1.8 could be concisely summed up as "no such thing".

              Ruby 1.9 is interesting. On one hand I can buy the argument that CJK and other non-Unicode, no

              • The rest of us will likely stick to tools that let us skip the whole mess, like, well, Python 3 or Perl.

                I just stick

                # encoding: UTF-8

                at the top of my Ruby files and handle everything in UTF-8. If it breaks for some Japanese people because they have some stupid religious objection to Unicode, that's their problem. You don't have to pander to them to use Ruby, so it's no reason to abandon Ruby.

                • That would guarantee that all strings that come from string literals in your source files are in UTF-8. It doesn't guarantee anything about strings that come from elsewhere - e.g. from the standard library, or from any third-party library you might be using.

                  You can ignore such libraries that don't provide you the expected encodings, sure. The problem is when you write your own Ruby library that's supposed to be reusable. Now you have to make a decision on whether you want to enforce your choice on the clien

                  • Actually declaring # encoding: UTF-8 does not assume external libraries are in UTF-8, Ruby handles that pretty well and that's likely because a lot of older Ruby code was written with Shift-JIS. To be honest I've only dealt with non-UTF-8 encodings in Shift-JIS so maybe it only handles those, but I can tell you it works fine and give you a working sample to prove it.

                    "I wish Ruby wasn't written by a Japanese guy - we wouldn't even have to argue about this by now if it were different..." - I don't even know h

                    • Actually declaring # encoding: UTF-8 does not assume external libraries are in UTF-8

                      That's precisely what I wrote. GP's point was that people assume that in practice, though, and he's right.

                      "I wish Ruby wasn't written by a Japanese guy - we wouldn't even have to argue about this by now if it were different..." - I don't even know how to take that. Seriously.

                      Take it exactly how it's written. It's not exactly a secret that pretty much the only ones who have serious trouble with Han unification in Unicode - and, as a consequence, Unicode itself - are speakers of Japanase; and the reasons for rejection are most accurately described as "political". It's also not a coincidence that, of all languages and frameworks that acquired encoding awareness, the one that's

                • "If it breaks for some Japanese people because they have some stupid religious objection to Unicode" - it doesn't break it, it works very very well and is a very practical real world implementation. But "practical" and "real world" mean engl-euro centric non CJK people want to do things like use a base "n" character and put "~" on top of it with an extended character and make every character 32bit instead of actually being sane and just using efficient standards like UTF-8.

                  If I'm not mistaken one of the rea

      • Re: (Score:1)

        by Anonymous Coward

        That's pretty outdated, although I see where it's come from. Most of the issues arise from the old versions on Ruby in use - the ones with shoddy Unicode support, and which require patching of the base classes to gain useful functionality.

        The ORM can now be swapped out (and new versions of ActiveRecord/Arel have made queries much more fun).

        The older erb templates are not the prettiest (though if you're doing PHP style script-in-page, you're using the tools wrong) - but using something like Haml is much, muc

    • Re: (Score:1)

      by Sarusa ( 104047 )

      Oh for fuck's sake. I get moderated down for asking a serious question? I really do want to know. What the hell is wrong with you people? I apologize if I stepped on the tail of a Ruby diehard, but the bloom is off the rose and I am curious why.

    • Rails 3.1 is just coming out and offers some really, really nice features. Rails use is becoming more and more wide spread, and there are even hosts and cloud services that focus on it specifically (EG; Heroku).

    • Wasn't Ruby supposed to be modern Perl for the web? Whatever happened to that?

      Different community values.

      Perl cares greatly about being fast, using few resources, maintaining long-term compatibility. It cares about the sysadmin (CPAN) and sysadmins seem to care about it (perl-Foo-Bar packages for almost all the important stuff). It caused quite a bit of pain about UNICODE and locales in 1997, when ~nobody knew why they were doing that silly stuff. mod_perl has been great for a decade - Passenger was just

    • Re: (Score:2)

      by Sarusa ( 104047 )

      All right, thank you to everyone who answered this seriously. I think I've gotten some idea now.

  • Web development is already "fun" with the likes of Django, Rails (not a favourite of mine but I see the appeal) and my personal favourite: Pylons/Pyramid.

    I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool. It's ugly.

    Sure, it's still better than PHP but then, what isn't?

    • The only exciting part of this new Mojolicious is to expand on a bunch of Perl web stuff you might already maintain. I don't have any large apps (like slashdot), but many "single page" type applications that process data or serve up custom reports. The simple pages simply flush stdout so when displaying long output appear speedy to the user. Others use some javascript and cludgy .html() replacements. Websockets and json support would be nice when extending these applications where the "bulk" of the code wri

    • Re: (Score:3)

      by arth1 ( 260657 )

      I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool.

      String parsing and massaging.
      Hashes.

      Also, system administration. Like sed and awk, perl should be in most sysadmins' arsenal, seeing daily use.
      Want to replace all occurrences of foo with bar in all files, while making a backup?

      perl -pi.bak -e 's/foo/bar/g' *

      What perl is not good for, and frequently is abused for is providing multiple layers of abstraction. You burn memory at an alarming rate, and your code becomes even harder to maintain by "simplifying" it. If good perl code looks cryptic, add comment

    • Re:"Web development can be fun again" (Score:4, Insightful)

      by Anrego ( 830717 ) * on Tuesday October 18, 2011 @12:41AM (#37746960)

      I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool. It's ugly.

      It's still _the_ tool for quick one-off type stuff. I know of no other tool that lets you just mash data together and produce something useful as easily and quickly as perl. That said, I'd never use it for a serious application or anything that had to be maintained for more than a few weeks. Those days are gone.. maintainability and reliability are king.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool. It's ugly.

        It's still _the_ tool for quick one-off type stuff. I know of no other tool that lets you just mash data together and produce something useful as easily and quickly as perl. That said, I'd never use it for a serious application or anything that had to be maintained for more than a few weeks. Those days are gone.. maintainability and reliability are king.

        Well the really smart guys that figure out DNA started using it. Many startups use it. I've used it pretty much everywhere I've gone and it's leaps and bounds above what I find in use in most places. It's huge in Japan. It was the favorite language of the guy who created Ruby, he just wanted more.

        So yeah no serious application or anything that had to be maintained, no never that, because how could anyone possibly write maintainable Perl. Instead you should use a programming language where maintainabili

        • Perl is for really old guys, period. If you're under 45 you're using python or ruby.

          • Re: (Score:2)

            by Ant P. ( 974313 )

            I'm decades under 45, and you can go fuck yourself with a rake.

          • A bit more politer than the other person who commented:
            I am quite a bit younger than 45 (as in over 20 years younger) and I use perl on a regular basis.

        • Your example of Perl is Slashcode? I'm not sure that has the desired affect on the audience...

        • Re: (Score:3)

          by Anrego ( 830717 ) *

          Never said it _hasn't_ been used to write something maintainable.. just that I wouldn't use it for that (any more.. ).

          Yes you can write maintainable code in perl if you make a specific effort to do so, but to me that defeats the point. It's primarily a hack and slash language that lets you crank out code while you think. To me writing maintainable perl is like writing a quick one-off script in c++ or java. Yes you can do it, but why bother. Use the tool that is suited for the task.

          And the DNA thing is a per

          • Yes you can write maintainable code in perl if you make a specific effort to do so, but to me that defeats the point. It's primarily a hack and slash language that lets you crank out code while you think. To me writing maintainable perl is like writing a quick one-off script in c++ or java. Yes you can do it, but why bother. Use the tool that is suited for the task.

            Have you actually written Perl?

            I mean, no offense, but that's just silly. Maintainable code requires a specific effort in Perl? But it doesn't in other languages? Can you provide anything to back that up? I can add use strict; use warnings to my perl and still have less boilerplate code than an equivalent Java (or C++, or even Python) program.

            Writing maintainable code, in any language requires some effort. Period. Perl makes it no more difficult than any other language, and offers more assistance than

      • Perl can be as easy to read and maintain as the developer can be bothered to make it. Sloppy Perl is written by sloppy developers. It has proper variable scoping, namespacing, packages, object inheritance, etc. You also don't have to squeeze as much functionality into one line using as many special characters as possible.

        Sure, there's plenty of ugly Perl out there. I suspect much of that is stuff that started as a small, quickly hacked together script which grew into something larger. Perl also used to

        • If you like LWP, you should check out the UserAgent for Mojolicous along with its CSS dom selectors and other goodies. Amazing stuff.

        • Re: (Score:3)

          by Anrego ( 830717 ) *

          I agree that it's possible to write maintainable perl, but from my vantage point, perl is not really designed for this.

          To me it's more of a hack n` slash language. Code while you think. All those shortcuts and lack of boilerplate code and ability to just say "take this data, compare it with this, and do whatever" in a few lines is to me perl's strength. The fact that the resultant code is hard to read is the weakness. If you are not going to do that, and write code in a more rigid, designed manner to avoid

          • I agree that it's possible to write maintainable perl, but from my vantage point, perl is not really designed for this.

            To me it's more of a hack n` slash language. Code while you think. All those shortcuts and lack of boilerplate code and ability to just say "take this data, compare it with this, and do whatever" in a few lines is to me perl's strength. The fact that the resultant code is hard to read is the weakness. If you are not going to do that, and write code in a more rigid, designed manner to avoid this, why use perl in the first place?

            The argument that it's not the tools it's the developer stands, however I do think some tools are more oriented towards maintainability (java, c++) and others towards rapid development (perl). You get ugly code in every language, but perl almost directly encourages it. The CPAN tool is _the_ definition of perl. Works, but oh my god is this code or cyphertext!

            I think I see the problem here. It's a perception problem. You've decided that you want Perl to be a "hack n slash" language, so you view it in that way, and only in that way. I think you're seriously shortchanging Perl and pigeonholing it to something that doesn't match reality.

            "Why use Perl" if you're not going to write sloppy code? Because there's a huge number of things that Perl can do really well. For example, using Mojolicious, it can be a great tool for designing web applications. Using CPAN,

            • Re: (Score:2)

              by Anrego ( 830717 ) *

              I'd say that the perception of perl as a hack `n slash language didn't come out of nowhere. I'll accept this may have changed as I haven't used perl in a while, and when I did, it was maintaining a very poorly designed system... but it's pretty damn hard to deny that perl at least at one point was the definition of a write once read never language.

        • Re: (Score:2)

          by Rysc ( 136391 ) *

          This a thousand times.

          The purpose I see for Mojolicious is to provide an alternative to PHP, not Ruby, Python, etc.. If we can get people to use Mojolicious over PHP then when their project becomes a big deal it's easier to manage and maintain.

    • Re: (Score:3)

      by grcumb ( 781340 )
      I won't defend Perl's syntactical constructs; either you like the fluidity of the language or you don't. But Mojolicious is a modern, useable framework, far superior in important ways to Django.

      For my part, I find it remarkably easy to implement RPC calls, CRUD especially, using this framework. Go to CPAN, read the Mojolicious::Lite exampes and decide for yourself whether it's worth your while.

      • By the looks of it Mojolicious does support stuff plain Django doesn't pay much attention to or leaves to the webserver (long polling for instance). Useful!

        Then again, Mojolicious doesn't have a built-in ORM or input-validation via forms. Together with URL handling and the request/response loop these are the basic building blocks in Django.

        So 'superior in important ways' depends on what you find important. I'm guessing 99% of Django users beg to differ.

        • Re: (Score:2)

          by grcumb ( 781340 )
          I won't. say you're wrong, but I will say that building asynchronous apps using CRUD and the like is remarkably easy. I have friends who swear by Django, so I'm not blind to its appeal. Mojolicious has different areas of emphasis and the things it does, it does exceptionally well. URL handling in Mojo is simple and elegant, but I simply don't know enough about Django's input validation to comment.

        • Much agreed - this is one of the things Django does very well. Having said that, i think the model handling part of Django is it's weaker point. If you need to do anything remotely complex regarding persistance it gets too much in the way.

          But yes. Most of the time, having a CRUD interface built automatically from the model it's a Godsend.

  • Oh boy (Score:3, Insightful)

    by 93 Escort Wagon ( 326346 ) on Monday October 17, 2011 @11:46PM (#37746674)

    Another perl web framework. I can't wait. I'm champing at the bit. /yawn

    I use perl all the time, and have yet to run into a framework that actually saves time overall. They're generally designed by Unix guys who really don't want to think about web design any more than they have to - and it shows.

    • Re: (Score:1)

      by draven ( 387 )

      I think you are wrong there. Sebastian actually cares about the web. http://mojolicio.us/ was designed by the author of the framework himself, and as you can see it's not your typical Perl project home page. He even drew all the artwork.

  • Useful for just certain applications (Score:4, Insightful)

    by FyberOptic ( 813904 ) on Tuesday October 18, 2011 @12:35AM (#37746926)

    I suppose the idea is neat, but I personally don't have any particular applications where I need Perl to actually be the whole webserver for me. The things that do come to mind would involve a small system where there is no webserver installed, but going on port 80 would mean running the script with higher privileges and the whole mess of Perl and everything need to be jailed. Or maybe to try one of those utilities I heard about to pass privileged ports to an app, but I haven't had experience with those.

    To be honest, frameworks left kind of a bad taste in my mouth when a language such as Ruby that had been around for years suddenly exploded when Ruby on Rails showed up. Everybody and their brother thought it was the new hip thing to use, until a lot of the bigger websites which had deployed it started to actually dump it due to limitations. Nobody wanted to take the time to write good code to start with, and it bit them in the butt.

    Using frameworks (whether it's .NET or on the web or otherwise) usually starts out as a means to set up a new project quickly, but the problem is that they end up being an excuse to make sloppy bloated coat for the final product. Perl was always fast and efficient; people should learn to develop in it that way.

  • So how did the camel icon lose its head? Is it the new security to protect us from zombie camels?

    • Apparently the span tag, which contains the icon and is narrower is width, has "overflow" set to "hidden".

      Ironic in a thread about web development.

  • I've never understood exactly what people mean by "pretty" when it comes to code.

    I assumed it meant easier to read but longer to write, but looking over some comments here, is it used as a synonym for "made it easier?"

    I mean, I find perl ugly but only because I can't read it very well. Otherwise I find it elegant.

  • Wouldn't that be Perl6 [perl6.org]?

    • Re: (Score:2)

      by hey ( 83763 )

      Does it work yet?

      • Re: (Score:2)

        by sqldr ( 838964 )

        I checked the release schedule.

        First alpha: 2045

        Second alpha: 3110

        First beta: shortly before the north american continent collides with the asian continent

        Second beta: approximately around the time of inteplanetary space travel

        Release candidate 1: Dolphins have evolved fingers

        Release:candidate 2: Human race enslaved by dolphins

        Release: Universe dies of heat death

        • Re: (Score:2)

          by blair1q ( 305137 )

          shortly before the north american continent collides with the asian continent

          Actually, that happened a long time ago. Notheast Siberia and Northern Japan are on the North American plate. The Bering Strait is fairly recently dry land that has become depressed due to the compressive stress.

      • Re: (Score:2)

        by Ant P. ( 974313 )

        You could figure that out for yourself [github.com], but I suspect you're not actually interested in having your snarky rhetorical question shot down with an answer.

  • Mojolicious has releases almost every day. 2.0 is just 1.99 + 0.01.
    So what's new? It's just a new release that break things, like almost every others...

    • It's just a new release that break things, like almost every others...

      My point is that the "release early, release really really really often" model of Mojolicious is hard to follow, and sometimes painful.

      Also 2.0 being a major release just after 1.99 is quite unexpected as I've seen nothing announcing it (neither in Changes [metacpan.org] or on the blog [kraih.com].

  • The last time i fiddled with a Perl web framework was with Mason - i've been checking out Mojolicious and it looks really cool. It implements a lot of stuff that Django got right in a language that deserves more love than it usually receives.

    Really cool stuff. I'll have to try it later at home.

  • mojo (Score:4, Interesting)

    by Rysc ( 136391 ) * <sorpigal@gmail.com> on Tuesday October 18, 2011 @12:24PM (#37751134) Homepage Journal

    Totally apart from a pretty slick MVC framework the Mojolicious project has my undying affection for producing the mojo tool.

    How many times have you wanted to scrape something out of a web page and you thought "I know, I'll use wget (or curl) and sed! Easy enough." so you write

    # get story titles from slashdot
    wget slashdot.org -O - 2>/dev/null | sed -e 's/uh, what now?//'

    And then you get stuck fiddling with ever-crazier sed expressions to filter down to just the data you want? I know I've been there a dozen times and wound up with various unpleasant solutions or, when necessary, I've broken down and written a proper perl script which parses the HTML (and taken about 20 times as long as I planned to take to do it!) Maybe you try

    # get story titles from slashdot
    wget slashdot.org -O - 2>/dev/null | sed -n '/"title-/{s/<[^>]*>//g;s/^[ \t]*//;p}'

    And just go with it, because it's good enough. Well, no more! Now I can say

    mojo get slashdot.org 'h2.story > span:first-child>a' text

    And have my results just like that!

    Just as jQuery was a revolution in DOM scripting, to the point where I just won't write JS without it, so is mojo a revolution for these kinds of applications. I can now pull down pages and parse the actual structure and select just what I need. Beautiful.

Slashdot Top Deals

Your program is sick! Shoot it and put it out of its memory.

Close