Mozilla is hoping its Firefox OS can capture the interest of developers building media players and robotics with Raspberry Pi boards.
Mozilla is hoping its Firefox OS can capture the interest of developers building media players and robotics with Raspberry Pi boards.
… where’s Thom?
Vacations, maybe ?
Anyway, what is the benefit for Firefox OS to spread everywhere ? Gets a larger dev/user base, hence future marketshare ?
Kochise
Lake Placid, NY.
Thom is on vacation, so the B-team is trying to keep things afloat in the meantime.
cool!
thanks David!
The B-team is actually posting more interesting content than Thom usually does. This site doesn’t look like his personal blog, for the first time in a long time.
And there’s none of his locked social justice warrior bs posts that cannot be discussed or commented upon.
That said, I love Thom and his sense of humor.
lol, what sense of humor.
Pink unicorns preyed from his cold dead hands.
Kochise
They are only alive because Google pours huge sums in their pockets to keep them as default search engine.
And at the same time, they diss everything cool Google makes that would be really useful to the web, like PNaCL or WebP, instead they invest in ridiculous stuff such as FirefoxOS. Hope their market share falls enough so they die already.
asm.js is way cooler than PNaCl
I would +1 you if I would not have commented other post
Yes, asm.js is amazing!
ebasconp,
On the one hand, what you can accomplish with asm.js is cool (through the use of javascript trans-coding compilers). However on the other hand does anyone actually think it’s exemplary of the kind of engineering we want to push for the future of the web? It’s not human legible code, and as a compiler target javascript isn’t a very compelling choice. It seems the sole motivation for asm.js is because javascript has a monopoly in the browser. Admittedly this kind of backwards compatibility is significant, clever even, but it still feels like a hack. I’m curious what everyone else thinks!
Isn’t research a huge part of it as well? Pushing the boundaries, seeing what’s possible, developing new techniques, measuring their efficiency and optimizing them. There are various indirect scientific benefits, knowledge is important too!
As for the practical side, I don’t know, but I guess it doesn’t hurt to have a bit of competition.
cfgr,
I’m not actually sure what you mean by this, maybe an example would help.
To me, it’s ironic that asm.js encourages devs to use other languages with more traditional compilers to produce higher performance web apps than one gets by programming in javascript natively. In a strange way, the more use that asm.js gets, the worse it bodes for javascript as a proper language.
I agree competition is good, but I think it’s difficult to actually achieve independently from other factors. For example, if I want to use an iphone, I am not given the choice since apple prohibits competing implementations, just as MS does in Windows RT, etc. So much for competition.
Anyways, I submitted an article about asm.js. Hopefully if it gets accepted it could provide a better backdrop for our discussion.
Edited 2014-10-29 05:09 UTC
I meant that it pushes various aspects of their Javascript engine, a bit like a benchmarking tool.
For example: http://arstechnica.com/gaming/2014/10/humble-mozilla-bundle-pushes-…
I consider projects like these (asm.js implementation) the equivalent of a research paper (but with the bonus that its code is completely free to read!). If their approach works, great, others can learn from it and modify this for similar problems. If their approach doesn’t work, also great, then we know it’s a dead end. This way everyone wins, even non-asm.js users.
Edited 2014-10-29 09:11 UTC
I wouldn’t call asm.js transcoding.
You should think of asm.js more like a bytecode for the Javascript VM.
There are people that like to use coffeescript or typescript, etc. they call that transpiling.
It depends, you can mix and match Javascript and asm.js on the same page.
The reason people use compilers is when they need to create something performance critical.
And it’s normal for things that come out of a compiler to not be human legible.
One of the characteristics of a scripting language is that it is human legible.
But if you look at how Javascript is used today:
http://www.osnews.com/js/jquery.min.js
Would you call that human legible ?
Then again, if you put that into http://jsbeautifier.org/ it’s not that bad.
The reason developers do this is because of HTTP/1.x luckily HTTP/2 is on the way to fix those problems. But adoption will take a while I think.
And as it turns out the Javascript code (jQuery), it’s open source code anyway. You can go to the source and even participate in the development of jQuery if you like.
I see more and more developers use open source libraries and tools as their base to start from. And I also see more and more companies sharing their code.
So maybe that is what you should be encouraging.
The reason we now have javascript as a monopoly is because IE-team reversed engineered Javascript as Netscape had produced it. Which took a lot of effort on their part because it has a lot of quirks (any language you create in 10 days will have flaws !). They documented and implemented all of them ( well, they did make a few mistakes ).
When it was time to standardize it Microsoft said we are only going to do that if we keep all the flaws the way they are. So Microsoft single handedly in a way made Javascript popular and horrible at the same time.
The browser makers know they can’t agree on any other language to add to the browser so they are working on improving Javascript. While trying to be mostly backwards compatible. Most Javascript developers these days stay away from the ‘Bad Parts’ and use mostly the ‘Good Parts’.
Javascript as a bytecode/compiler target is probably going to happen. You can’t stop people from doing it.
It is a little bit like putting DRM in HTML5. Will it end up helping to make HTML5 a more viable platform or will it end up creating more barriers.
I don’t know, I think it might be better to be inclusive.
Am I going to welcome the asm.js people ? Of course.
Am I going to welcome the DRM people ? Not so much.
Lennie,
This is exactly how I think of it, but IMHO it’s a poor substitute for a “bytecode” for several reasons because it was never designed to be a bytecode in the first place. It’s actually slow to (re)compile. LLVM compiler has to restrict it’s vocabulary to the subset understood by javascript. It has poor parity with CPU features, making it difficult/impossible for the backend compiler to take advantage of optimization it can normally perform.
So I get that it’s neat that it runs in the browser, but if it weren’t for that fact, I find it difficult to believe anyone would promote this as a practical bytecode technology.
But this is kind of my point. A huge pro for javascript was it’s human legibility, and that it was self contained with no need for external processing. And though that’s still true for those of us who use javascript directly, as more developers are shifting to external code generation tools in practice, then the relevancy of these pros because mute. As more people look for JS alternatives (such as coffee script), we have to ask ourselves whether it makes good engineering sense to keep javascript as a foundation.
That’s great, but it’s not really exclusive to javascript in any way.
MS actually promoted vbscript in their browser! Thankfully it never caught on. Unfortunately it did catch on in the form of ASP (legacy), which I had the misfortune of using for a short stint in my career.
You are right, and I have to concede that agreement on a superior “VM” may not be possible.
I should clarify something: I personally look forward to making use of alternative languages via asm.js in the future, which might sound odd in light of my criticism, but I’m a pragmatic person. I like what asm.js offers in the end, I just think it’s unfortunate that we haven’t been able to standardize on a superior implementation, one explicitly designed for this sort of thing. Moving forward it will likely be difficult to change since asm.js will be “good enough”.
Edited 2014-10-29 15:19 UTC
The Mozilla developers have said, parsing the asm.js code isn’t slower than parsing binary bytecode. So I don’t see anything bad for that.
And the bytecode Java uses isn’t processor specific.
Java does JIT at runtime and Javascript does JIT at runtime.
I ones read/heared Mozilla wants to eventually add JIT-hints to asm.js as well to even optimize things more.
You could use jscript in asp too if you wanted. 😉
Just don’t use both in the same code base, it’s very bad for performance every time it has to switch between them.
Lennie,
I’m skeptical of such claims, do you have a link to any benchmarks? I don’t have time to test it myself right now. The unreal demo seems to be down, but IIRC it took half a minute for javascript to recompile the asm.js generated code, has it gotten any better?
It’s not necessarily that javascript is slow at parsing, but also that the transcoding into asm.js can require more code to begin with.
https://adblockplus.org/blog/thoghts-on-using-asmjs-for-performance-…
It’s not just libraries either, even normal code is big in asm.js and it’s not difficult to see why. Static types simply don’t map very well into standard javascript. Consider normal integral math operations, which are _extremely_ common in static languages, have to be expressed using a bizarre notation for every single integral math operation expressed in javascript. This is just to make up for the fact that javascript doesn’t have true types.
x = (x + 1)|0;
https://kripken.github.io/mloc_emscripten_talk/gindex.html#/14
It’s true asm.js is designed to see this and optimize it away, but it’s also true that a transcoder is forced into using these bizarre code conventions to produce code that’s compatible with standard JS. Adding hints can help asm.js use information from the first compilation phase, but it’s going to become even more complex and bloated. As a software engineer, the more I dig into asm.js, the more I feel like this:
http://tvtropes.org/pmwiki/pmwiki.php/Main/FacePalm
At least this is all behind the scenes, typical users will always get the benefit of asm.js working everywhere, which is a plus.
I specifically mentioned parsing.
parsing isn’t slower than a binary bytecode.
Yes, asm.js is bigger. But gzipped it’s not, it’s similar in size to a bytecode.
Compiling is a different step.
With asm.js they can skip a number of steps. But what makes for a worse user experience is that it will compile the whole asm.js file in one go. If I’m not mistaken normal Javascript is parsed and compiled in pieces. The advantage for asm.js is that after loading performance will be predictable as there are no new compile steps of small pieces and asm.js has no garbage collection.
Lennie,
Ok fair enough, but I’m still be inclined to think a kind of “RISC” instruction set might be “parsed” easier/faster (maybe 2 or 4 bytes at a time) due to it’s well defined structure and ability to store values directly without any base conversions. Not only does javascript have to parse all input one character at a time, but it has to evaluate abstract syntax trees in the process, to keep track of javascript’s order of operations, which was designed for humans. A more natural syntax for efficient computer parsing would be a language like forth, used in embedded systems for exactly that reason.
I’m really nitpicking here, “parsing” in isolation of everything else javascript needs to do is not going to take more than a blip of time. Still, for the reasons above, I question claims that js parsing is “as fast” as a purpose built bytecode. I’m more comfortable agreeing to an “insignificant” amount of time, which is why I wanted a link to read myself.
Anyways, I’d like to leave this thread and continue the discussion under the asm.js article!
Yes, sorry for being unclear, insignificant or a similar word is what he did said.
I wouldn’t be surprised that asm.js doesn’t need to use the abstract syntax trees in an engine that has asm.js support like the browser engine in Firefox. Because asm.js is prefixed with special characters to indicate it is asm.js so the browser engine can skip a number of steps.
It’s meant to be bytecode that can be compiled with the JIT compiler with as little steps as possible.
Kind of funny how Asm.js also made it up on the frontpage of OSNews on the same day:
http://www.osnews.com/story/28005/On_Asm_js
With all that can be done with Linux on the RPi, why would I want to bother with a half done OS like Firefox? Love the browser, but the OS seems a bit pointless.
https://www.youtube.com/watch?v=Uy062kp-LM4
TL;DW the guy takes his FirefoxOS phone apart and is able to make into a dedicated, simple to program platform for “The Internet of Things” tasks due to FirefoxOS’s built in Javascript environment and its hardware bindings.
I think this video shows a pretty good use case for having FirefoxOS on a Raspberry PI. I don’t know if any of the tasks he does can be done any better on FirefoxOS vs other, more mature RPi distros, but that’s what the article reminded me of.
This is about the Rpi.
JS has spread everywhere like a virus over the years. And now it’s infected this thread. :/
Anyhow, I appreciate the attention the Raspberry Pi is getting outside of this thread. Thanks Mozilla.