I liked Dart from the beginning... It could have been a perfect replacement for JavaScript a few years ago, but now with ES6 becoming widely available in browsers and Node.js, I feel that some of the shine of Dart has been lost.
I think the biggest problem with Dart isn't related to the project itself - My biggest concern is that other browser vendors didn't embrace it. Dart has not been universally accepted by all sides, despite the massive amount of publicity which it received over the years.
With ES6, I think that JavaScript has proved that it can adapt to change and that it has significant staying power.
I think the Dart team made all the right moves, but, unfortunately, so did the JS team.
The project hasn't had much luck either. There was no breakthrough. Getting its own native VM inside Chrome would have been nice.
They did do a lot right. But two big things that hampered adoption, I suspect, are
* Working on Dart in secret for a while and unintentionally revealing it to the world in a leaked email. This made it look threatening from day one, since the email seemed to imply covert plans to replace JavaScript. The impression may have been partially wrong, but given those circumstances, there was a negative initial impression.
* Intending to ship the Dart VM in Chrome, despite no interest - and some opposition - in standardization from all other vendors. That worried a lot of people in the web community, both because of policy reasons (vendors shouldn't ship that way; it's even against Google's own Blink principles) and technical reasons (the intent was to polyfill in other browsers, but semantic differences - e.g. in numeric types - meant that was risky). In the end Google didn't ship the VM, despite years of massive efforts towards doing so, but the damage was already done.
And some more minor things that I think were problems as well:
* Dart's syntax looked "Java-esque" to many people. Java isn't in fashion anymore. Yes, the goal was be a familiar and natural language, but it achieved that goal primarily for Java devs. Which is a large group inside Google, of course (hence other projects like GWT and Closure Compiler), but in the larger web dev community, "looking like Java" is a downside.
* The already-mentioned semantic differences on numeric types between the VM and the polyfill. Calling it "undefined behavior" excuses the difference, but the risk of web compatibility remains - undefined behavior makes more sense for a source language like C or C++, where you ship binaries, and not for the shipped code, especially on
the web. As far as I know, this was never resolved, because harmonizing those semantics had too much of a perf hit, despite attempts to optimize things. Perhaps there was too much optimism in early days that this could be achieved.
I think it's a mistake to see Dart primarily as an alternative to Javascript in the browser. While this is certainly how Google initially tried to market it, Dart always was designed around having its own VM, and as a result, it is actually more of a competitor for Python, Ruby, or Node. Even the original move to provide an alternative to Javascript in the browser was not primarily because Dart was a different language, but because the Dart VM wouldn't be constrained in the same way that Javascript VMs were.
Meh. JavaScript isn't horrendous. It's not great, but every language has its flaws, even ES6. It gets the job done and lets us make stuff and go home at the end of the day having made stuff. It's good enough.
Without starting any religious wars, I think we could all name at least one language that is very poorly and even dangerously designed, even though it lets you make stuff which sort-of works and earn money.
"With ES6, I think that JavaScript has proved that it can adapt to change"
JavaScript proved squat. Those changes should have been done a long time ago and now we should have had a sane language instead of JS. Betting on JS "evolving" is the wrong way to go.
I think Typescript is in a different boat. All valid JS is valid Typescript, and Typescript is adding new JS features faster than browsers can. If JS ever catches up to Typescript it'll be by becoming Typescript, basically.
The rate at which JS evolves has been determined quite rightly by browser market share and aut0-updatability. When your clients need to upgrade their VM when your language changes, the only way to ensure progress is to make sure all your clients are running latest auto-updating versions. This is beginning to happen now, which is why the V8 and the language itself can start to make real progress.
I used Dart for a project 1-2 years ago and really enjoyed it. It's a well designed language with an equally well designed standard library and already had fabulous tooling (IDE support, package manager, debugger) back then. My hopes were that it could really replace JS at some point of time, because I'm not the biggest fan of JS in the ES5 incarnation. For me it was a little bit sad to see that Dart got almost no external traction since while Go got lot's of traction. I personally think Dart is the better language in most regards.
Since then I have worked on a few non-web projects and now got back to building some bigger application with node, a browser frontend and typescript. With the current revisions of typescript I don't miss much from Dart, Typescript did a great job on building a type system that fits to Javascript and the ecosystem (available libraries, etc.) is huge due to seamless interoperability (export typescript as JS libraries and import all JS as untyped typescript). Therefore for me the appeal to use Dart instead of typescript in classical web applications is much lower then some years before.
For other applications the choice of languages is already more then abundant. I don't think it would have been a bad move to introduce it as an Android application language, but I don't think that will happen due to all the existing code.
I'm interested to see what will happen in the microcontroller domain, but this is a very slowly evolving domain where real changes happen rarly and everybody is stuck on C despite alternatives have been available earlier. Don't see a special appeal for raspberry PI like devices - these are more like PCs then really embedded stuff. You can run nearly anything you want there.
Dart is a great language. I tried it on day one and it has come a long way since then. But in my experience... every time I read an article trying to justify why something is still relevant or important in a company roadmap, it dies a lonely death a short time after.
> trying to justify why something is still relevant or important in a company roadmap
While I know what you mean, I didn't read the article that way at all. The author isn't a marketing type or someone high up in the company, but a programmer making a calculation about Dart and passing on his observation to his friends, who don't see that situation the way he does. Dart has received a lot of bad press because some Dart engineers made the mistake of saying it would replace JavaScript. I didn't get involved in defending JavaScript from Dart and wrote a bunch of Dart, and I noticed I was about twice as productive. I also learned along the way that Google was heavily invested in something called Google Web Toolkit, a Java based system for writing web apps. I figured Google was looking to replace that with Dart so it would always have a place, and it looks like I was right. The code that powers the engine that brings in 17 billion dollars a year is nothing to dismiss, like many do of Dart, if in fact they are converting GWT to Dart, and it sounds like they are.
TypeScript is one way to add safety, Dart is another. The difference in the two approaches is discussed here by the two main authors Anders Hejlsberg and Lars Bak respectively [1]. What I found compelling about Dart was the elimination of "monkey patching" that Lars talks about. I was also drawn to try TypeScript and found it a great tool as well. So does Google as they are now using TypeScript in Angular 2.0. Microsoft and Google are working together - never thought I'd see the day.
I couldn't help reading the emphasized "types" in "optional types" as a yell for the Typescript developers to come back.
But I too hope that Dart will become more successful, because let's stop beating around the bush -- it isn't now, not relatively speaking and comparing to the state of web development today. And this is unfortunatenly _not_ because web development hasn't been rapidly evolving the past few years.
But enough negativity. I found this part the most interesting, because today there are already so many ways to get various non-officially sanctioned languages onto both iOS and Android:
> Soon, you’ll be able to write Dart code for micro-processors (think Raspberry Pi) and — more interestingly — for micro-controllers (think Arduino). This means developing for really compact, really cheap, really low-energy devices is no longer a C/C++/asm club.
> I couldn't help reading the emphasized "types" in "optional types" as a yell for the Typescript developers to come back.
Not sure what you mean, but I definitely didn't have TypeScript in mind. I emphasized "optional" in "optional types" in the bulletpoint where I'm talking about "getting out of your way", and "type" in the next bulletpoint where I'm talking about structure. It was meant to be cute but evidently I failed... Sorry for the confusion.
I liked Dart enough to give a talk about it at the local Google user group a year or so ago. Sadly, I haven't touched it since; less because I fear that it's a dead/failed language, and more because I simply haven't found a use case for it where a language I already know better doesn't do an acceptable job.
> I couldn't help reading the emphasized "types" in "optional types" as a yell for the Typescript developers
Dart was saying this before it was cool!
Historically, Dart was (in part) born out of Gilad Bracha's Pluggable Type Systems[1] paper, so the concept of optional types is the very heart of Dart, and was so long before TypeScript.
It's sad that Gilad's obsession with Smalltalk led to this.
I feel that Dart could have been a more serious competitor in that space if it was fully statically typed. No optional types. This would lead to a more credible language and, obviously, a more performant one.
A number of people on the Dart team are working on strong mode[1], which is very close to what you're asking for.
I say "very close" because "No optional types" is ambiguous. Type annotations are still optional in strong mode because in most cases it will infer the static type for you. Strong mode still also supports a dynamic type—much like C# does—because that's useful for things like interop or working with data.
Strong mode was initially created because it helps produce cleaner JS (unsurprising that static types help with static transpilation) but what we're hearing from customers is that they like it for better type safety and tooling. Even many of the Flutter[2] folks, who don't compile their Dart code to JS at all, are using strong mode because they get better static checking.
Not really. Counter-intuitively, all annotated types are thrown out at runtime, as far as I recall. The VM learns about types in the same way that JS VMs do. Dart's performance wins over JS are elsewhere (object construction and access (designed without prototypes to avoid the performance pitfalls of V8's hidden classes), lack of global object, with and eval…).
> The VM designers say that in practice, type guarantees really don’t help them nearly as much as you might think, because type checks are not a major drain on performance.
> I think it's interesting that the author says: "I’m betting my career on it"
Yes, the author is probably a bit junior in that field. You don't bet your career on technologies, much less languages (especially beleaguered languages like Dart).
You take a bet, see if it works for a few years and if it doesn't (which is the case for 99% of languages out there), you move on to something else.
Cross pollination of ideas from working with different languages is a very powerful thing. Coders often, sadly, regard 'their language' as a walled garden, whereas in fact there is so much crossover in terms of technique, it only makes your knowledge deeper and more solid seeing how solutions are achieved in different ways.
At least, that's been my experience as an average/middling dev - there may well be some level of zen where this doesn't apply, but I'm hard pressed to think of one right now.
One of the things that Rust (GC free zero cost memory management), Swift (the official iOS programming language with excellent UI libraries) and Blueprint (easy coding for non-coders in UE4) have made crystal clear to me is that, if you choose to create a new programming language rather than using an existing one, you need to actually decide what the draw card you have is, over other existing solutions, and stick to it.
Dart has consistently failed to be anything more interesting than slightly better javascript that interops poorly with existing the existing javascript ecosystem.
That is not a draw card.
Now, it seems to be trying to be 'a generally useful programming language you can use on multiple platforms'. That's not a draw card. Just stop!
Please actually focus on making Dart something special, or give up on it.
There's this thing, where you make something and you get invested in it, and it becomes to politically complicated to throw away.
I have no technical objections to Dart, it's a fairly nice language; but I too, cannot come up with any reason to either use it, or be excited about the future of it.
I've made this comment before. I'm wondering if there are plans to replace Java with Dart or Go on the Android platform. This because of the continuing threat of lawsuits from Oracle.
It's probably impossible to replace Dalvik because you need the bytcode but maybe replacing the language might shield Google from Oracle.
The Dart & Go teams have projects to target Android but AFAIK these are independent projects with no relation with the Android team.
Dalvik -> it is already replaced by ART, but it is still a VM (for ART the bytecode is compiled AOT though).
AFAIK, there is no public plan to replace java, neither are there any public commit on AOSP indicating a move in that direction.
Many Android devs are following Kotlin very closely (it is a boon for Android app development) but again there is no known plan from the Android frameworks team to switch to it.
Which is a pity. With Google's backing (and they already collaborate with JetBrains, as Android Studio is forked IntelliJ Idea) Kotlin could really grow.
I hope that Google will reconsider. Being stuck with Java 6.5 is more and more of an issue. You can use ThreeTenABP, Retrolambda and some other libs to get past some of the languages limitations but that's far from ideal.
Even if Google switches to OpenJdk 8 (or even 9 or 10), if the adoption times stay consistent, we will have to wait 3 years before being able to use their new features in mature apps.
I do hope that either the android team is working on a new language (along with a framework revamp) or will reconsider its position on Kotlin and starts adopting it.
Why do you expect any other language would have a lower adoption time? Kotlin has to pay the same performance penalties RetroLambda and others do until the device runtime itself is updated.
because kotlin can target devices already in the wild (albeit with a perf cost indeed) whereas languages features added by a new jdk will only be useable with terminals sporting a new version of Android.
Just like right now most of us can't use try with resources.
It would be fantastic if Swift was adopted as the language for Android.
It's a very well-designed language (with non-nullable types and immutability!). It's now open-source, and development model is even more open than Android's throw-over-the-wall.
Swift's type inference and ARC makes it feel very script-like, but it supports AOT compilation and tighter control over memory usage.
While Cocoa won't be available on Android, having a single language that's usable on iOS, Android and server-side would be great for reusing as much as possible.
Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though.
So, you can have Kotlin on iOS via RoboVM. But that's kind of expensive. Also, RoboVM brings its own heavy runtime environment with its own class hierarchy, garbage collector, and the need to bridge between that world and the ObjC runtime.
Or you can have RemObjects's almost-Swift (http://www.elementscompiler.com/elements/silver/) on Apple platforms, Android/JVM, and .NET as well. I call Silver almost-Swift because some permanent differences from real Swift are documented here: http://docs.elementscompiler.com/Silver/DifferencesAndLimita... For that reason, though I like the Elements compiler's approach of targeting each platform in the most native possible way, I'd recommend using their C# front-end or even their Oxygene language (a Pascal derivative) instead.
> Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though.
Sure, but as we've seen from the WebKit/Blink fork, Google and Apple aren't capable of sharing stewardship of something that central to both of their platforms in the long run. So it's not going to happen.
iOS and Android both disappoint me as being one-language-dominates platforms; I much prefer the paradigm of Windows, Linux or OS X, where you can have apps in Python, apps in C, apps in VB or Lisp or FORTRAN or Brainfuck, all running as first-class citizens. It feels like a real step back for me.
It's a step back just as the walled garden ecosystem is in general, but it did make it easier to find documentation and hire developers, and thus grow the platform.
>How well does Kotlin perform on Android? Can you use all the native stuff?
Not only is Kotlin a great language, it is also a good fit for Android since it outputs bytecode and is entirely interoperable with java.
The only cost of using Kotlin are the 6k methods that it adds to the apk. You can call all the native Android APIs. Of course they are not idiomatic kotlin code, but you can cope with that, especially since the Kotlin team has written some Extensions methods in order to facilitate this process.
>Are there some successful apps written in Kotlin?
I know that Expedia uses some Kotlin for its new features (since there is full interop, you can switch gradually).
I am working alongside 12 or so other engineers on a successful Android app. Most of us (especially the more experimented) would like to switch to Kotlin but we get a lot of resistance from an extremely change averse team leader (we have just convinced him to start using EventBus and are still pushing for Dagger 2 & Rx).
This kind of move is always complex for a large team though. You need to get everyone on board and up to speed with this new language. Even though I think that kotlin is very easy to learn (especially for a java dev), this is still a significant effort.
Personally I think a good way to set a foot in the door (with Kotlin) is to use it for unit tests. Hey, unit tests aren't production code, so what's the worst that can happen, right? Plus in many projects - sadly - tests are still perceived as an optional thing.
And Kotlin is very well suited for tests, because it's so expressive, DSL-friendly etc. There's also this pleasant framework: http://jetbrains.github.io/spek/
If you can't convince your team (or bosses) to switch to Kotlin, start writing unit tests in Kotlin. They can even coexist with Java ones, so I believe this is an easy way in. And once people get to see it at work...
we already have started making more and more tests several months ago (the code base we inherited is awfully architectured and entirely untested), I will try to win over our test engineer with that idea.
JetBrains has been using Kotlin in production of IntelliJ IDEA, YouTrack and other products for quite a long time now. We have more than 250’000 LOC of Kotlin in production at the moment (plus about as much in the Kotlin project itself). While some of our projects are entirely written in Kotlin (account.jetbrains.com), others have introduced it to existing Java codebases, as we planned initially. We reached the level of interoperability where freely putting Kotlin alongside Java is transparent for Java clients: Java can be called from Kotlin and vice versa, sources can be mixed in one project, resulting .class files are totally compatible with Java tooling.
Some folks use Groovy (I've attended a talk about it on one of the DroidCons), although the tooling is a bit lacking, and there are some other drawbacks such as long build times.
Groovy for Android isn't being maintained. The programmer maintaining it was retrenched by Pivotal 12 months ago. Groovy's used quite a lot for scripting, but the more recent statically-typed additions for Java and Android aren't being used much and have QA issues.
Yeah you've got full interop with Java. There is some overhead in terms of executable size, but not significant. As for commercial apps written in Kotlin, I have no way of knowing, but there's a lot of open-source projects. It wasn't long ago that Kotlin reached 1.0, and prior to that I would myself err on the safe side not recommending it for production yet. It's been improving very fast though.
I doubt that Google would adopt a language owned by a main competitor, they had enough troubles already with Java.
And as already mentioned, Kotlin feels a lot like swift and is interop with Java.
Garbage collection is absurd to run on a battery-powered device (both Go and Dart are garbage collected, like Java). I think that Swift would be a great choice, and would allow some sharing of code between the platforms.
They'd still need to ship the class library (with 'infringing' API copyrights) for many years for backwards compatibility. Their current strategy of replacing Apache Harmony classes with OpenJDK seems like a good shot to get rid of Oracle's claims for future versions.
My guess is that they'll wait and see how that move pans out first.
Now that Google has decided to comply with the OpenJDK license (as they should have done years ago, IMO), this should not be a problem. They will now be using a license officially granted to them (and anyone else) by Oracle, a completely free license, with no restrictions (Oracle are prohibited to place further restrictions by their own license).
> I'm wondering if there are plans to replace Java with Dart or Go on the Android platform.
There are very few languages choices where I prefer to keep using Java. Go and Dart are two of these.
I'm a dedicated Apple skeptic, but Swift is nicer than both of these trainwrecks.
If what the article claims is true (that Dart can be used to target µCs), which I highly doubt, it might become interesting for me. My doubts arise from the fact that the standard library for a language makes some opinionated design choices, and in my opinion it's impossible to make an idiomatic library that works the same (and is usable!) in a GC context (existing deployment) and a non-GC context (embedded).
It's sad that of the dynamic languages, Python and Ruby are performance deadends, and LuaJIT is too obscure for most people.
Elixir (and the Phoenix web framework) is getting a lot of attention these days from Rubyists who are looking for something that speaks their language that is also fast in realtime distributed environments.
>My doubts arise from the fact that the standard library for a language makes some opinionated design choices, and in my opinion it's impossible to make an idiomatic library that works the same (and is usable!) in a GC context (existing deployment) and a non-GC context (embedded).
What microcontrollers you have in mind? He mentioned Arduino in the post. It's not like we need Dart for extremely low spec-ed mCs, and we could run GC just fine in higher level mCs for ages...
> What microcontrollers you have in mind? He mentioned Arduino in the post. It's not like we need Dart for extremely low spec-ed mCs
The article mentions the Arduino, which in its original incarnation is an extremely tiny AVR. Maybe the author has a more powerful Arduino variant in mind, but I'm pretty sure you cannot run a GC runtime on the AVR Arduino. The only language that runs on such tiny devices is probably eLua.
> , and we could run GC just fine in higher level mCs for ages...
> The Android team has publicly stated that only Java matters on Android and the NDK is only a means for games and code from other platforms.
The NDK isn't going anywhere, of course, and the recent switch from a GCC based toolchain to a LLVM based toolchain is an indicator that a lot of things are going on in native land.
I don't mean it is going away. What I mean is this attitude:
"The NDK is not appropriate for most novice Android programmers, and has little value for many types of Android apps."
"Squeeze extra performance out of a device for computationally intensive applications like games or physics simulations."
"Reuse your own or other developers' C or C++ libraries."
Versus the Windows Phone and iOS that allow full use of the OS APIs via their Objective-C++ and C++/CX, instead of a thin set of libraries + JNI boilerplate.
Then we have the way the whole Eclipse CDT -> Android Studio process has been handled and Gradle still cannot handle the majority of ndk builds.
It's interesting to hear that Dart was designed as a general-purpose language. I always assumed that Dart was kind of like Coffeescript, that it was only meant to be translated into JavaScript.
I'm curious how this fits in with Go, another programming language from Google, which is also presumably a general-purpose language. Can anybody compare Go and Dart?
Dart was always designed to have its own VM. Compiling to Javascript was more of a necessary evil. Google's vision with respect to Dart in the browser was to have a more powerful VM rather than persistently piggybacking on a Javascript VM (this was what Dartium was about).
Even now, the current VM supports state snapshotting, isolates, and native/transparent big integers [1], neither of which you can get out of a compiler that generates Javascript, unless the Javascript backend already supports it. Compilation to Javascript is still possible and useful, but you inevitably lose some Dart VM features in the process. Ironically, Ceylon now supports a Dart backend.
In short, Dart is both a language and a platform, though the language can also be used to target other platforms.
[1] In general, it's pretty obvious that several of the Dart developers have a Smalltalk background.
Dart was meant to be a general-purpose language from day 1. I think they were always working on the standalone, server VM in parallel to the Javascript translator/compiler/transpiler/whatever it's called these days.
I see Go as a systems language and I think it was designed that way (wikipedia agrees with me here but I don't know enough about it so I'm not claiming this to be true). AFAIK it's used mostly for server / CLI stuff, where its concurrency model and speed shines.
I do write a lot of Go and it fits in the Oberon/Modula-2/C family. It is a general purpose language and the design of the language does not really make it a system language. In fact, one could argue that many properties that people expect of a system language (e.g. no GC) are missing.
Currently, Go is indeed popular for network services and command-line tools, but I think that is due to it's standard library supporting those use-cases well. But Go will surely branch out as its ecosystem matures.
I used Dart a while ago for a personal project. Language-wise, it has dramatically improved by 'await'. My favorite part about Dart is the standard library. I've never used a language with a better standard library.
Does anyone know how Dart will be affected by web assembly?
> Does anyone know how Dart will be affected by web assembly?
WebAssembly right now is a suitable target only for C++ like languages. There is a hope that in the future WebAssembly will introduce features enabling efficient compilation of dynamic languages, but so far it's unclear when this hope is going to materialize into something more tangible than a few entries on the road map.
> I've never used a language with a better standard library.
I found myself wishing that it would take more from Scala's example, especially the collections, where they could certainly use some more utility. I also wish they'd do more to support a more functional style of programming; little things like, say, turning `if` into an expression, which, while I don't think it would affect existing code at all (the result would just be thrown away), would allow you to assign to a constant value, avoiding undefineds altogether.
What's really interesting in the comments on this thread is that almost everyone who has tried Dart reports liking or loving the experience. If all those people would push a little harder instead of caving to the status quo, we might just get wide adoption and a great experience for everyone. You know...progress.
Anyone have any experience with typescript vs. dart? I'm thinking of learning one of the two for frontend and wondered if anyone had any success or horror stories either way. Thanks!
I develop with both, and Dart wins hands-down. ES6/TS adds a lot of Dart's best features to JavaScript, but without getting rid of JS's annoying problems. Many here have mentioned that Dart's standard library is among the best there is, and that's no exaggeration. That alone makes it better.
Whenever I have a choice, I always use Dart. The tools (analyzer, profiler, etc.) automatically make me twice as productive as when I use JS.
Exactly. In the browser (and node) it's not really a question of how Dart compares to TS / ES6 (for example), but how Dart + ease of using JS libs compares to TS / ES6 + ease of using JS libs. And of course that makes sense.
TS is a language where the primary goal is seamless JS interoperability. Presumably, it will always make design tradeoffs to maintain that.
Dart is a language where the primary goal is developer productivity. The team decided that it required a clean break from JS to achieve that.
The tradeoff being that JS interoperability is harder.
So it's not a great surprise that TS wins in the JS interoperability front. Dart has made big improvements here recently and continue to do so and I expect the gap to continue to close but never quite go away.
Similarly, it's not a great surprise (to me at least) that Dart is a cleaner more productive language. As many have said ES6 has made big improvements over ES5 and coupled with TS has significantly closed the gap to Dart.
I see this trend continuing. With Dart maintaining an edge in language features + productivity and TS with JS interoperability ease, but the gaps in both aspects being small enough that it is a matter of personal choice and what best fits the project.
Dart uses map files for debugging in the browser, but if you use an IDE like JetBrains WebStorm or Eclipse, you can debug right in your editor environment without the provably harmful context switch.
The fact that typescript is a superset of javascript turns out to be huge in terms of adoption. Being able to start out writing javascript and gradually introduce typescript features (even in a well established codebase) is fantastic.
The javascript output is also saner and fairly predictable, so (for me at least) it is easier to reason about.
Google is a massive organization, and this is probably the LEAST ridiculous example of redundancy! I've lost count of the number of database systems they've developed.
I don't know if they're still as committed to this today, but historically Google has been famous for allowing their engineers to spend some percentage of their time on self-directed side projects. This leads to lots of engineers working on the same sorts of things in different ways.
Some of Google's databases are just more functionality on top of an existing one, though, rather than being created from scratch. Spanner is built on top of BigTable, and F1 is built on top of Spanner, for example.
I gave Dart a try and liked it. In my opinion it has failed in being a mainstream. It was bad enough that browser vendors where not embracing its VM, but its downfall to go mainstream was in my opinion when Google themselves announced that it would not be included in Chrome.
JS community are embracing ES6 and Typescript now. And for the none browser market there are definitely a lot of better choices.
Programming languages take years to incubate and in five years time you never know what will happen.
Don't believe that a virtual machine based language is going to fly in true embedded environments other than toys though. I've got more faith in lightweight scripting languages for rapid development.
I only tested the Android version and it is still extremely early.
Very basic samples that don't run very well and implement Material elements in an uncanny valley kind of way compared to the existing web & mobiles implementations.
Not to mention that Android with Java/Kotlin has a truckload of tooling that Dart would have to replace.
There are several parts of the android framework that I would like to see rewritten from scratch (activity as a god object, love of inheritance everywhere in the framework classes, weak UI/animation framework, etc) but it is also a mature code base with tons of features, tools & open source libraries built around it.
I tried Dart when looking for a typed language that compiles to Javascript. It was nice but in the end I used haxe because it had a much smaller footprint. Dart seems to include its own library while haxe sticks close to what Javascript offers.
When was that? Dart started out generating massive JavaScript files, but the output has been significantly reduced in the past couple of years (something to do with using transformers to replace some of the reflection at transpilation time, I think).
About half a year ago. It turned 1500 lines of Dart into ~10000 lines of Javascript. That might not be that much to handle for a webview but it was quite hard to debug. I used it as a UserScript in WKWebView so I couldn't use DartEditor. In comparison, the haxe code, which looked very similar to the Dart code, was compiled into 1400 lines of pretty readable Javascript.
Tried Dart a while back and really liked the language.
But I found the emphasis on Dart's use as an application building language didn't fit my use case very well - compiling JavaScript libraries.
In short, I wanted to use Dart as a cleaner replacement for the Closure libraries and compiler. It didn't work well. Not only was the JavaScript quite large, but exposing APIs was a time-consuming manual process.
I noticed the change of focus to using Dart as a language that transpiles to JavaScript for in-browser use. That sounds like what I'm looking for.
When will it be possible to use Dart to conveniently create minified JavaScript libraries that expose well-defined interfaces?
Do Dart and Typescript hurt each other's adoption? i.e. they are close enough that it 'splits the vote' and what might result in critical mass for one ends up with both feeling like they are marginal contenders.
I'm far from being an expert in Go or know the specifics about future plans but from what I've gathered it does seem like a beautiful system language. We mainly use it for writing lightning fast API's. I do have a feeling that it will have a breakout year in 2016.
Presumably the post above was referring to HTTP-based services, which of course don't face issues of cross-language ABI compatibility. In this case Go is often much faster than Ruby, Python, JS, etc., while still allowing relatively quick development compared to even faster, yet lower level, languages such as C/C++.
I feel like I sound defensive every time I bring this up, but Angular supports three languages that are all equally first-class: JavaScript, TypeScript, and Dart[1].
Angular 2 is written in TypeScript because that felt that was the best source language to transpile from. But then they have transpile that to JS and Dart for users of those languages.
The main thing stopping me from using Dart is the same thing as Java and Python and others. It isn't designed to compile in the browser. You have to use the command line or an IDE. I have no problems with those myself, but the apps I am interested in involve letting end users create their own apps/animations/simulations, etc. If they went forward with a Dart VM in the browser, that would be great, but it sounds like that was one of the first things they abandoned.
There are so many other languages that do compile in the browser and can be used without relying on command line tools that there's no reason to pay any attention to dart at all, even though I like everything else about dart: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
Yes, when Dart was still recently released I fully expected at least Chrome of all browsers to directly support it, and with it being an open source project, it to perhaps even trickle out to other browsers as well.
And I saw a Dart-powered web, and it was beautiful. Calling it a Javascript killer is a misnomer, because it's a Javascript eviscerator.
Now Typescript is here in full force and I honestly think that, assuming the language isn't going to be browser supported, that this is a better idea. :/ Simply because TS is a superscript over JS, so developers can migrate their projects over time. Regardless how much of it is still in JS, that is per definition also TS.
I think that is a huge boon, along with Typescript definition files to TS:ify libraries without having to restort to what the Dart guys seem to have been forced into doing with full reimplementations (DQuery, Bootjack, ... rather than simply downloading the appropriate files from DefinitelyTyped.org).
It's too bad, because _conceptually_ I like Dart more! Everything is so coherent regardless if it's on the client or the server, and modern HTML5 features are suddenly just libraries in the language itself! I really like it, I don't even have to "want" to like it, I already do. Kind of annoying. :P
I'm not sure what distinction you're making between Dart and languages that "compile in the browser". You linked to Jeremy Ashkenas' list of languages which compile to Javascript, yet that list includes Java, Python, and even Dart
Edit: Are you referring to languages that you can compile to Javascript by including a script in the HTML? I remember doing this with React, before I set up a build tool to my project. If that's what you're referring to, I'm not sure it's such a huge factor. For one thing, I am not aware of any technical reasons why Dart can't do this as well. For another thing, I don't think compiling in the browser is all that popular. Most front-end developers have embraced build tools like Gulp, Grunt, and Webpack which allow compile to Javascript. Compiling in the browser is also not as performant.
They made two languages. That doesn't seem a lot for a technology company as large as Google. Nobody looks at Visual Basic, C#, F#, etc and says, "Why does one company need so many languages?"
Is JavaScript the only "language" you've programmed in? Personally, I prefer a language that doesn't require large frameworks and libraries that are here today, gone tomorrow for basic language constructs like name spacing or library references. Personally, I prefer not having "engines" silently fail on something as fundamental as syntax errors, causing bugs that can't be reproduced or tracked down. Want syntax checking? You guessed it! Another Framework/Library/Tool to learn or build! Not horrendus? Good Enough? JavaScript is the language of Satan's incompetent stepchild.
I don't know how you can hate Javascript or any other language so thoroughly unless you just finally branched out to your second language that you're currently in honeymoon love with.
Took me two years of writing Clojure full-time to realize that there is no best. There are only trade-offs. These days I mostly use Javascript.
The story goes that I have played with many languages, but only used small amounts of js as needed before building an extension for chrome. I have never found a language to be so unfriendly to n00bs. One is absolutely required to learn third party frameworks and libraries just to do anything useful. There is a never-ending list of basic things that are not supported by the language. I have never had to use a third party tool just to check syntax in any other language. I don't see any trade-offs to using javascript at all. It is a language just like most C-based languages with everything chopped out of it. What benefits does javascript have over any other language?
> These days I mostly use Javascript
You don't use javascript, you use a framework for javascript. In fact, because browsers don't fully support EMCA 6, you are probably even using a tool to convert your javascript code.
I absolutely abhor javascript, to the point where I stopped working on my chrome extension (which is < 500 lines at this point) until I figure out how to do it in another language. Which will probably be clojurescript or typescript.
I think you would find Dart to be a true joy, given your complaints about JS. I switched to Dart, and now even looking at JS code with all those stacks of indented curly-braces hurts my eyes...
I think you're at a place where you would be best off indeed pursuing other languages and solutions. Your current frustrations with Javascript will be a powerful motivation to dig into new ecosystems.
I was in a similar place once and it compelled a tour of languages that's probably the most important event in my growth as a developer.
Finally, it seems like you're talking about client-side development. Client-side applications have to manage the intersection of state, user interaction, and some interface (browser API). That interaction comes with complexity that's classically hard to manage, else we wouldn't be spinning our wheels so much trying to figure out better ones.
Have you ever programmed in JavaScript? I don't use any of those frameworks or transpilers and it's nice. ive written plenty of ruby, Python, Java, and C. What are you talking about with syntax checking anyway?
I'm talking about chrome's extension library returning NULL instead of a "tab" object when creating a new tab because of a syntax error in a completely different file.
It had nothing to do with Chrome's extension API. The API works perfectly fine. It has to do with the nature of JavaScript where syntax errors are "forgiven" leading to unforgivable bugs that require line by line review unless you use a tool to check your syntax. This was not the first, last, or only syntax caused bug I experienced. It was simply the most frustrating and inexplicable.
I think the biggest problem with Dart isn't related to the project itself - My biggest concern is that other browser vendors didn't embrace it. Dart has not been universally accepted by all sides, despite the massive amount of publicity which it received over the years.
With ES6, I think that JavaScript has proved that it can adapt to change and that it has significant staying power.
I think the Dart team made all the right moves, but, unfortunately, so did the JS team.
The project hasn't had much luck either. There was no breakthrough. Getting its own native VM inside Chrome would have been nice.