11 ms·

Mozilla Research Projects

440 points by yuashizuki 12y ago

mp3geek 12y ago
No pdf.js?
- MegaDeKay 12y ago
  "Following on the success of pdf.js, a high-fidelity PDF renderer written in pure HTML and JavaScript, the Shumway project..."
  - pedalpete 12y ago
    but I thought Shumway was about converting flash to html, not pdf, or is it now pdf and flash?
    - ripdog 12y ago
      It is. pdf.js does pdf, shumway does flash. Read the linked page.
    - SwellJoe 12y ago
      Separate projects. But, pdf.js is integrated into Firefox and is past the research stage. I believe they're just sort of saying, "Hey, we made that other seemingly impossible idea work when we made pdf.js actually work pretty well, so you probably shouldn't laugh when we say we're implementing Flash in JS and HTML5."
    - dherman 12y ago
      (Director of Strategy for Mozilla Research here.) pdf.js was the brainchild of Andreas Gal, now our CTO but at the time a cofounder of Mozilla Research along with Brendan Eich and me. That project started briefly in Research but was shepherded to product pretty quickly. Shumway is a separate project but similar in spirit. It's not a converter per se, but rather an emulator including a full ActionScript Bytecode (ABC) JIT, implemented in pure JavaScript. Right now we are interested in getting Shumway to the point where it can be used in Firefox as an alternative to the native Flash plugin for certain kinds of web Flash content, to provide better security, stability, and performance. Over time as Shumway matures the ultimate goal would be to eliminate the need for the Flash plugin entirely, but we'll walk before we run. But Shumway is usable as a standalone project as well, and others have begun taking notice. For example, Prezi has invested in Shumway as a library for rendering vector graphics: https://medium.com/prezi-engineering/how-and-why-prezi-turned-to-javascript-56e0ca57d135 https://medium.com/prezi-engineering/how-and-why-prezi-turne...
  - dfc 12y ago
    "...aims to implement an emulator for the Flash multimedia platform."
    - Mahn 12y ago
      The point is not that Shumway is directly connected with pdf.js, but rather that the wording in its descrition suggests pdf.js is no longer a research project.
- dfc 12y ago
  I think the take away is that pdf.js is no longer a mozilla research project. It has been included with Firefox since v19.
- theandrewbailey 12y ago
  It looks like that's a Mozilla Labs project, not a Mozilla Research project. https://mozillalabs.com/en-US/pdfjs/ https://mozillalabs.com/en-US/pdfjs/
ChrisAntaki 12y ago
Keep up the great work, Mozilla! I'm excited to see where a lot of these projects go, especially asm.js.
mindcrime 12y ago
Hmmm... would it make sense to talk about a JVM written in Rust? Could that make it easier to write a safe JVM that would be less susceptible to exploits? It would be wonderful if we could get there and have a Mozilla browser with "out of the box" Java support without needing a separate plugin.
- Jweb_Guru 12y ago
  Rust can't really make JIT compiled code substantially safer. JIT compilers are pretty much the unsafest things ever.
  - deleted 12y ago
    [deleted]
  - dbaupp 12y ago
    To be specific: Rust's memory safety guarantees only guarantee that the Rust code is free from memory safety violations, it can't make any sort of guarantees that the output of that code is sane. That said, maybe the other features like ADTs and explicit compile-time tracking of ownership make writing correct JITs (slightly) easier over plain C++, but that's yet to be seen (and it seems like it would be small in any case).
- pjmlp 12y ago
  There are already JVMs written in Java like JikesRVM, Graal/SubstrateVM and a few others. There is little that Rust safety could add over Java memory safety. There have been talks that Hotspot might eventually give place to Graal, but no plans were ever given.
- MichaelGG 12y ago
  Aren't most or nearly all of the Java exploits related to running sandboxed code? Instead of relying on a code security model, use containers or other external permission systems. For Microsoft, all the RCE were either use of C/++ or loading .Net into partially trusted scopes (like a browser). I think Rust would have perhaps fixed a few of the managed runtime vulnerabilities, but probably not the majority. Forget sandboxing and you're done.
