I am sure after WebAssembly Post-MVP, asm.js will be deprecated. Even now, a few existing asm.js projects already start to use WebAssembly. JS engine (V8) also starts to comiple asm.js to WebAssembly, so even if old projects never migrate, end-users will still get partial advantages from WebAssembly.
My question is, what about native-client then? It is not implemented in JS engine so that can be a problem. Native-client seems to be deprecated even now. Will native-client be completely removed from Chrome in foreseeable future? I would love to see some reduction in binary size of Chrome.
Side questions:
After thread/gc/simd/exception are included in WebAssembly, is there still something native-client has but missing in WebAssembly (blocking migration)?
It took WebAssembly about 2 years just to reach MVP, what is the expected time for any one of the Post-MVP to get finalized?
It seems like WebAssembly group is tackling multiple Post-MVP features at once instead of one by one, won't that make it slower to finalize one of them?
Answering the side-questions only, because I no longer work on Native Client. Google's plans are its own to speak for, so I'll make this a wiki.
Update as of 2017/05/20 NaCl isn't in glibc. This was the original libc which was supported, and took quite a while to clean up and upstream. It was only ever supported by NaCl's GCC toolchain. There's still support for musl libc, which works with the more up-to-date LLVM-based NaCl and PNaCl toolchain.
Update as of 2017/05/30 the Chromium team announced the fate of PNaCl and tentative roadmap of WebAssembly features.
Here are some Native Client features which you haven't mentioned:
Out-of-process, which many consider a bug because it forces asynchronous communication. It allows guaranteed address space, which with 64-bit isn't much of an upside, and was critical to Native Client's double-sandbox design. WebAssembly doesn't have processes yet.
Has blocking to and from the JavaScript event loop, through postMessageAndAwaitResponse. Also seen as a bug by many.
Has many APIs through Pepper. Many mirror the web platform's APIs.
Can do memory protection through mprotect (though execute pages are limited).
POSIX signals can be handled.
Supports computed goto and other irreducible control flow.
Has some Just-in-Time code patching support.
Supports weaker than seq_cst atomics.
Has support for inline assembly, as long as it follows the NaCl validation rules.
Not all of these are in Portable Native Client, though. There's official documentation of differences.
There's no timeline for any of the post-MVP WebAssembly features. We don't want to rush anything, but we want to deliver one the most useful things first. It's a community group, so priorities are really driven by whoever gets involved. Implementations won't be able to tackle features all at once, but exploration parallelizes well.
SonarSource has said that they would be dropping support for Ruby on Rails. So assuming that we would need to use Web APIs from here onwards, what are alternate ways of writing your widgets? Has anyone tried any alternate ways of writing one? And how do you link said widget to the UI?
Short answer:
In upcoming versions of SonarQube, widgets and customizable dashboards will be progressively be removed. You will still be able to use the Web APIs to get all the data you want but you won't be able to contribute changes to the "dashboards" of the product.
Long answer:
SonarQube was initially designed to be able to inject and display any kind of information, mostly thanks to the customizable dashboards and widgets (that are indeed written in Ruby). While this helped getting widespread, the downside is that people started using it as a multi-purpose aggregator and reporting tool. One would add information coming from a bug tracker system, another one would add documentation information about projects, ...etc. The consequence is that soon, the global and project dashboards ended up being full of useless and useful information, everything mixed up together in a big mess.
So something had to be done to get back to what SonarQube is meant for: managing source code quality. Every information that can't be precisely linked to a source file should not end in SonarQube. Having said this, it becomes obvious that having a mechanism to define custom dashboards and widgets is just too generic. The web application must provide features that answer precise needs for a precise audience. This is why customizable global and project dashboards are progressively replaced by "hard-coded" pages which answer those use cases. This started with the new project home page introduced in the 5.x series of SonarQube and available in the latest 5.6 LTS. And we'll do the same with global dashboards in the 6.x series.
Now that TideSDK is effectively dead, I've been looking into alternative 'wrappers' to run HTML/CSS/JS applications as stand-alone desktop applications. The three viable options I have run across so far, are NW.js (formerly node-webkit), brackets-shell, and Electron (formerly atom-shell).
The problem is that there does not appear to be a sufficiently complete comparison between the three in terms of feature set, compatibility, etc. I'm hoping to turn this into a more-or-less canonical thread on the (objective) differences between the three, in particular regarding:
Platform support; operating systems, dependencies, etc.
Language feature support, as far as HTML5, CSS3 and JavaScript are concerned. Think things like "does HTML5 video work, and if yes, what codecs are available?"
Non-standard extra features, such as tray icons, popup notifications, and OS-rendered menu bars.
Extensibility; eg. ability to 'plug in' native code, talk to Node.js, and so on.
Architecture; in particular the architectural differences that affect daily usage as a developer.
Debugging; included development tools, compatibility with commonly used tools like node-inspector, etc.
... and so on.
What are the objective, technical differences that matter when making a choice between them as an application developer?
I did similar research about two months ago, and in the end I went with node-webkit. The biggest upside on node-webkit is node.js and npm. The package management of npm is really nice, and node has well done filesystem access.
Brackets-shell looked interesting, but other than a nice IDE I didn't really get what made this one as good or better than the rest. They are very clear that "The brackets-shell is only maintained for use by the Brackets project ", that screams run away to me.
https://github.com/adobe/brackets-shell#overview
Atom-shell seems to be recently active, but it seems much like brackets in that they are really writing and editor/IDE that just happens to be attached to a webkit runtime. It also is built on top of node.js. This one has the downside of being difficult to search for stuff online without being reminded of your middle school chemistry.
I really don't want an new editor, and most programmers have their favorite already. For the actual application development, they pretty much work the same, and should, since they all use webkit. You basically write 90-95% of it like a website, and then deal with the native parts, and some config.
These things are true for all three of them
platforms - runs on Windows, Mac, and Linux
language support - HTML5, CSS3 and Javascript : since they run javascript you can download and run nearly any library/framework that you want.
The big caveat on webkit is codec support. Typically you will have problems with non-free video codecs, unless you rebuild the dll/so to support them. For example the shipped node-webkit won't play mp4 video.
I've been playing with Atom-Shell over the last few days, and I am loving it so far.
The best part about it is that it's backed by GitHub.. which should allow you to settle into the platform for the long term, especially if it gains a large following. It's also made possible by direct Node.js improvements courtesy of a contract with StrongLoop, who is a major Node.js contributor (they claim to employ more Node.js core developers than any other company, even Joyent).
I've also found it rather comfortable to get started. It took me about a day to learn the structure and get my first proof of concept running. Very cool.
Bullet Points:
Platform support: Windows, Linux, Mac OSX (More Info Here)
Language feature support: HTML5, CSS3, JS via Chromium - so far, zero issues, but I have not tested video specifically.
Native Features: Native App Menus, Task Tray Support, Global Hotkeys, Protocol Handler Support (that I've seen so far)
Extensibility: Excellent Node.js integration, both the client and server can "require" Node.js modules and natives. I've also successfully tested Bower libraries (incl jQuery) without issue.
Architecture: Covered in the other points, but in general its very smooth.
Update (11/25/14): I've not yet found use case for Atom-Shell in any official capacity, but I have used it to build a few small apps for my own use, the most complex being an app that pulls my time logs from my PM software and creates Paypal invoices.
My opinion of the platform remains positive. It's pretty awesome.
On my time invoicing app I successfully brought in Bootstrap 3's Dashboard Example Template and a few node modules (bluebird, Paypal SDK, Teamwork PM Client) to create a mildly complex app. It took me a few days and does its job well.
I really cannot think of anything negative to say about Atom-Shell, its solid, stable, fast, and easy to code for. I hope this helps someone.
Besides fully support Web standards, NW.js supports a list of non-standard features for native app development including:
Protect JS source code by compiling them into machine code: https://github.com/nwjs/nw.js/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Jailed devtools: https://github.com/nwjs/nw.js/wiki/Devtools-jail-feature
Additional security model with which you can do more in DOM: https://github.com/nwjs/nw.js/wiki/Security https://github.com/nwjs/nw.js/wiki/Changes-to-DOM
enhanced file dialog: https://github.com/nwjs/nw.js/wiki/File-dialogs
kiosk mode: https://github.com/nwjs/nw.js/wiki/The-Kiosk-mode
supports for a growing list of chrome.* API, include chrome.webRequest so you can intercept HTTP requests from DOM: https://github.com/nwjs/nw.js/issues/518
support for rich notifications, print preview, many more chrome.* APIs, Chrome Apps and other Chromium features starting from 0.13.0-alpha0
There is much more to see in the wiki including Menu, Tray, etc.
I've been working with brackets-shell for some time now, here are some of my findings:
brackets-shell is primarily developed as a shell under the brackets IDE project, but the project can run any web application. You just need to point it to your own html page. Clint Berry wrote an excellent tutorial about doing just this: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/
The project is backed by Adobe and has a lot of activity
Documentation could be better
platform support They support Windows, Mac and Linux. An installer package can also be created. I only tested it on Win and Mac, it works great.
feature support html5, css3, js. Html5 video does not work out of the box, but is very easy to enable (by default the ffmpegsumo.dll is not copied into the installer, if you change the script to copy it it will work).
native features menu bar, 'open file with', file system access. I am not using any of these, as all I need is the communication with the node process.
extensibility a nodejs is built in, and you can communicate with node from your web application. In this way, you can use node to access the filesystem etc.
architecture The project is well set up, keeping a nice separation between the shell project and your own web app running inside it. In your own application, a global appshell object is available which gives you access to the brackets functionality (filesystem access, communication with node process, ...).
One thing to note (if you care), is that the Electron officially does not support Windows Vista. Vista's market share is about halfway between OSX 10.9 and 10.10 (both of which are fully supported by Electron). Vista is also still supported by Microsoft until 2017.
NW.js works fine in Vista, as well as OSX 10.9+. NW.js works on Ubuntu, Debian, Zorin, Manjaro, Arch, and most other Debian based Linux OS's. Electron has refused PR's to fix Ubuntu specific bugs on their platform which is concerning.
NW.js works in XP too. Currently 18% of the market is still on XP. So if you're desktop application is more general purpose or wants to have access to the late adopters still on XP, you're probably better off with NW.js (0.14.7) as Electron only supports Win 7 and up.
If you use NW.js 0.12.3 you can also support OSX 10.6+ and very old versions of Debian based Linux OS's like Ubuntu, and Win XP+. It is recommended that you do special builds just for those legacy systems though and use the newer versions of NW.js for newer OS's.
I'm currently working on a no-touch deployment and auto-update mechanism for a Windows application. I've tried Microsoft ClickOnce strategy but it did not work for me as the strategy only suits small-sized apps, and my application hauls at ~500MB.
I'm interested in how the stub based installation and update strategies work for Mozilla Firefox and Google Chrome and also Microsoft's packages including its .NET framework and VS installers. I've come across Google Omaha which hosts the Google product update deployment mechanism, but it is not very conclusive for me.
Can anybody please help me out how the stub-based deployment design works?
P.S. Any open source code for the same would be of a great help. ;-)
I'm not quite exactly sure of what you mean by "stub-based". There's a handful of technologies and tools involved in what I understand you want to accomplish. For the setup packages creation there are: NSIS, Inno Setup and the WiX Toolset, for example. A core technology is MSI. On the other hand, for application updates and the such, there's BITS and also some web stuff involved in updates publishing, like using an ATOM feed, for instance (your referenced Google Omaha might fit into this category).
It's only a bunch of pointers, but I hope it helps.
The Mozilla installer is opensource (as is the NSIS system it uses) so I'd suggest adapting the code found here: http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/installer/windows/nsis/
It's a bit complex so you could start with a simpler script and incorporate the bits you want (like finding/downloading updates and UAC evelation).
Just got started and running with jqMobi, which is now called 'intel's application framework' (cheesy name eh)
Along with intel's porting to their new site, they forgot to put the full docs online (at least I can't find it). Now there's only minimal documentation, like the getting started. I'd like to get on with it.
Anyone knows where the (full) docs are hosted? I really hate to go look for another framework again.
The documentation is all there. The only thing they did not add was the "testdrive", which is just the kitchen sink sample found in github
In my opinion the docs are somewhat scattered, but there's some helpful stuff if you can find it. I keep bookmarks for these links. There are some links from those that get you to more stuff.
http://html5dev-software.intel.com/documentation/jqmobiapis/index.html
http://app-framework-software.intel.com/documentation.php?r=9057
http://developer.html5dev-software.intel.com/
http://www.html5dev-software.intel.com/documentation/
Actually they split off where appMobi is a cloud services company to support apps, and Intel took the part to build the apps. So you may still need/want appMobi. Their docs are on their site of course. There is still some duplication on the appMobi site.
Technically I don't think jqMobi is the same thing as the Intel App Framework, but at the same time I have a hard time understanding what's called what anymore. I'm sure they'll clear this up over time. I hope they find names that can be useful tags on stackoverflow.com!