
Mozilla Chromeless 0.2 - abraham
http://mozillalabs.com/chromeless/2011/04/29/chromeless-0-2/
======
yan
Seeing so much awesome stuff out of the Mozilla team yet again makes me
thankful for such an active browser ecosystem.

------
rubergly
Am I the only one who thought this was some attack on Chrome? Whenever I hear
talk about browser chrome I always think that Google's name choice was a
little confusing. Probably best in the end, though, since it's a catchy name.

~~~
code_duck
Google seems to be making a habit of that... Closure and Noop are two other
examples that come to mind.

~~~
Hovertruck
Dont' forget "Go"

~~~
nddrylliog
Actually, do forget it.

------
euroclydon
I can't tell if this is an alternative to something like QtWebKit. There
doesn't seem to be any emphases on native code integration.

~~~
leoc
> There doesn't seem to be any emphases on native code integration.

Mozilla's actively opposed to any form of JS/native code integration,
undoubtedly because that would dilute the effective proprietary control over
the Web platform that it shares with a small group of fellow browser vendors.
(And maybe because it would wound the personal vanity of its senior
developers.) It's already briefing friendly journalists against Google NaCl
[http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermon...](http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermonkey_javascript_engine_extension/)
[http://www.theregister.co.uk/2011/02/18/google_releases_firs...](http://www.theregister.co.uk/2011/02/18/google_releases_first_native_client_sdk/)
, using comically disingenuous arguments: oh, it's just _too bad_ that NaCl
hasn't been blessed by the web standards process that we ourselves control!
Opera is behaving similarly:
[http://www.theregister.co.uk/2010/10/01/opera_on_google_nati...](http://www.theregister.co.uk/2010/10/01/opera_on_google_native_client/)
.

Of course, it's another thing to extend this attitude to the desktop, where
developers have plenty of alternatives to drinking the JS kool-aid. But
presumably Mozilla is hoping that the accelerated-Javascript/"contemporary
HTML" juggernaut will be powerful enough to sweep a good number of desktop
developers along anyhow. Next Big Language and all that, after all.

~~~
quanticle
How is Mozilla's control over the W3C HTML standards process proprietary in
any way? Mozilla is only one of a number of vendors on the W3C, and is
certainly not the most powerful of those vendors.

~~~
leoc
I didn't suggest that Mozilla has sole control over the HTML (etc.) standards.
It's one of the five browser vendors who collectively have _de facto_ control
over the Web platform, and it's one of the four non-MS browser vendors who
collectively have _de facto_ control over "open Web standards". Thus, for
instance, the reason that Google Native Client is not set fair to become an
"open Web standard" is because three of the four non-MS vendors oppose it for
reasons of self-interest. Similarly, it's going to have trouble getting real-
world adoption because MS opposes it too, for basically the same reasons.
You'll note how the desires or interests of other actors, like the non-
browser-vendor W3C members or Web users and developers at large, play no role
in the calculation.

~~~
tiles
> The reason that Google Native Client is not set fair to become an "open Web
> standard" is because three of the four non-MS vendors oppose it for reasons
> of self-interest.

As a user, I don't want to see NaCl's compile-once-per-each-architecture model
become part of the web. It's true browsers oppose it out of self interest, but
NaCl has its own problems that haven't been solved.

PNaCl is a good start and much more in the vein of an open web that isn't tied
to a particular platform. And whatever benefits an Open Web, Mozilla will
inevitably support, as it sustains their business model. NaCl doesn't do
anything for browser makers, but it also doesn't help me as a user.

~~~
leoc
So what remaining problems with NaCl's compile-once-per-each-architecture
model do you believe can't be solved by the combination of multi-architecture
compilers (llvm, gcc ...) on the developer/server end and PNaCl on the client?
Obviously the implementation is incomplete and immature, but Mozilla and Opera
aren't even pretending that their opposition to NaCl is based on the
immaturity of the implementation.

> And whatever benefits an Open Web, Mozilla will inevitably support, as it
> sustains their business model.

Mozilla inevitably supports and benefits from an Open Web only to the extent
that you accept Mozilla's rather Newspeak definition of the Open Web as "a Web
whose client API and runtime is under the shared control of a small group of
browser vendors". If you have a less Orwellian kind of openness in mind, then
it's clearly not true: Mozilla benefits from its shared control over the Web
platform in largely the same way that MS benefits from its control over the
Windows platform, and just like MS it has a strong self-interest in not seeing
its platform "commoditised". As if that weren't perfectly clear already, then
Chromeless underlines it. I assume you accept that Mozilla has a self-interest
in seeing Chromeless succeed? The reason that Chromeless has a chance of
hitting the big-time on the desktop is almost solely because Javascript and
friends are popular on the Web client, and the ultimate reason for _that_ is
because JS and friends are bolted in and difficult to avoid on the web client.

~~~
bzbarsky
Well, for a start there's the problem that LLVM itself is architecture-
dependent, last I checked. It's not as arhictecture-dependent as assembly but
the last time I looked you couldn't generate the same LLVM on x86 and x86-64,
say. Has that changed?

It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted
LLVM... including 32-bit pointer alignment. It's not immediately obvious how
portable this would be to some hardware, and more importantly I'm not aware of
any plans to support anything other than x86 and ARM initially (well, and
x86-64 using its ability to run 32-bit code as far as I can tell). Am I just
missing something on this front?

If I'm not missing anything, then this project's main impact if it caught on
would be to restrict the set of hardware on which you can access web content,
which is NOT a good thing.

~~~
daeken
> Well, for a start there's the problem that LLVM itself is architecture-
> dependent, last I checked. It's not as arhictecture-dependent as assembly
> but the last time I looked you couldn't generate the same LLVM on x86 and
> x86-64, say. Has that changed?

LLVM bytecode is 100% architecture and platform independent, unless you call
into platform-specific bits or into blobs of machine code.

~~~
bzbarsky
OK, so in that case what <http://llvm.org/docs/FAQ.html#platformindependent>
is telling me is that it's not possible to produce said LLVM bytecode from C
or C++ code in general, right?

And if I read <http://llvm.org/docs/LangRef.html> correctly, some bitcode is
"not supported by all targets". How is that reconciled with "100% platform and
architecture independent"?

~~~
daeken
Hmm, you're quite right. A better way of putting this would be: a large subset
of LLVM IR is platform independent, but not all. My mistake.

------
johkra
Looks like the decision to stop development of Mozilla Prism was not a bad
one. "appify" looks very interesting.

~~~
kleiba
Why was Prism stopped? Does anyone know?

~~~
johkra
You can read the announcement here:
[https://mozillalabs.com/blog/2011/02/prism-is-now-
chromeless...](https://mozillalabs.com/blog/2011/02/prism-is-now-chromeless/)

Basically: Both can solve the same problem, but Chromeless is more powerful.

------
latortuga
How is this different from xulrunner? In reading the description it sounds
like a way to make a webapp behave like a desktop app but it's a little
unclear.

~~~
quanticle
Chromeless requires you to write your apps in HTML5/Javascript, whereas
XULRunner requires you to write your apps in XUL/Javascript. Given that HTML5
is a much more widely known standard than XUL, I'm glad that Mozilla is
pushing forward with Chromeless and relegating XULRunner.

Ideally, Chromeless would allow you to take your webapp and (with minor
modifications) turn it into a desktop app or vice versa.

------
jimmyjazz14
I like the idea of being able to do some parts of a desktop application with
HTML but would really prefer not to have to use Javascript. Does anyone know
of anything similar to this but that can be manipulated with another language.

~~~
skymt
Microsoft's WPF [0] will probably get you the best results on Windows. It's
intended to be an easy transition for web programmers to native GUI
programming, so it uses an XML-based markup language called XAML for layout.

If you want real HTML, you'll need to work out how to interact with your page
from your non-JavaScript code. Two easy ways to do that: plugins and
compilers.

IronPython allows you to embed Python in HTML [1] just like you would
JavaScript. (A small Silverlight applet does the real work.) I haven't used
this myself, so I can't vouch for how well it works in practice.

You can also write code in a language that compiles to JavaScript. [2]
CoffeeScript is a popular choice, but there are quite a few others, including
several compilers each for Python and Ruby. Some caveats:

* This can have performance implications if the compiler produces poorly-optimized JavaScript or compiles on the fly in the browser.

* Many of these compilers are toys, so make sure whatever you pick has seen real-world use.

* You still need to deal with JavaScript when you debug.

[0]: <http://msdn.microsoft.com/en-us/library/aa970268.aspx>

[1]: <http://ironpython.net/browser/>

[2]: [https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)

~~~
jimmyjazz14
Yeah I was kinda thinking of HTML applications that are not intended to be
used in the browser.

~~~
skymt
You could use any of the tools I mentioned outside the browser, the latter two
(plugins and JavaScript-targeting compilers) with something like Chromeless or
Adobe Air. The whole idea of those is to remove browser chrome but leave the
engine, keeping development mostly the same. Anything you can do to script
without JavaScript in the browser will work just as well in these non-browser
environments.

------
ww520
This looks promising. Are there supports for native file system access,
databases (SQLite?), and network access?

~~~
lloydhilaiel
file system access, yeah! It should feel like node.js (on purpose):
[http://mozilla.github.com/chromeless/#guide/filesystem-
acces...](http://mozilla.github.com/chromeless/#guide/filesystem-access)

databases, IndexedDB should "just work", and thinking exposing SQLlite is
worthwhile.

only the most basic network libraries at the moment.

~~~
jorangreef
Would it be possible to use Chromeless to tell the operating system to have a
specific file opened by its default native application? So you could have a
collection of links in a Chromeless app, that represent files on the user's
computer, and the user could click a link for say an Excel file, and Excel
would launch and show the file? Ideally this is what the new FileSystemApi
needs, so that a web-based "dropbox" becomes possible. At the moment, any kind
of web-based file manager must result in downloads to get most files opened,
and re-uploads, whenever the user changes the file.

------
glenjamin
Their documentation system seems to be pretty cool. Does anyone know if this
is spun off as a separate project somewhere? It looks pretty and seems to tie
API functions straight to the equivalent github page - sounds like it would be
pretty useful in lots of places.

~~~
lloydhilaiel
it's homegrown. I spun off the docstract project which pulls docs outta .js
and outputs them in json. From their you can render the docs however you want.
Docstract itself is permissive open source you can use, here:

<https://github.com/lloyd/docstract>

------
Plugawy
Wow, it's pretty much the same as Titanium Desktop.

(yes - I remember XULRunner and Adobe AIR - but the first didn't have any
usable documentation, and the later is just Flash with webkit web view +
AS<->JS bridge)

------
mgutz
Where's the tutorial? Github pages for tutorial not doing anything. I'm very
interested as this seems to allow more features than a Chrome Packaged
Application desktop app.

------
StuffMaster
I'd still like Prism to live on...it allows the _user_ to turn any website
into an application.

~~~
asadotzler
This feature is already beginning in Firefox 4 with App Tabs and will continue
grow into the Prism-like platform without the need for a separate product. You
should just be able to tell Firefox, "make this site an app" and not have to
download Prism to get that.

~~~
StuffMaster
I want it to run in a separate process and minimize to the system tray
though...:(

------
jamesbritt
Nice. Looks like an update on Microsoft's HTA (HTML Applications).

------
nrbafna
any sample applications to showcase?

~~~
lloydhilaiel
totally. check out webian: <https://github.com/webianproject/shell>

------
ignifero
So is this like PhoneGap for desktops? it was about time

~~~
IanDrake
Actually, check out Adobe Air (for ajax developers). Basically it's webkit as
a desktop app and pretty mature.

I've used it in the past, but I think Mozilla has a big opportunity here as
Adobe has pretty much abandoned the web desktop aspect of AIR to focus on
flash/flex for mobile.

Also, Adobe removes some of the best parts of webkit like web workers and I
recently found a giant performance bug in their javascript engine that only
exists in AIR.

~~~
bni
Does Air still require a shared runtime component to be installed beforehand?
We all know how well that worked with Java.

~~~
IanDrake
You can now build MSIs for Windows and DMGs for Macs with AIR that will
bootstrap the runtime. That said, I haven't used that option.

Up until Craig's lawyers killed my app, I was using the flash installer that
was seamless. Same sort of installation process can be seen on TweetDeck which
uses AIR.

------
drivingmenuts
The recent Amazon outage, in which actual data was lost, would seem to make a
case for NOT using this.

~~~
elliottcarlson
This has nothing to do with "the cloud", hosted content or anything -
Chromless is an application launcher allowing applications to launch utilizing
the Firefox engine - think of it as an Adobe AIR type product.

~~~
drivingmenuts
OK, fair enough. And where are those applications hosted? If it's local to the
machine, then great. If it's it's out in "the cloud", then the reliability for
applications, which may have been purchased, is iffy at best.