bjz_ 12y ago
A neat thing about Shumway is just how much of it is written in Typescript[0]. It's great that Mozilla is getting behind the project. - [0]: https://github.com/mozilla/shumway/tree/master/src https://github.com/mozilla/shumway/tree/master/src
bobajeff 12y ago
So I take it this means that Mozilla is reopening "Mozilla Labs". It's interesting to see Shumway on there as I was under the impression the project was put on hold.
- Jakuv2000 12y ago
  I'm surprised that pdf.js is described as a "success". I don't think I've ever heard a user of it say anything good about it. Any time I have heard about it, it's always somebody else in the office cursing loudly about it taking forever to open a PDF, or that it locked up Firefox, or that it's rendering something improperly, or that they wanted Foxit Reader or some other app to open the PDF instead of Firefox. Just because it's integrated with Firefox doesn't make it a "success", as far as I'm concerned. Australis is bundled with Firefox, too, and it's almost universally hated.
  - nnethercote 12y ago
    One could argue that it was shipped in Firefox too early. But the performance and rendering quality/completeness has improved greatly since then. ("Initially flaky software improves over time" is a common story, albeit a boring one, and bad first impressions can be hard to shift.) I'm always happy when it fires up and saves me having to switch to an external PDF viewer.
  - ZenoArrow 12y ago
    I don't hate Australis, and I'd be surprised if that hatred is anywhere near universal, it's very Chrome-esque and people don't seem to have such a problem with that. What seems more likely is that you're hearing a vocal minority that hates it, I'd bet most people couldn't care less so long as it works.
  - gboss 12y ago
    Are your friends using late 2000s netbooks? I routinely open large PDFs (greater than 5mbs) with no problem. Firefox is very customizable if you don't like the Australis look you are free to change it. I use tree-style tabs personally. This comment is just unnecessary trolling.
ape4 12y ago
I donated some money to Mozilla this year. May you could too?
- exo762 12y ago
  Donated to Mozilla using Bitcoin. Feels good, man.
  - k__ 12y ago
    I "donated" to Mozilla using Code.
shmerl 12y ago
I hope Shumway will arrive before major shift to Wayland on the desktop. Daala is a very exciting project. The current mess of codecs support on the Web is just horrible.
- arianvanp 12y ago
  Why would the two be related? One is a replacement for Flash. the Other for X?
  - valarauca1 12y ago
    I think the user was just listing things they are excited for. Not drawing relationships between them.
  - evilpie 12y ago
    Maybe Adobe Flash doesn't work with pure Wayland, but needs X? So with Shumway you wouldn't need an X compositor (at least for Flash)
  - shmerl 12y ago
    Flash is dependent on GTK2 and for Wayland GTK3 is required. So ideally Firefox for Wayland shouldn't have any dependencies on GTK2 stuff (since mixing them together in one process isn't really a good idea, plus even if you manage to mix them somehow in separate processes GTK2 would still require X to function, so you'll have to fall back to XWayland in that case probably which is already not ideal). So Shumway can solve this (at least in context of Flash) replacing the Flash plugin altogether. For more details, see https://bugzilla.mozilla.org/show_bug.cgi?id=627699 https://bugzilla.mozilla.org/show_bug.cgi?id=627699
    - amaranth 12y ago
      Firefox already uses an external process to run Flash so leaving that on GTK2 while the browser uses GTK3 isn't an issue. The equivalent of XEmbed (to put the flash content in the page) in Wayland is writing a nested Wayland compositor which would be compatible with an XWayland window. Basically, Firefox itself can be a native Wayland app while still using the X11 dependent Flash player.
thomasfoster96 12y ago
I hadn't heard of about half of these - it's great that there's a sort of directory for them. Sweet.js is pretty awesome (I was going to say it's sweet, but that's stupid). Broadway.js and Shumway look pretty awesome, I'm going to check them out tonight. Regarding Parallel JavaScript, does anyone know how this relates to Khronos' WebCL project? Hardware manufacturers seem really interested in WebCL, but software developers aren't.
- derf_ 12y ago
  Unlike OpenGL, OpenCL allows writes to arbitrary addresses computed by the OpenCL kernel. To be safely run on the web, you have to solve a very difficult validation problem to prove that an arbitrary kernel won't do bad things. I don't think anyone has adequately solved that problem. As stated at <https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30> https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30>, "The future for GPU compute in Firefox is ARB_compute_shader, which is now part of ES 3.1."
  - thomasfoster96 12y ago
    Yep, I'd heard browsers wanted to use Shaders instead of WebCL. I think there's a couple of node packages that implement WebCL, but they're not in the browser environment and they're really only used with trusted code. Looking through some discussions on Google Groups related to chromium development, it looks like they thought WebCL might be safe to use eventually, but not in the near term.
