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.
Yeah, I was annoyed with Google when they announced Chrome because I thought it would cause some confusing collisions for the technical crowd down the road. I really would have liked to see them choose a different name for their browser. The interface and trappings of the browser has long been called "chrome" by Mozilla, so if you see chrome given in a non-proper-noun context then it probably refers to that, not Google's competing browser.
The lead frontend engineer on Chrome was previously the lead frontend engineer on Firefox, and many other people on the team worked on browsers forever - we all knew what 'chrome' meant in a technical context long before we called it that.
But we still liked 'Chrome' more than the other names, and our motto is "content, not Chrome", which neatly works with either capitalization.
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.
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.
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.
> 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.
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.
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.
> Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked.
The idea is not to produce a single cross-platform binary using LLVM - let alone using GCC! - but to produce a set of NaCl binaries for common archs from your portable HLL code using a cross-platform compiler - like LLVM, or GCC - plus PNaCl (or whatever) as the wildcard. Content negotiation is your friend.
> 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,
shrug I haven't heard of any major problems in converting LLVM IR to decently-performing assembler in various archs, so I presume that PNaCl will be able to do okay, especially since the bar is not set very high: consistently world-beating performance is not a necessity in a backstop solution. And if you're on a new or obscure platform (or, er, IE/Windows/x86-64) you're not guaranteed the swiftest Javascript speeds either. The likely worst is that PNaCl will need a redesign: see below.
> 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?
As I said in my previous post "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." Seriously, if the problem with NaCl is that it's not mature and widely ported enough yet, then there's an obvious solution to that.
> I haven't heard of any major problems in converting LLVM IR to decently-performing assembler
But normally when you create LLVM IR you can choose what your pointer-size representation is, as I understand. Again, I could be completely off base here; I've just read some of the docs and talked to people who have worked with LLVM, not worked with it myself. Please tell me if I'm wrong!
The problem with PNaCl is not that it's not widely ported enough "yet", but rather that there are no plans for a way to run it on platforms what PNaCl hasn't been ported to. Compare this to JS, where you can get JS working on a new platform in fairly short order (e.g. by just compiling Spidermonkey, which is largely fairly portable C code and has a platform-independent interpreter). Now your new platform won't have a JIT yet at that point, so performance may not be great, but at least you'll have a fighting chance at using the web. You won't have that without a pretty large porting job if NaCl is in wide use.
> 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.
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"?
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.
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.
I'm not too familiar with what xulrunner does, but this looks like it is very close to Air. Define a desktop application with html & js, but then have lots of additional hooks to make it a desktop app, playing nice w/ the environment.
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.
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.
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.
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.
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.
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:
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)
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.
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.
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.
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.
Yes, but the install is relatively seamless (as long as you already have Flash installed) and only needs to be done once. The AIR update process (for both the runtime and the applications) is also pretty seamless as well.
yes, but if im stil up to date on that, it has its own gui frameworks that your app is tied to forever. Might aswell write the app in Cocoa or Win32 then.
Correct me if Im wrong, can you deploy your client side web app as a desktop application without using the Titanium framework stuff?
I believe you're correct about the framework. I think Titanium apps are packaged with the framework statically "linked", instead of installed separately.
The Titanium mobile API is basically JS bindings for Cocoa, but the desktop API is mostly OS agnostic.
In my opinion, Titanium was smart to make one version for mobile and one for desktops. Adobe should have done the same.
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.
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.
