Why does this video sound like a tv shop program selling body hair removal solutions.
Dart is ready for the real world
31–40 of 53 posts
Re: Dart is ready for the real world
#32From the editor-promoted comment: Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what…
I love what you're saying, but I don't think it would be mutually exclusive with dart. While a standard byte code solves a very similar problem, it's still a different problem, and a much harder and longer one to solve.
Re: Dart is ready for the real world
#33Dart + Native Client Modules almost makes me excited about web programming again. Obviously not for general websites, but for specific applications it would not be unreasonable to require Chrome to be installed as the alternative would be installing a native app anyway.
Not again. We have been through this with ActiveX and it was no fun. Similarly we have been through "works on every OS (if it is Windows)". Web development today with JS/CoffeeScript + jQuery + Underscore and other libs is not hard. Just accept that different users will use different browsers.
I am more thinking of Dart+Native Client as a nice alternative to native application development rather than an alternative to general web development.
If you wanted to write an application that performed with native speed would you rather write it multiple times for Windows, Linux and OSX, iOS* and Android (and make sure it compiles on multiple architectures) AND force your users to install and update the application on their computer...
OR
Write it once as a mixed Dart/Native Client app targeting the LLVM bytecode and run it securely in the Chrome browser on multiple platforms? All the user needs to do is install Chrome and visit a URL. Updating the app becomes trivial.
I am not saying it is the clear winner, but to me it sounds like a damn interesting alternative with a lot of promise.
It is also possible that Chrome will "win" - either by gaining such majority user-base that targeting specific features of Chrome becomes worth while, or because Dart+Native Client becomes a de facto standard the other browsers adopt.
Also, if you are writing a "web app" to target a niche market that really want to use the application (hard-core gamers?), requiring Chrome really may not be a big deal for the user-base. After all, if people are willing to install native applications on their local system, why would they be unwilling to install Chrome and visit a URL?
* It is unclear if the Chrome browser on iOS will ever be able to download and run native code for both technical and policy reasons.
Re: Dart is ready for the real world
#34I'm not convinced. After Google killed numerous projects this year, I'm a little skittish about jumping into Dart. When it has the traction of Go, I'll be more willing.
Second time I've seen this today. An account created minutes after the submission apparently just for the purpose of spreading FUD.
Why FUD? Javascript is well established, in fact it is the most popular programming language on the Earth. Are you sure that if Dart would not catch up for 2 years, it would not be cancelled by Google (or, as it is nicely said these days, "given to the communit", as Google Wave was.)
Re: Dart is ready for the real world
#35From the editor-promoted comment: Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what…
Brendan Eich talks about the VM solution (http://www.youtube.com/watch?v=Rj49rmc01Hs Slides: http://brendaneich.github.com/Strange-Loop-2012/#/).
I personally believe that HTML is fantastic for what it was designed for: Structured Documents. But the world has gone more interactive and I believe the ad-hoc solution of Javascript, HTML and CSS is not "rich" enough to provide for the users demand.
I like the language independent VM idea as long as it doesn't turn out like bloated Java bytecode.
Re: Dart is ready for the real world
#36I like it. Here's what it has got for me:
Isolates: Message passing concurrency which takes away 80% of the problems with threads and locking. I find it intuitive in the way that Unix pipes are intuitive. A few other languages have this also but Dart is one of them and its a plus.
Optional Typing: Its a dynamic language so its very flexible. Some statically typed languages are also flexible but you can still run into some very complex cases with the type system. I want to focus on my application. By having optional types though I can get 80% of what static, strong typing gives me, namely documentation, the ability to quickly reverse engineer someone else's code and runtime type checks. You know all those unit tests that you write in a dynamically typed language just to check the type of some parameter? With Dart you just turn on a switch and those unit tests are built in (I don't think typescript gives you this as the type information is erased at runtime)
Native debugger: I want my apps to run everywhere which means generating javascript. I see the Dart VM as a native debugging environment. Google have built a special VM so that I can debug Dart natively. I don't think source maps will be able to give as rich a debugging experience.
Tree shaking: The size of javascript libraries is a big issue. Have you tried looking at some sites over a slow mobile connection? Tree shaking looks like it will make it possible to only pay for what you use. This is a major plus
A consistent core: How many javascript libraries are there? Which should I pick? I don't even want to pick anymore I just want to get on with the job.
A pretty good experience: Rob Pike had an article a while ago about people complaining about a language without using it. I tried Go and that's why I like it. I also tried Dart with the Dart editor. Its nice, the libraries are good, the language is fluent and concise enough. Everything seems to be in the right place.
Re: Dart is ready for the real world
#37Is google really betting dart will take off? Because I don't see microsoft/apple/mozilla supporting it in the future. But of course dart can still be a cofeescript competitor.
There is one language to kill JS and Dart. It is TCL and it is here with two decades of development and sane. Why develop these languages when TCL has everything and can run in the browser or even with NaCl.
Re: Dart is ready for the real world
#38I have been using dart for a couple of months now and am extremely happy with it. Code completion on the DOM API is a different world to the classic javascript edit-test-fix syntax error cycle.
The language and the vm are a distraction. The huge win with dart is what the IDE will do for your productivity.
Re: Dart is ready for the real world
#39I haven't read all the comments sorry if this has been posted already. I think you guys would enjoy listing to this discussion about TypeScript, Dart and JavaScript between Anders Hejlsberg and Lars Bak the guy behind V8 and co-creator of Dart.
Link: http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-a...
Re: Dart is ready for the real world
#40Honestly I still don't see the point of Dart. It's made some strange choices (IMHO) like optional typing. The idea that code can be shared between client and server is the panacea touted by GWT, which (IMHO) failed to eventuate (eg some classes weren't "GWT compatible" and this included protocol buffers generated classes). Dart seems like the next throw of the dice. I am not optimistic about its successes. Go on the…
>It's made some strange choices (IMHO) like optional typing. Yes, this may look a bit weird, but it actually makes perfect sense. Those types are annotations. If you use them at the "API boundaries" (parameters and return values), you already get most of the benefits you may know from Java or C#. Compare the doc comments you usually have to write with those baked-in type annotations: /** * Foos the bar. * @param {int…
You made an example of how not to write documentation and then you shown that the code was better without. That is not the point.
Try to add content to the documentation, as "what is expected to be x?", then you can't remove it so easily anymore