tkubacki 12y ago
what about Mozilla Brick and WebComponents ?
- soapdog 12y ago
  WebComponents are based on a collection of proposed web standards that are still being implemented by browser vendors. Its not something by Mozilla. You can learn more about the current direction and updates regarding Web Components in this blog post https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ https://hacks.mozilla.org/2014/12/mozilla-and-web-components... As for Brick, it is mostly made by people from the Apps team and last time I checked it was going thru a rewrite to base it on platform.js instead of x-tags. You can check with someone from that team on #apps on irc.mozilla.org. Brick is not research, it is just a collection of Web Components.
  - tkubacki 12y ago
    Thanks for the link! I'm very happy to see Mozilla commitment for implementing Custom Elements and ShadowDOM and I hope IE and Safari will catch up some day.
  - ldng 12y ago
    So x-tags is getting phased out ? Unfortunately, Brick feels a bit lacking pitted against Polymer.
soapdog 12y ago
Also, if you folks enjoy these projects take your time (and money) to donate a some bucks to Mozilla. Mozilla is the only independent vendor pushing technology and principles focused on people over profit. You can find the donation page at https://sendto.mozilla.org/page/contribute/givenow-seq#page-1 https://sendto.mozilla.org/page/contribute/givenow-seq#page-...
- CmonDev 12y ago
  Nah, there is too much JS on their agenda. Locking web to legacy languages is not cool. Please do not donate.
  - RobinInTheRain 12y ago
    Despite the parent comment getting downmodded, I think it makes a valid point. Why don't we see a true plurality of programming languages supported within the browser? I'm talking about proper implementations, too. Not hacks that use something like Emscripten to mangle C code down to JavaScript (which is all that asm.js is, after all). NaCl and PNaCl are a much more general and sensible approach, rather than trying to contort JavaScript into a psuedo-bytecode. If Mozilla really does care about openness and freedom, then we'd see more emphasis being placed on languages other than JavaScript. But CmonDev is right, we just don't see that happening. We see a monoculture developing around JavaScript and only JavaScript. In general, monocultures of any type are an unhealthy thing, and lead to stagnation.
    - k__ 12y ago
      JavaScript is open and free. Also, with Rust, they are already developing another language. You might be right with the monoculture problem, but JS is a big thing with many developers, it would be dumb not to use this resource.
    - abnormalbrains 12y ago
      Do you think it's also worrying that we all communicate in English? Is the English language a stagnated monoculture? Pandering to language fanboys isn't a good idea. Javascript is a good enough language, and if you don't like it, write in something else and compile it to javascript.
k__ 12y ago
And they are using Github! I did some issues on Firefox, but stopped, because the Bugzilla/Mercurial workflow was so bad. I did some fixes for other OSS projects on Github later and it felt like a charm.
- tschneidereit 12y ago
  Full support for contributing to Firefox via git is coming: http://glandium.org/blog/?p=3413 http://glandium.org/blog/?p=3413
  - khuey 12y ago
    Doesn't mean we're going to use github.
    - k__ 12y ago
      well, if you would optimize of the patch-process (Creating PRs in Github is much faster than creating patches and uploading them to Bugzilla), it would lower the barrier.
      - tschneidereit 12y ago
        We're moving away from the attach-patches-to-bugs model, but in another direction: bugzilla integration with reviewboard, with changesets pushed to a review server and review requests being triggered automatically. See https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html https://mozilla-version-control-tools.readthedocs.org/en/lat... for details
        k__ 12y ago
        Sounds nice :) The old model felt rather clunky. I always had the impression that the coding was the easy part, getting the patch-creation right felt like a chore.
      - mccr8 12y ago
