back to article Firefox maker moves towards a browser-free world

Something interesting is brewing at Mozilla, and it appears to have very little to do with browsers. For years, Mozilla's brand has been closely aligned with its open source browser, Firefox, despite the non-profit's efforts to branch out into mail suites (Thunderbird), social networking (Raindrop), and more. Now, Mozilla is …

COMMENTS

This topic is closed for new posts.
  1. Marco van de Voort

    Powerpc

    Does that mean they finally going to provide PowerPC/ OS X builds of modern versions?

    Otherwise I would say this is over their heads. They can't even manage reasonably open platforms yet, let alone they want to attack walled gardens

    1. kissingthecarpet
      Linux

      Which browser are you referring to?

      If its Firefox, one can just roll one's own anyway - You, someone else, or Apple.

    2. Tom Maddox Silver badge
      Facepalm

      Certainly

      I think it would be a fabulous use of Mozilla's resources maintaining compatibility with a dead platform. Maybe they can also crank out an Amiga version or a BeOS (PPC, of course) version.

  2. Ru
    Unhappy

    Is it just me,

    or is everything that people are enthusing over about html5 already available in, say, flash?

    Mature toolchain, massive user and developer base, blah blah blah. I guess we should probably be thankful Adobe haven't tried to give us FlashOS yet.

    Me, I see two problems in the bright HTML5 future. Maybe three. Firstly, what is stopping a dominant vendor doing the old embrace and extend trick? Google and Apple spring to mind. Have a think about what Chrome's NaCL is intended for. Secondly, javascript/html is a bloody awful dev platform. I've worked with various languages and GUI frameworks in the past, and whilst few have actually been very good they've all been significantly nicer to program in than javascript, and mildly more convenient for presentation layout than HTML/CSS. Having to code in JS for the rest of my life seems a bit like a punishment.

    Lastly, the whole 'write once, struggle everywhere' approach is probably quite familiar to most web devs. The problem has manifestly failed to go away over the last ten years. It isn't going to stop now. Platform providers are manifestly shit when it comes to supporting complex standards; why is this going to change? This problem is perhaps a subset of the 'embrace, extend' issue above.

    When Silverlight, of all the unloved and unwanted dev environments starts to look good in comparison to the glorious new future, the world is very clearly heading in a bloody stupid direction.

    1. Steve Knox
      Happy

      Problems?

      1. Embrace and Extend has already been tried by the undisputed champion of that technique. It even looked like they might succeed. But they underestimated the desire for the web community to keep their standard, well, standard.

      2. If you don't like it, don't do it. There are plenty of good programmers out there who are fine with developing for the HTML5/CSS/JS platform.

      3. There are relatively few devices out there that render HTML badly nowadays, primarily because of the increased availability of mature engines that are either free and the realization by platform providers that "roll your own" rarely pans out well. Those that do poorly enough to cause problems with web apps generally do poorly enough in the market that you don't have to worry about them.

      Five years to ten years ago, I may have agreed with you on points 1 and 3. But back then, Microsoft was still refusing to update IE6 (the final gasp of their E&E ploy) and every portable device producer was still going it alone on their platforms. Now IE is relatively standards-compliant, and there are only 4 major SFF platforms (all of which are pretty compliant as well) to worry about.

      Finally, Silverlight has never looked good in comparison to anything else I've developed in.

    2. Gilgamesh

      "Mature toolchain, massive user and developer base ... "

      ... bug-ridden closed source memory hog

    3. Steven Roper

      For my part

      having written programs in just about every language since CBM BASIC V2, I can say that the HTML5/CSS/JS (hereafter referred to as simply HCJ) platform is by far the best I've ever worked on, for one simple reason: the separation of presentation and computation.

      With HCJ, your interface layout markup is in the HTML component, your layout styling is in the CSS, and your gruntwork is also separated into JS on the client and PHP/Perl/Python (P*) on the server. This allows you to focus much more on the specific aspect of development to platform component you're currently working in, e.g. with HTML you focus on layout, CSS you focus on styling, with your functions in JS/P*. It makes it so much easier to organise projects and keep your dev team focused on their assigned jobs. Also, because each component is designed solely with its specific task in mind, it's much easier to build, for example, an interface with HTML/CSS than with all the component positioning and other crap in say, C++.

      I think that this conglomeration of HCJ has come not before time. Now that I'm using it on a regular basis I'm amazed that we didn't come out with the idea of presentation/computation separation much earlier in the history of computer programming.

      1. mangobrain
        Stop

        Separation of computation from presentation

        "Now that I'm using it on a regular basis I'm amazed that we didn't come out with the idea of presentation/computation separation much earlier in the history of computer programming."

        You don't have to use "HCJ" (as you insist on calling it) to do this. Two such technologies I've used are GtkBuilder (recent, but its forerunner libglade has been around for a while) for GTK applications, and XRC for wxWidgets applications. These are not the only solutions. Their primary advantage over "HCJ" is letting you write native desktop applications in a choice of compiled or non-compiled languages.

        GUI development doesn't begin and end with Visual Basic, thankfully. Of course the technologies I'm talking about are layers *above* the "raw" toolkit APIs, because under the hood one still needs to be able to construct GUIs programmatically; how else would these things be implemented? The real issue in Windows land is simply that Microsoft has, prior to the advent of XAML, never come forth with any first-party technology for doing this. Even XAML muddies the waters by requiring you to use a .Net language (whereas GtkBuilder and XRC can be used from any language with GTK or wxWidgets bindings), with everything that entails, and its penchant for being compiled into binary files and inserted directly into assemblies.

      2. DZ-Jay

        @Steven Roper

        >> I think that this conglomeration of HCJ has come not before time. Now that I'm using it on a regular basis I'm amazed that we didn't come out with the idea of presentation/computation separation much earlier in the history of computer programming.

        We did. It's called the Model View Controller pattern, or "MVC" for short. It was first described in 1979, and any serious programming framework has offered a variation of it since then.

        It's only so-called "web developers" that are just now re-discovering the old as new, hitting the same age-old problems that have been long since solved and, essentially, re-inventing the wheel.

        Except that this time around, the wheel is not round but oval, it's covered in lots of friction-inducing hairs, is made of solid stone, and requires an industrial engine to roll around. It does, however, have nifty and shiny stickers all around it--with rounded corners.

        -dZ.

    4. Rattus Rattus

      @Ru

      The difference between Flash and HTML5 is that Flash is slow, buggy, and shit. My PC can run Crysis at max settings and high framerates without breaking a sweat, but if I fullscreen Flash Player I'm lucky to get 20 fps. And almost every time I get a crash in a browser session, it's Flash that has crashed. Also, may the Flying Spaghetti Monster help anyone who tries to run Flash under Linux.

      The sooner we're rid of Flash, the better.

  3. Anonymous Coward
    Anonymous Coward

    Well ...

    I hear that apparently they are developing an OS - cum - cloudly thing. Like ChromeOS apparently. MozOS or summat. So not entirely browser free.

    Maybe that's what is going on.

  4. JDX Gold badge

    @Steve Knox

    "If you don't like it, don't do it. There are plenty of good programmers out there who are fine with developing for the HTML5/CSS/JS platform"

    What a great piece of critical thinking. People will get good at using a bad tool, if it's their only option, therefore it's not a problem.

    The word "tool" seems highly appropriate to your post.

  5. mrmond

    Not for Arm6

    Brilliant except they stated they won't develop Firefox mobile version for any android device under Arm7 despite many models still being sold using the arm6 chip (ZTE Blade etc)

    I'll stick with Skyfire on my mobile devices which will also play flash video.

  6. John Tserkezis

    @JDX

    "What a great piece of critical thinking. People will get good at using a bad tool, if it's their only option, therefore it's not a problem".

    Yes, you might be "right", but your way of thinking does not translate at all to what people actually DO.

    History has repeated itself enough times in this area to show that.

  7. json

    The browser is the OS..

    .. long live the browser!

  8. Anonymous Coward
    Anonymous Coward

    Stacks to do and stacks to see

    Firstly, the 'user sovereignty' argument is bogus. This is really about developer sovereignty, and the constant pipedream of a one true platform.

    I'm not quite sure why people think that would be a good idea. We came close to it with Windows.

    Secondly - I'm with the other commenters in not wanting a future where HTML and JavaScript are the only platform. Even agreeing with Steve Roper's comment - that there is a value in separating presentation and computation - HTML was never designed as a user-interface design language - compared to, say, XUL, XAML, NextStep's interface builder/NIB files - some of the 90s 4GL systems also had declarative layout systems.

    Specific example : The lack of data typing on form fields - it's coming with HTML5, but of course we have to be able to fall back, which means we still need to use JavaScript to add something as simple as field validation.

    This is no criticism of HTML - it's just a case of picking something that was fundamentally never designed for the job and then modifying it. Along the way, we've had to fix it - introducing the DOM, removing presentational tags introduced by browsers, etc. To the degree that we've ended up with something that is now too complex for amateurs - who could easily grasp inline style tags - but still constrained by backward compatibility.

    Again, there are similar issues with JavaScript - with the proposal that, like HTML, we introduce a 'strict' tag for a fixed version, that is backwardly compatible with the non-strict version.

    (The irony of this is that the people who use strict compliant HTML and strict safe JavaScript are probably the people most competent to use the 'unsafe' version).

  9. Anonymous Coward
    Anonymous Coward

    Mozilla Free

    I am free of Mozilla at last!!! Fed up after all these years.

This topic is closed for new posts.

Other stories you might like