Servo: Inside Mozilla's mission to reinvent the web browser
zdnet.com
zdnet.com
Do you not realise that means throwing away the entire web, and its history going back to the early 1990's? Backwards compatibility and platform stability are GOOD THINGS that we need more, not less of. Lest we perpetually build content for doomed platforms, and leave no mark, no history on the world.
the better course is evolution, not revolution.
Mozilla has been through every revolution, first hand. They know what they're doing.
edit: I'm flattered but please vote up the comments relevant to the actual post.
1) Amateurs can use it easily and poorly 2) It is not taught in computer science class 3) HTML/CSS is not programming 4) HTML docs attempt to be responsive/liquid as opposed to traditional screen painters.
These are actually good things (and #2 can be fixed) but they represent a significant philosophical shift that most traditional developers don't want to accept.
Edit: damn, it is more than 15 years already. I've brought home the first HTML spec printout in 1996 and got first money for the website I've built in 1998. Still remember fixing <center> bug in IE3 when it came out…
So that makes it 20 years. (dangit!)
Anyway, I think javascript made a mess of it. The point of the web was to link documents. JS makes links obsolete, as they now are relegated to JS-app entry points.
before I get too much in the weeds, I'm gonna go read the article.
Cassowary is hands down the best tech for interfaces.
i thoroughly agree with this if you say "interface implementation technology" instead of "interface design technology". i also believe anyone who disagrees has never fully explored the various print/console/mobile/mfc/actionscript worlds. i mean... have you ever even USED something like pagemaker?
Given my experience with the dozens of UI frameworks we enjoyed since the early 80's I cannot agree.
It cannot be called anything else other than a big hack.
There's no reason we can't keep backward compatibility as long as it's desired.
No one is "throwing away the web", what ever that even means.
We can always put the current stuff in a nice museum and pay tribute to the technological importance it achieved during the evolution of the web! vs an evolution of any seriously flawed specific piece of technology.
Also, this really is not a "want", rather the real problems are creating real needs.
That is exactly what Servo is doing.
Does "ditch" and "junk" mean something other than the common usages of these terms to you? The only assumption I'm making is that you're writing in english.
I was suggesting to ditch specific technologies, not the "web" as you put it. So it's... what the web means... That I referred to.
Go on. Use them. I dare you. See how long you last.
or invent your own platform and see how quickly everyone switches over to it. I'm sure the only thing stopping this from happening is nobody has tried. Sure!
I didn't say that html/css/doesn't need improvement. that's changing the subject. The question is: why do the people here so eager to "ditch" (as in totally discard) html/css/js.
<section> and <article> are new semantic containers for content.
or .main or any number of similar classes.
<main>?
Aren't you the least bit curious why it succeeded despite not being to your taste? Do you think it's just accidental? That the laws of physics and rationality were suspended for one brief glorious moment in the 1990's? Are you a web creationist?
Or do you believe that there's an actual answer?
Just how exactly do you archive that content anyway? Anything you "buy" on those platforms is not something you own. It's something you're licensing for short term use. Doesn't sound like a great outlet for culture to me. It sounds like a death trap.
> Just how exactly do you archive that content anyway?
> Anything you "buy" on those platforms is not something you own.
Define "win". From my point of view, the web has not only won desktop, but utterly dominated it, and relegated the rest of the OS to a mere substrate for webpages. The only things it hasn't really replaced are photoshop, final cut and protools. It's only a matter of time.
"Why should I archive anything? I don't archive web pages I visit either"
oh boy. Paging Jason Scott. Jason Scott on aisle 12.
" I don't care. I change my phone: they are already there. I get new Mac:"
I'm glad you can thrive only on corporately produced content you license for brief periods of time. Many people out in the world are not corporations, and produce things that they care about. Many use computers to do this. Most care about the thing they made, and not about the tech they made it with. And so it ends up in these closed off little data silos and proprietary formats- not only are these things not backed up, they can't be backed up.
And then those people die, and there is nothing left of that person except what they made on the iPad with iOS6. The apps the things live inside are not compatible with the newer iOS. When that iPad dies, it's like the father, the lost son, the missing daughter- they die for a second time.
But you know, it's good that owning that stuff doesn't matter to you, and therefore should not matter to anyone else.
ta.
Well, yes, technically, we as tech savvy people could, but the commoners (not to say technophobics), they don't know how.
and that is how it is designed. You don't need backup, it's in the cloud. What happens when it is not anymore ?
It is not owning but rather preserving that is the concern. Is everything worth preserving though, I don't know.
Also, having books and movies stuck in your amazon or apple account is convenient for consumption, but horrible for creation. You can't DO anything with that content. I've wanted to extract interesting stuff from books I own before and was forced to make screengrabs. If you don't understand what's wrong with the media rental model, go read "the right to read" by stallman.
By the way, you have drifted away from discussing the technological aspects of the Web. This line of argument doesn't help establish why HTML/JavaScript/CSS are better.
Apps cannot.
That's why HTML matters.
If we'd started with xml compatible markup (all tags must close in order), and no browsers supported a quirks mode... we'd have much cleaner web browser engines and a much more usable web today.
I think that JS has a few quirks as well... so does CSS.. JS and CSS came after HTML, and even then have grown/distorted a bit. XHTML broke too many things, so we went pragmatic with HTML5. Just the same, no "new wheel" will get adopted in this space whole-sale. People have ditched XHTML and run back to HTML5.
I think a lot of things could be better, and will get better... so long as there are billions of pages/sites out there as-is, quirks mode browsers aren't going away.
Sigh.
Just the same, it started with well-formedness being loose, and continued from there.
The well-formedness thing is, sorry to be blunt, a totally crazy thing to complain about.
Every single platform that has any popularity introduces rough edges like this over time. It's impossible not to because every single bug that introduces relaxations gets baked in as content comes to rely on it. It is impossible to ever remove those relaxations, and really, it's totally fine.
There is a cost to lack of well-formedness, but on the list of problems with the web it is waaaaay waaaay down there.
Oh yes, I do remember those nice <layers> in NN4 and that CSS wannabe mingled with JS.
For what I am grateful is Firefox (before the rise of chrome). However I think the proper mindset left Mozilla together with Blake Ross and all that's left is posturing and politics.
Mozilla is making Firefox and helping keep the web open with new APIs, standards. It is helping with the politics side regarding net neutrality. It is helping millions learn how to build web pages thru webmaker.org program that teaches web literacy and moving onward to teach app making with Mozilla Appmaker. Mozilla is helping bring the next billion people online by working with partners to offer affordable mobile devices on emerging markets where people can't afford computers or high end devices. Thats more than posturing.... Thats the result of a global community of volunteers, staff and partners working together to make the web and the world a better place for everybody.
The web is more than the browser. The network protocols is what matter, not the browser.
the better course is evolution, not revolution.
Candles oil lamps, and torches were pretty good at providing light at night in the 18th century, then there came electricity and the light bulb, everyone slowly threw away their candles for something better. Many people tried to design better candles instead of switching over. Candles that would burn brighter and longer, candles that would not blow out as easily and did not put off as much smoke, but you know what? These were was mere evolutionary changes and could not "hold a candle" to the revolutionary benefits of the light bulb.
Sure it took a lot of work for people to take their oil lamps and candle fixtures off of the walls and ceilings. It was a lot of work to run wiring and put up new electric fixtures. But the time spent was an investment. Eventually it led to a lot better solution and a lot less effort in total.
You are one of these guys who was using and evolving candles and oil lamps. You just can't see the bigger picture.
These HNers who are not happy with still being forced to use candles are the real innovators... The technologists. You who are happy with the candle are merely paint and canvas artists.
Paint and canvas artists in the 80s and 90s started to scoff when computer art and graphics began to gain prominence. These artists lacked the skills to do art with new technology, and lacked the ambition and any passion which was required to learn something new that would have diversified their artistic talents. They had their tools and they didn't want new ones. Their opposition actually was a result of a fear of being displaced, they wanted to stay in their stagnated comfort zone.
Many web designers today are much the same. You want to make art with your old tools and are not really technologists at all, perhaps with new brushing techniques (JS libraries) in some instances, but never with any major evolutionary change.
This stagnates innovation, even worse you are actively supporting the suppression of choice because you are afraid that you may become obsolete in your complacence with the technology behind your art.
Should be later this year.
> and someone could write an in depth and well structured book on it.
Give me some time. ;)
Question: are there any moderate-sized codebases (ie not Servo, not Rust itself) that can be used to show idiomatic Rust? In my own experimentation (a simple image utility to resize images and convert to b&w), I ended up writing it a lot like I would C, which I know isn't correct based on snippets I've seen. Or rather, it's correct in that it works, but it's not particularly idiomatic and the Rust elite would sneer at me.
It's like the early days of C++ when people were writing it as "C with classes", complete with pointers everywhere, malloc, etc. A lot of that could have been mitigated with some easily digestible source that clearly demonstrates the idioms. Maybe a small game, a simple text editor, etc.? Does anyone know of anything like this? Or is it too soon for this?
I am not entirely sure that 'idiomatic Rust' is something that's fully figured out yet. Rust itself is _certainly_ not idiomatic, as it's a hodge-podge of several historical coding styles.
As I said when I spoke at the Bay Area Meetup, my position in Rust is 'eternal newbie,' so I'm not actually the best one to ask here. Maybe pcwalton can chime in.
OMFG..and in this day and age is soooooo much more important not to be sneered at by the "elite" then it is to have working code...
man do i miss the days when programming was about getting stuff working not worrying about the political and social impact of how your style was...
EDIT: not always, of course, but unless it's a one-off tool, it doesn't make a lot of sense to NOT be idiomatic.
As you know, Real Programmers can write FORTRAN in any language.
But, do we want to?
No, we want to learn what is new and useful in a new language. We want to learn how to make best use of that language.
That doesn't mean writing code that looks just like the language we used before. What would be the point of using a new language, then?
No one cares what the "Rust elite" think. Didn't you see that that was just a humorous throwaway comment following a much more important point: writing idiomatic code.
Learning to write idiomatic code helps us see what is new and useful in any language.
We won't learn that by writing FORTRAN in the new language.
But seeing how experienced users write their code is a great way to see what is good and interesting about the language.
Go kind of wanted that prize. It didn't quite get it.
Many will say how they care about cool features, built-in concurrency, nice stuff and in the end, when comes to releasing product if performance isn't there, it won't replace C++.
Some program in C++ because they love the language. They really do. There are people like that, I've met one, once. Quite often others do it because the rest of their world does (libraries, coworkers) and performance.
The niche were performance matters (and I understand that is a loaded word so to speak) is going to be hard to get into.
How was a garbage collection language ever supposed to take the place of a manual memory management language? The area that C++ shines in is systems programming, and you can't do that with Go, because of garbage collection. Rust on the other hand, is precisely made for systems programming.
That is simply not the case. Rob Pike himself describes how we was working on a large C++ application when he thought of creating Go:
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
I like C++ personally for its power and keeping performance accessible (especially with new developments of C++11 and beyond). And looking at new alternatives, Rust looks more like a successor to me than Go. As others pointed out, Rust doesn't enforce garbage collection, while Go does. For example if someone would want to write a demanding game, they wouldn't do it with garbage collection enforced language.
That's why Rust is about zero-cost abstractions, period. Unlike almost every other new language (for example, Go), we don't accept abstractions that compromise performance.
This is an article about Servo. We care about performance for Servo—along with safety, performance is Servo's entire raison d'être. Much of the focus on performance in Rust is motivated by the desire to build an engine that's faster—not just "as fast as" or "within the ballpark of", faster—than the existing C++ engines.
FWIW the language is only nearning 1.0 in that 0.9 > 0.8. 0.9 is by no means the final pre-1.0 release.
And this is Mozilla. They are used to putting out releases often. Firefox Nightly is at version 30.0 :)
What's the pain point here, beyond just wanting to reinvent a round-enough wheel?
Anyone who has attempted to implement trivial things, like thematic scrollbars or cross-browser capable code, or dealt with dom thrashing via JavaScript, knows the amount of effort going in (or knowledge required) to do trivial things is ridiculous; considering how long we've been travelling down this road. Why are we still using a wagon? And why do we want to build more of them running in parallel?
That's true, but that's maybe for the better?
In the sense that it leaves a place for desktop and native apps to thrive too.
I would worry if the browsers was a great execution environment, that could even run Photoshop or Valve or Pro Tools, and every company went that route.
It would mean total loss of data freedom (they would push you to have them in the "cloud"), and a rent-model for software purchases, with software being able to completely change under your feet (like Gmail did for example).
We absolutely plan to (and are!) working on new standards that enable greater efficiency and developer productivity. I don't like the fact that floats are used for layout any more than anyone does, not the least because it makes it hard to parallelize. But at the end of the day we're building a browser, not a from-scratch app platform.
If your browser won't browse the Web, consumers simply won't use it.
I was just hoping there was some interesting project already underway I could read about.
Create an entirely different model. One that acts as a hybrid between a full blown inefficient co-ordinate system and, plausibly, a more efficient box model.
We could start by modelling 'movement' which equates to objects having 1. A reference point, 2. A magnitude and 3. A direction.
It would be beneficial to do this in such a way that one could apply functions to said model achieving a reactive design that gives you a sense of a full blown co-ordinate system while achieving simpler mechanisms for ease in development and efficiency.
I know that's pretty high level stuff, but in my mind I can see a fairly clear path to achieve a significant improvement.
The real competition for the web are the walled gardens of iOS and Android App development.
I have no pipe dreams. Displacing the aforementioned technologies with something better is inevitable. I just gave an example of how easy better ideas are to be found.
The benefits are also clear though, basically not being limited to current standards.
And Apple would shove some Obj-C renderer down your device, only this would support only iOS, MacOS and Windows, not Android and certainly not Linux.
FOSS-Shops would transmit only a repackaged build system which then would start downloading source packages and start compiling them in your browser. 3min later and you could actually start using the application.
I really fail to see the advantage here.
First things first, I found out the other day that someone actually built the major part of my vision: Constraints Oriented stylesheets (using cassowary).
This is how iOS now handles layout. It makes easy things easy, and hard things achievable. Exactly what you'd want.
Beyond this, I think that html has too many tags. To put another way, the browser should not generally permit <script> and <style> to exist in the same context that <em> can exist. onblah= attributes were a terrible mistake that we'll never be able to undo. It would be cool if there was something like a <content> tag which, within it, only permits content oriented mark up, while disabling scripting and styling tags. Likewise, forms, scripting, meta tags and linkages should be in isolated contexts.
And finally, what idiot decided that & ampersands should have a prominent position in many URLS and then use & for entity encoding in html, a completely different purpose. URLS now have to be http://entity&encoded
uhg. so stupid. what would be wrong with <amp> or <amp/> instead? or since we've freed up & for normal expected use, <gt> <lt> and <quot>
ah well.
the paper describing the algorithm is here:
https://docs.google.com/viewer?url=http://www.cs.washington....
example.com/?a=1&b=2
vs.
example.com/?a=1;b=2
https://stackoverflow.com/questions/3481664/semicolon-as-url...
Somewhere along the line, for some reason, everyone settled on & and the web ossified around the assumption that was the only character that ever gets used.
https://chromium.googlecode.com/files/chromecomicJPGS.zip http://www.chromium.org/blink
But the means are extremely different between those projects.
[1]: http://www.nets.eu/dk-da/Produkter/Sikkerhed/NemID-tjenesteu...
PDF plugin -> PDF.js
Flash plugin -> Shumway.js
Java Plugin -> Nope. Good riddance.
Others -> Nope
As far as I know Silverlight's primary draw is DRM. Good riddance.
Then I hope they don't intend on supporting any 32-bit platform. Make a clean start on 64-bit platforms. By the time Servo is out, there should be 64-bit ARM processors cheap enough even for their low-end phones, and on a desktop it should be a nobrainer.
It wouldn't be optimal, but at least they wouldn't have to completely write off older or lower-powered devices.
this type of thinking is so negative... why would you ever make not supporting/doing something to be a project's goal?
the servo devs might make speed of development or maintainability a goal, and that might lead to the decision not to support 32-bit (it's not clear to me why it would create that much overhead on either front, but then i don't know rust).
sorry if that's tangential, but reasoning/explanations of the form, "here's the goal: let's not accomplish __," is broken, and i just needed to vent.
Yeah, right. Modern browsers already eat up several GIGS of memory, while super-advenced-zomg tablets boast of 2G. Most have 1G 80% of which is eaten by the system (and widgets, and other persistent stuff). But not caring about memory is hype. Because its future, technology, and, you know, Moore's law
So they try something else.
> them the proper marketing so they have a chance to thrive?
For mediocre products to thrive just marketing is not enough. Marketing is a good accelerator for already great products. If they are not great, marketing is working against the flow. Sure one can show people the cool Windows 8 tablet commercial with people dancing in it 100 more times and maybe they'll get a few more sales, but that alone is not going to be enough to make it a success.
[1] http://video.fosdem.org/2014/UD2218A/Saturday/Servo_building...
See "Fast and Parallel Webpage Layout" for some early work by Leo Meyerovich at UC Berkeley: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pub...
Even IF it fails it's still a benefit as a data point. Rust people are reusing a lot of Mozilla software stack and plan to do auto conversion of C++ to Rust (where benefits are greatest).
This... is news to me? I'm pretty sure we have no such plans at all.
I think it was this issue that talked about porting using Java -> Rust and C++ -> Rust translator.
So, it might have not worked out for Netscape the company, but then nothing would have, and at least if worked well for Mozilla the organisation.
[1]http://damienkatz.net/2005/01/formula-engine-rewrite.html
> With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).
-- haberman (https://news.ycombinator.com/item?id=7288033)
Stuff is rewritten all the time. Servo is not replacing all of Firefox, just an experimental project to replace Gecko by a skeleton crew.
It's not yet another HTTP, HTML, CSS .. implementation that is needed, it's making these standards sane and fit for 2014.
Judging by the number of people who complain that their browsers are slow, it absolutely seems like useful work to me.
> It's not yet another HTTP, HTML, CSS .. implementation that is needed, it's making these standards sane and fit for 2014.
A quick search turns up dozens of standards that Mozilla is working on: https://www.google.com/search?q=w3+module+mozilla+corporatio...