jamii 12y ago
LLJS is listed here but the last commit is over a year ago. Having spent the last month hand-coding arrays of structs in js, I'm really feeling the need for better low-level constructs. Looks like I'm stuck waiting for rust + emscripten to be a valid option.
- tschneidereit 12y ago
  Structs are coming to JS proper in the form of Typed Objects. For a whole load of details, check the spec draft (https://github.com/dslomov-chromium/typed-objects-es7 https://github.com/dslomov-chromium/typed-objects-es7) or this very readable paper: http://smallcultfollowing.com/babysteps/pubs/2014.04.01-TypedObjects.pdf http://smallcultfollowing.com/babysteps/pubs/2014.04.01-Type... Implementation of Typed Objects is progressing very nicely in Firefox; if you want to play around with them, just download a Nightly build.
  - jamii 12y ago
    Typed Objects are a huge step forwards but they still have some limitations. I frequently use things like: solverStates = { numVars: uint32 numConstraints: uint32 numStates: uint32 solverStates: solverState[numStates] } solverState = { los: uint32[numVars] his: uint32[numVars] constraintStates: *void[numConstraints] } Even using C, dealing with types like this is kind of a pain and would benefit from some macro magic. With Typed Objects it looks like I have to choose between variable sized arrays and pointers - I can't have both because then the gc won't know where to look for the pointers. According to http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects working with such types is an explicit non-goal: > In particular, binary formats often need expressive and dynamic data dependencies that are decidedly out of scope for this API, such as being able to specify an array whose length is determined by a preceding integer That's probably the right decision for js, given the constraints of sane gc implementation. It still looks like my best option is to use asm.js and have full control over layout. Either way, I am grateful that Mozilla continues to push for a fast, open and portable language. I don't have much love for js, but it's a damn sight better than trying to deliver portable native code to non-technical users.
bkeroack 12y ago
It's really fantastic to see Mozilla become a sort of steward and incubator of the open web. Considering that Mozilla originally came from a revolutionary (at the time) and somewhat desperate attempt by Netscape to counter the monopoly power of Microsoft/IE. If I'm remembering correctly, this was the first high profile corporate OSS dump (years before Java, for example) and shortly thereafter was largely considered a failure since Netscape became irrelevant and the Mozilla project didn't stop the MS juggernaut. Therefore it would be a number of years before a company was willing to take a risk like that again. Of course with hindsight we can see that the Mozilla folks played the long game. Quietly working in the background they produced a product (Firefox) that actually did largely kill IE dominance. You can argue the role that Chrome had in this, but my opinion is that Firefox created the market for non-IE browsers. Without this trailblazing Chrome would not exist. Congrats to everyone responsible, from the beginning to the present day.

440 points by yuashizuki 12y ago

mp3geek 12y ago

No pdf.js?

MegaDeKay 12y ago
"Following on the success of pdf.js, a high-fidelity PDF renderer written in pure HTML and JavaScript, the Shumway project..."
- pedalpete 12y ago
  but I thought Shumway was about converting flash to html, not pdf, or is it now pdf and flash?
  - ripdog 12y ago
    It is. pdf.js does pdf, shumway does flash. Read the linked page.
  - SwellJoe 12y ago
    Separate projects. But, pdf.js is integrated into Firefox and is past the research stage. I believe they're just sort of saying, "Hey, we made that other seemingly impossible idea work when we made pdf.js actually work pretty well, so you probably shouldn't laugh when we say we're implementing Flash in JS and HTML5."
  - dherman 12y ago
    (Director of Strategy for Mozilla Research here.) pdf.js was the brainchild of Andreas Gal, now our CTO but at the time a cofounder of Mozilla Research along with Brendan Eich and me. That project started briefly in Research but was shepherded to product pretty quickly. Shumway is a separate project but similar in spirit. It's not a converter per se, but rather an emulator including a full ActionScript Bytecode (ABC) JIT, implemented in pure JavaScript. Right now we are interested in getting Shumway to the point where it can be used in Firefox as an alternative to the native Flash plugin for certain kinds of web Flash content, to provide better security, stability, and performance. Over time as Shumway matures the ultimate goal would be to eliminate the need for the Flash plugin entirely, but we'll walk before we run. But Shumway is usable as a standalone project as well, and others have begun taking notice. For example, Prezi has invested in Shumway as a library for rendering vector graphics: https://medium.com/prezi-engineering/how-and-why-prezi-turned-to-javascript-56e0ca57d135 https://medium.com/prezi-engineering/how-and-why-prezi-turne...
- dfc 12y ago
  "...aims to implement an emulator for the Flash multimedia platform."
  - Mahn 12y ago
    The point is not that Shumway is directly connected with pdf.js, but rather that the wording in its descrition suggests pdf.js is no longer a research project.
dfc 12y ago
I think the take away is that pdf.js is no longer a mozilla research project. It has been included with Firefox since v19.
theandrewbailey 12y ago
It looks like that's a Mozilla Labs project, not a Mozilla Research project. https://mozillalabs.com/en-US/pdfjs/ https://mozillalabs.com/en-US/pdfjs/

ChrisAntaki 12y ago

Keep up the great work, Mozilla! I'm excited to see where a lot of these projects go, especially asm.js.

mindcrime 12y ago

Hmmm... would it make sense to talk about a JVM written in Rust? Could that make it easier to write a safe JVM that would be less susceptible to exploits? It would be wonderful if we could get there and have a Mozilla browser with "out of the box" Java support without needing a separate plugin.

Jweb_Guru 12y ago
Rust can't really make JIT compiled code substantially safer. JIT compilers are pretty much the unsafest things ever.
- deleted 12y ago
  [deleted]
- dbaupp 12y ago
  To be specific: Rust's memory safety guarantees only guarantee that the Rust code is free from memory safety violations, it can't make any sort of guarantees that the output of that code is sane. That said, maybe the other features like ADTs and explicit compile-time tracking of ownership make writing correct JITs (slightly) easier over plain C++, but that's yet to be seen (and it seems like it would be small in any case).
pjmlp 12y ago
There are already JVMs written in Java like JikesRVM, Graal/SubstrateVM and a few others. There is little that Rust safety could add over Java memory safety. There have been talks that Hotspot might eventually give place to Graal, but no plans were ever given.
MichaelGG 12y ago
Aren't most or nearly all of the Java exploits related to running sandboxed code? Instead of relying on a code security model, use containers or other external permission systems. For Microsoft, all the RCE were either use of C/++ or loading .Net into partially trusted scopes (like a browser). I think Rust would have perhaps fixed a few of the managed runtime vulnerabilities, but probably not the majority. Forget sandboxing and you're done.

bjz_ 12y ago

A neat thing about Shumway is just how much of it is written in Typescript[0]. It's great that Mozilla is getting behind the project. - [0]: https://github.com/mozilla/shumway/tree/master/src https://github.com/mozilla/shumway/tree/master/src

bobajeff 12y ago

So I take it this means that Mozilla is reopening "Mozilla Labs". It's interesting to see Shumway on there as I was under the impression the project was put on hold.

Jakuv2000 12y ago
I'm surprised that pdf.js is described as a "success". I don't think I've ever heard a user of it say anything good about it. Any time I have heard about it, it's always somebody else in the office cursing loudly about it taking forever to open a PDF, or that it locked up Firefox, or that it's rendering something improperly, or that they wanted Foxit Reader or some other app to open the PDF instead of Firefox. Just because it's integrated with Firefox doesn't make it a "success", as far as I'm concerned. Australis is bundled with Firefox, too, and it's almost universally hated.
- nnethercote 12y ago
  One could argue that it was shipped in Firefox too early. But the performance and rendering quality/completeness has improved greatly since then. ("Initially flaky software improves over time" is a common story, albeit a boring one, and bad first impressions can be hard to shift.) I'm always happy when it fires up and saves me having to switch to an external PDF viewer.
- ZenoArrow 12y ago
  I don't hate Australis, and I'd be surprised if that hatred is anywhere near universal, it's very Chrome-esque and people don't seem to have such a problem with that. What seems more likely is that you're hearing a vocal minority that hates it, I'd bet most people couldn't care less so long as it works.
- gboss 12y ago
  Are your friends using late 2000s netbooks? I routinely open large PDFs (greater than 5mbs) with no problem. Firefox is very customizable if you don't like the Australis look you are free to change it. I use tree-style tabs personally. This comment is just unnecessary trolling.

ape4 12y ago

I donated some money to Mozilla this year. May you could too?

exo762 12y ago
Donated to Mozilla using Bitcoin. Feels good, man.
- k__ 12y ago
  I "donated" to Mozilla using Code.

shmerl 12y ago

I hope Shumway will arrive before major shift to Wayland on the desktop. Daala is a very exciting project. The current mess of codecs support on the Web is just horrible.

arianvanp 12y ago
Why would the two be related? One is a replacement for Flash. the Other for X?
- valarauca1 12y ago
  I think the user was just listing things they are excited for. Not drawing relationships between them.
- evilpie 12y ago
  Maybe Adobe Flash doesn't work with pure Wayland, but needs X? So with Shumway you wouldn't need an X compositor (at least for Flash)
- shmerl 12y ago
  Flash is dependent on GTK2 and for Wayland GTK3 is required. So ideally Firefox for Wayland shouldn't have any dependencies on GTK2 stuff (since mixing them together in one process isn't really a good idea, plus even if you manage to mix them somehow in separate processes GTK2 would still require X to function, so you'll have to fall back to XWayland in that case probably which is already not ideal). So Shumway can solve this (at least in context of Flash) replacing the Flash plugin altogether. For more details, see https://bugzilla.mozilla.org/show_bug.cgi?id=627699 https://bugzilla.mozilla.org/show_bug.cgi?id=627699
  - amaranth 12y ago
    Firefox already uses an external process to run Flash so leaving that on GTK2 while the browser uses GTK3 isn't an issue. The equivalent of XEmbed (to put the flash content in the page) in Wayland is writing a nested Wayland compositor which would be compatible with an XWayland window. Basically, Firefox itself can be a native Wayland app while still using the X11 dependent Flash player.

thomasfoster96 12y ago

I hadn't heard of about half of these - it's great that there's a sort of directory for them. Sweet.js is pretty awesome (I was going to say it's sweet, but that's stupid). Broadway.js and Shumway look pretty awesome, I'm going to check them out tonight. Regarding Parallel JavaScript, does anyone know how this relates to Khronos' WebCL project? Hardware manufacturers seem really interested in WebCL, but software developers aren't.

derf_ 12y ago
Unlike OpenGL, OpenCL allows writes to arbitrary addresses computed by the OpenCL kernel. To be safely run on the web, you have to solve a very difficult validation problem to prove that an arbitrary kernel won't do bad things. I don't think anyone has adequately solved that problem. As stated at <https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30> https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30>, "The future for GPU compute in Firefox is ARB_compute_shader, which is now part of ES 3.1."
- thomasfoster96 12y ago
  Yep, I'd heard browsers wanted to use Shaders instead of WebCL. I think there's a couple of node packages that implement WebCL, but they're not in the browser environment and they're really only used with trusted code. Looking through some discussions on Google Groups related to chromium development, it looks like they thought WebCL might be safe to use eventually, but not in the near term.

tkubacki 12y ago

what about Mozilla Brick and WebComponents ?

soapdog 12y ago
WebComponents are based on a collection of proposed web standards that are still being implemented by browser vendors. Its not something by Mozilla. You can learn more about the current direction and updates regarding Web Components in this blog post https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ https://hacks.mozilla.org/2014/12/mozilla-and-web-components... As for Brick, it is mostly made by people from the Apps team and last time I checked it was going thru a rewrite to base it on platform.js instead of x-tags. You can check with someone from that team on #apps on irc.mozilla.org. Brick is not research, it is just a collection of Web Components.
- tkubacki 12y ago
  Thanks for the link! I'm very happy to see Mozilla commitment for implementing Custom Elements and ShadowDOM and I hope IE and Safari will catch up some day.
- ldng 12y ago
  So x-tags is getting phased out ? Unfortunately, Brick feels a bit lacking pitted against Polymer.

soapdog 12y ago

Also, if you folks enjoy these projects take your time (and money) to donate a some bucks to Mozilla. Mozilla is the only independent vendor pushing technology and principles focused on people over profit. You can find the donation page at https://sendto.mozilla.org/page/contribute/givenow-seq#page-1 https://sendto.mozilla.org/page/contribute/givenow-seq#page-...

CmonDev 12y ago
Nah, there is too much JS on their agenda. Locking web to legacy languages is not cool. Please do not donate.
- RobinInTheRain 12y ago
  Despite the parent comment getting downmodded, I think it makes a valid point. Why don't we see a true plurality of programming languages supported within the browser? I'm talking about proper implementations, too. Not hacks that use something like Emscripten to mangle C code down to JavaScript (which is all that asm.js is, after all). NaCl and PNaCl are a much more general and sensible approach, rather than trying to contort JavaScript into a psuedo-bytecode. If Mozilla really does care about openness and freedom, then we'd see more emphasis being placed on languages other than JavaScript. But CmonDev is right, we just don't see that happening. We see a monoculture developing around JavaScript and only JavaScript. In general, monocultures of any type are an unhealthy thing, and lead to stagnation.
  - k__ 12y ago
    JavaScript is open and free. Also, with Rust, they are already developing another language. You might be right with the monoculture problem, but JS is a big thing with many developers, it would be dumb not to use this resource.
  - abnormalbrains 12y ago
    Do you think it's also worrying that we all communicate in English? Is the English language a stagnated monoculture? Pandering to language fanboys isn't a good idea. Javascript is a good enough language, and if you don't like it, write in something else and compile it to javascript.

k__ 12y ago

And they are using Github! I did some issues on Firefox, but stopped, because the Bugzilla/Mercurial workflow was so bad. I did some fixes for other OSS projects on Github later and it felt like a charm.

tschneidereit 12y ago
Full support for contributing to Firefox via git is coming: http://glandium.org/blog/?p=3413 http://glandium.org/blog/?p=3413
- khuey 12y ago
  Doesn't mean we're going to use github.
  - k__ 12y ago
    well, if you would optimize of the patch-process (Creating PRs in Github is much faster than creating patches and uploading them to Bugzilla), it would lower the barrier.
    - tschneidereit 12y ago
      We're moving away from the attach-patches-to-bugs model, but in another direction: bugzilla integration with reviewboard, with changesets pushed to a review server and review requests being triggered automatically. See https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview.html https://mozilla-version-control-tools.readthedocs.org/en/lat... for details
      - k__ 12y ago
        Sounds nice :) The old model felt rather clunky. I always had the impression that the coding was the easy part, getting the patch-creation right felt like a chore.
    - mccr8 12y ago

