Will Dart scripts run natively in the browser? - html

The Dart language looks like a very nice technology to build web applications for the web. For me it seems that there are no browsers available (yet?) which can run Dart scripts natively. Although there's a description on Dart's site about how to embed such scripts into HTML. I understand that for now i have to "compile" Dart scripts to Javascript. But will this change in the future or the language is designed to be translated to other script standards similar to Haxe?

This is speculation, but I guess that Chrome will likely support dart natively in the future. It will mean that Chrome will be able to outperform other browsers that don't have the native support.
Update: There's a hint from The Official Google Code Blog that it might be coming:
The Dart VM is not currently integrated in Chrome but we plan to explore this option.
Update 2: It looks like I was right! Here's some recent news:
Additionally, and perhaps most importantly, Google is releasing Dartium, a Chromium build with native Dart support.
It’s more than likely that Dartium is part of a series of steps that Google will be taking to launch native support in Chrome — greatly improving the usefulness of Dart. Bringing native support into other browsers like Firefox and IE, on the other hand, will be quite the challenge.
Update 3: Since I posted this answer, Microsoft have released TypeScript which is a competing technology. I'd say it's unlikely that Microsoft have any intention of integrating Dart into Internet Explorer as they would probably prefer people to use TypeScript rather than Dart.

The official answer is Yes, Dart will run natively in Chrome. The branch of Chrome, affectionately called Dartium, is now available as source, and binaries will be released soon. More information on how to get and build the source: http://code.google.com/p/dart/wiki/BuildingDartium

As of March 25 of 2015, the offical answer is: no.
Source: Dart for the Entire Web
Google dropped the integration plan of the Dart VM into Chrome in favor of optimizing the Javascript compilation. Dartium is still accessible for development purposes.

Eventually, yes. The proposed MIME type + usage looks like this:
<script type="application/dart">
main() {
Element element = document.getElementById('message');
element.innerHTML = 'Hello from Dart';
}
</script>
(That example looks like JavaScript, but don't be fooled!)

Related

Why does developing a firefox extension involve installing an sdk?

I'm currently trying to port a Chrome extension into a Firefox add-on, but the development process is incredibly different, and the part in particular that I find confusing is why I should have to install an SDK.
How are these two so different? Do Firefox add-ons run faster because they're precompiled? Why aren't firefox add-ons just HTML and javascript like (some) Chrome ones?
What's going on behind the scenes here that involves using so much command line just to get a firefox addon started?
The SDK exists to help developers build their extentions, but if you don't want to use it there is also a way.
You can use web extensions which as the wiki says have their benefits:
Porting add-ons to and from other browsers should be easier.
Reviewing add-ons for addons.mozilla.org should be easier.
WebExtensions must be compatible with multiprocess Firefox (Electrolysis).
Changes to Firefox's internal code should be less likely to break add-ons.
WebExtensions should be easier to use than the existing Firefox XPCOM/XUL APIs.
I don't have personal experience with web extension but it seems to be promising for someone who does not want to use SDK and the benefits ofthe web extensions are that they support an enrich manifest document and you only need to zip your extension and run it.
There are some examples on github to get started.

native browser plugins alternatives to NPAPI

Hello as you might now NPAPI is deprecated.
What are the alternatives to this? I see skype released now the web version where you need to install a web plugin to make voice and video calls. Looking over what I installed I arrived to the conclusion that on chrome they are using Google Native Client: https://developer.chrome.com/native-client
But this one is not supported on firefox/safari (only chrome).
On Firefox/Safary I'm not sure what they are using.
So what are now the best alternatives for this kind of job where using c++ is mandatory (to extend an existing app and make it available as web plugin)
Silviu
After Chrome drop the NPAPI support, there is no-common technology support by Firefox/Chrome/Safari. You can consider about Firebreath 2.0. It allow you use one C++ implement to support different browser.
It's not released yet... If you like to try version 2.0, you can get source code from https://github.org/firebreath/firebreath (the "refactor" branch)
Note: version 2.0 make huge change, because the call between plugin and javascript are asynchronous! Upgrade from older version required lots of javascript change.

What are the functional differences between NW.js, Brackets-Shell and Electron?

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.

Framework to develop Google Chrome Extension "Session Buddy"

I'd love to develop Google Chrome Extension. But currently I don't know any framework to work with. I found the "Session Buddy" is one of very well structured extensions. I think it must be developed by specific framework (because it's very well structured, and encoded).
Anyone know what framework does the author of Session Buddy use to develop this extension? Here is the url: https://chrome.google.com/webstore/detail/edacconmaakjimmfgnblocblbcdcpbko?hl=en-US
Moreover what other frameworks do you use to create chrome extension? Does it support unit test?
Thanks for your answers,
nTuan16
The current version of Session Buddy (v3.0.9) is coded in pure JavaScript, with the exception that it uses MooTools for internationalization of dates and ordinals (I'm currently exploring alternatives to that though, so this may be replaced in favor of a different library in a future release). The code obfuscation is achieved through a simple js parser I built using C#.
-Hans (Session Buddy developer)
Addendum: I should add (because you mention the code structure) that I pass the code through Google's Closure Compiler with a compilation level of WHITESPACE_ONLY.

Using Java/Python libraries in programming Firefox/Chrome Extensions

I have an idea of studying user behavior on the browser, for which I intend to make a Chrome/Firefox extension to study the behavior dynamically. I have some predefined libraries in Java and Python to analyze the results, which will be impossible to program in plain JavaScript.
Now for my question: is it possible to use third party libraries, especially those of Python or Java like plain function calls?
I have a vague idea about something like Java XPCOM or PyXPCOM for Firefox. However, for a beginner, it all looks so scary. I started making Add-On for Firefox, but got lost somewhere in the huge API.
I found Programming Chrome extensions easier than Firefox, but I couldn't come across something similar to XPCOM in Chrome.
How can I decide which one to go for?
Chrome - seems easy but I am not sure of its power.
Firefox - Seems powerful, but is it really possible to use any Java/Python Library?
Additionally, I came across this link that may be useful: How does someone use thirdparty libraries to be included in Firefox addons/extensions?
But seems like it mostly talks about C++ and XPCOM.
I have a vague idea about something like Java XPCOM or PyXPCOM for Firefox. But for a beginner, it all looks so scary.
I am not a beginner and JavaXPCOM/PyXPCOM are very scary (in addition to being barely maintained). As Firefox goes, it should be much easier to wrap your Java/Python library in an application and run it as an external process: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIProcess. Note that you cannot get data back (other than an exit code) so the application should write it to a file that you can then read in your Firefox extension. Not very elegant but it has the advantage of being doable.
As to Chrome, its extensions run in a sandbox and using Java or Python isn't possible. Only option is adding an NPAPI plugin to your extension. It is binary code meaning that it could do anything.
When writing Chrome extensions, you're limited to JavaScript unless you choose to use an NPAPI plugin, which lets you do pretty much anything, but is not recommended.
The other approach you could take is to implement your Java or Python code on the server and make requests from the chrome extension's JavaScript.