Dartium for Windows Released : Initial Version Available
Chromium (Chrome) Browser with Native Dart-Language Virtual Machine (VM)
I have been anxiously awaiting Google's new Dartium for Windows browser, their version of Chrome that includes support for their new Dart Language — a very enticing alternative to JavaScript that is under heavy development now. Although you could previously run Dart-based scripts through the Dart-to-JavaScript interpreter/converter/compiler, there are obvious substantial benefits to having a Dart-language VM built right into the browser.Downloading and Installing Dartium Browser
Note: I have done the following on Microsoft Windows-7 x64.The first publicly available version was posted online today in this Dartium continuous-build directory. You will see a file named: "dartium-win.zip"; download that and make sure you have 7-Zip (file archiver) available to open the archive and extract the files.
When you open the .ZIP archive, you will see it contains another archive named "chrome.7z" which you will open. This file contains a single directory named "Chrome-bin". Open that directory in 7-zip to reveal the following files/directories:
Now, I suggest creating a directory on your computer where you want to run this from, perhaps something like "C:\Dart\Dartium". From 7-Zip, grab the contents (the files/dirs) shown in the image above, and drag them into your new Dartium directory. You should be done with 7-zip now.
Before you get too excited about running Dartium, you will probably find that it has issues (unless they have been resolved since I wrote this)...
Dartium Windows Installation Bug / Errors (as of 3-16-2012)
One of the first things I encountered when trying to run Dartium, by clicking on the Chrome.exe file in my new Dartium directory, is that nothing happens! There is no sign that the program even attempted to run. But, if you look at the debug.log file it creates in that directory, you may find errors like this:[0316/124628:ERROR:client_util.cc(397)] Could not get Chrome DLL version. [0316/124628:ERROR:client_util.cc(434)] Could not find exported function RelaunchChromeBrowserWithNewCommandLineIfNeeded
So, what is causing this? Well, I got sorta lucky in my first guess. Fixing this turns out to be rather easy. Just copy the chrome.exe file to the C:\Dart\Dartium\19.0.1071.0 subdirectory, and launch chrome.exe (aka, "Dartium") from there! That should fix the problem and you should see Dartium launch as expected.
Next, you may experience the same thing I did whereby Dartium crashed within moments of running the first time. But, re-launching Dartium resulted in a stable browsing experience so far, and I was able to test out some HTML Pages that used Dart-language scripts (instead of JavaScript!) just fine. You include such scripts like this:
<script type="application/dart" src="Clock.dart">
Which brings me to the most exciting part...
Dart, the programming Language
Although I use JavaScript quite a bit, I have felt constrained by the language and perpetually frustrated by the lack of solid OOP (object-oriented programming) features and robust libraries. And, before anyone corrects me, yes, I realize I can accomplish all sorts of OOP (or OOP-like) stuff in JavaScript using prototypal inheritance, closures, etc, but it still simply sucks compared to a real OOP language like Delphi or C#. Well, Dart is here to finally give me a real in-browser OOP scripting language with strong typing and much more, and available NOW.I am so utterly sick of waiting for the JavaScript purists and boffins to quit arguing what is the best way to implement "syntactic sugar" for things like classes, and having to read spaghetti-code JavaScript with piles of prototype-based "inheritance", and now Dart may deliver me from this evil! Of course these same JS boffins are already trying to discredit any attempt to replace JavaScript with anything that they did not invent, even as the participants from Microsoft, Mozilla, Safari, and Webkit camps make barely a snail's pace march toward "JavaScript.next" or "JS Harmony" or whatever other half-baked next-generation Javascript standard is to be.
Well, such is... if I have to write applications that ONLY run in Chrome/Chromium/Dartium, so be it. I am rather sure I can convince any of my business-software users to install whatever browser is needed, especially when I tell them how I can build the same functionality in less time, and for less money, than it would otherwise cost to develop in JavaScript. Oh, and let's talk about how much easier this code is going to be to maintain — a lot! (based on experience working with other real OOP languages as compared to JScript). This is what is going to make Dart a success. when businesses figure out there is money to be saved by using Dart vs. Javascript, the rest will take care of itself as developers start migrating to Dart. And, I expect that server-side Dart will make a lot of sense too!
Note: I am not saying that Dart is the end of JavaScript. I guarantee JS will be around for a LONG time, as there is a huge installed based of JS code out there, and a lot of developers that work with it. But, that fact alone is not going to keep Dart from becoming an accepted language for web-development. Browser vendors that ultimately refuse to adopt a common Dart-VM may find themselves in the same position Microsoft does now as people migrate from Windows desktop applications to HTML5/CSS3 web-based alternatives running on many devices (and not just those running their proprietary Windows OS).
Now, it is time for me to get back to writing some Dart-based code for some web-applications I am working on. I will be following the Dart-language and Dartium progress closely, and I hope to post some additional articles on here with Dart-programming examples in the future.
3 comments:
it really helped me.thanx
Sorry , but I have to laugh my ass off when I hear someone say they need OOP to program. Biggest Myth in programming. I've been programming since the late 80's, with procedures, functions, classes, and methods. I'll take procedures and functions for the win. You can look at function calls and almost immediately tell what it does, not so with many classes. To me classes get in the way, I want my code to work well and fast, not look cool for other programmers, so then I can brag that I put a constructor in a class to call a method just to do what a simple function call could easily do. Dart could go completely Functional and I for one would be happy. happy codin all!
Anonymous,
Clearly you either see no benefit from the code-maintainability that OOP can bring to the table (through encapsulation, polymorphism, and inheritance) or you simply don't care to see those OOP features as a positive. It is not like procedures and functions are *gone* in OOP, they are just methods on a class. So what?
I have programmed since assembler, and I have spent many a year since the late 1970's writing functional type programs as well as OOP styled programs. Fact is, I cannot see going back to pre-OOP after using it. Sure, if it not implemented correctly, it can be worse than non-OOP. And, like ANY programming method, it can be more memory intensive or inefficient if the person coding is not familiar with how to code properly. Again, I have worked with every type of coding from assembler to COBOL to 4GL's to multiple modern OOP languages, and the fact is, I have seen good and bad programming practices in each. But, when OOP is done properly, I have not seen anything that can rival its productivity and maintainability for any substantial systems.
Keep in mind that with an OOP-capable language, you *can* generally use it as a functional language if you so choose. But, the converse is not true unless you plan to write your own OO layers, which I can almost guarantee will be not be as efficient as implemented natively in something like C++ or Delphi.
Thanks for the comment. I can not help thinking that you have had the misfortune of having to maintain poorly-designed OO code and that tainted your views on maintainability and such. Don't worry -- you are not alone -- I have seen plenty of bad OO implementations that are so ridiculously abstracted and layered full of interfaces and classes that the systems are "unreadable" to anyone but the original authors. I certainly agree with you that in those cases, OO is horrendous. But, I have seen equally bad spaghetti-code functional code too. And, for all it matters, I can write assembler-code that may be more easily understood (with proper comments) than some poor OO or functional systems. :)
Post a Comment