jamii 12y ago

LLJS is listed here but the last commit is over a year ago. Having spent the last month hand-coding arrays of structs in js, I'm really feeling the need for better low-level constructs. Looks like I'm stuck waiting for rust + emscripten to be a valid option.

tschneidereit 12y ago
Structs are coming to JS proper in the form of Typed Objects. For a whole load of details, check the spec draft (https://github.com/dslomov-chromium/typed-objects-es7 https://github.com/dslomov-chromium/typed-objects-es7) or this very readable paper: http://smallcultfollowing.com/babysteps/pubs/2014.04.01-TypedObjects.pdf http://smallcultfollowing.com/babysteps/pubs/2014.04.01-Type... Implementation of Typed Objects is progressing very nicely in Firefox; if you want to play around with them, just download a Nightly build.
- jamii 12y ago
  Typed Objects are a huge step forwards but they still have some limitations. I frequently use things like: solverStates = { numVars: uint32 numConstraints: uint32 numStates: uint32 solverStates: solverState[numStates] } solverState = { los: uint32[numVars] his: uint32[numVars] constraintStates: *void[numConstraints] } Even using C, dealing with types like this is kind of a pain and would benefit from some macro magic. With Typed Objects it looks like I have to choose between variable sized arrays and pointers - I can't have both because then the gc won't know where to look for the pointers. According to http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects working with such types is an explicit non-goal: > In particular, binary formats often need expressive and dynamic data dependencies that are decidedly out of scope for this API, such as being able to specify an array whose length is determined by a preceding integer That's probably the right decision for js, given the constraints of sane gc implementation. It still looks like my best option is to use asm.js and have full control over layout. Either way, I am grateful that Mozilla continues to push for a fast, open and portable language. I don't have much love for js, but it's a damn sight better than trying to deliver portable native code to non-technical users.

bkeroack 12y ago

It's really fantastic to see Mozilla become a sort of steward and incubator of the open web. Considering that Mozilla originally came from a revolutionary (at the time) and somewhat desperate attempt by Netscape to counter the monopoly power of Microsoft/IE. If I'm remembering correctly, this was the first high profile corporate OSS dump (years before Java, for example) and shortly thereafter was largely considered a failure since Netscape became irrelevant and the Mozilla project didn't stop the MS juggernaut. Therefore it would be a number of years before a company was willing to take a risk like that again. Of course with hindsight we can see that the Mozilla folks played the long game. Quietly working in the background they produced a product (Firefox) that actually did largely kill IE dominance. You can argue the role that Chrome had in this, but my opinion is that Firefox created the market for non-IE browsers. Without this trailblazing Chrome would not exist. Congrats to everyone responsible, from the beginning to the present day.