Linked by Thom Holwerda on Fri 20th Dec 2013 07:53 UTC, submitted by Hiev
General Development

Google believes Dart speeds up both developers and the programs they write, but skeptics worry that it fragments Web programming and undermines the industry's focus on better JavaScript. So far, it's been a largely academic debate, but that will change in coming months.

That's because Google right now is building Dart technology directly into Chrome.

Does anyone here use Dart?

Order by: Score:
Dart
by shiny on Fri 20th Dec 2013 09:40 UTC
shiny
Member since:
2005-08-09

I'm considering it for my next personal project, just for the sake of trying it out and experimenting. Probably wouldn't bring it up at my next project planning at work though.

Good thing about Dart is that it maintains compatibility by compiling to JS on non Dart-enabled browsers, although that impacts the performance.

Courious whether it will follow the fate of GWT.

Reply Score: 3

RE: Dart
by AndyB on Fri 20th Dec 2013 10:15 UTC in reply to "Dart"
AndyB Member since:
2013-03-22

Good thing about Dart is that it maintains compatibility by compiling to JS on non Dart-enabled browsers, although that impacts the performance.

So if it can compile to Javascript it can't do anything which Javascript can't? If my assumption is correct, what's the point of it, might as well just carry on writing in Javascript!

Reply Score: 2

RE[2]: Dart
by moltonel on Fri 20th Dec 2013 10:40 UTC in reply to "RE: Dart"
moltonel Member since:
2006-02-24

So if it can compile to Javascript it can't do anything which Javascript can't? If my assumption is correct, what's the point of it, might as well just carry on writing in Javascript!


The idea is that dart code is easyer to write (there are other, more popular tools for this, for example cofeescript) and that the language is easyer to optimize for the compiler (speeding up execution).

Dart is actually *less* functional than javascript. But they only threw away parts of JS that nobody should use, and are just early mistakes that hamper JS to this day.

That said, until dart gets traction from other browsers, I won't even try. Mozilla's asm.js is less ambitious in a way, but I think it is a better way forward.

Reply Score: 3

RE[3]: Dart
by vivainio on Fri 20th Dec 2013 12:42 UTC in reply to "RE[2]: Dart"
vivainio Member since:
2008-12-26

CoffeeScript makes JS less fugly, and TypeScript makes it more scalable for larger teams and bigger projects (through static typing). Both compile to idiomatic JS.

I don't see a good "niche" for Dart, since both of these interact perfectly with existing JS ecosystem and provide the same "better language" benefits as Dart.

I'd rather see a JS-with-perf-extensions in the VM (e.g. structs and type annotations, integers, ...), that TypeScript, CoffeeScript & friends would compile to.

Reply Score: 3

RE[4]: Dart
by moltonel on Fri 20th Dec 2013 14:37 UTC in reply to "RE[3]: Dart"
moltonel Member since:
2006-02-24

I'd rather see a JS-with-perf-extensions in the VM (e.g. structs and type annotations, integers, ...), that TypeScript, CoffeeScript & friends would compile to.


That's pretty much what asm.js is. It's hard to call it an "extension" because it removes stuff from the language instead of adding to it, but it has the distinct advantage of being proper javascript that can run unmodified even on a browser that only knows about plain javascript (not sure what the performance profile is in this case).

As for type annotations and similar, since you can generate asm.js code from llvm bytecode, you have a large choice of languages to write your code in.

Reply Score: 3

RE[5]: Dart
by vivainio on Fri 20th Dec 2013 17:03 UTC in reply to "RE[4]: Dart"
vivainio Member since:
2008-12-26

I'm thinking something sane and debuggable (asm.js doean't even have a string type).

Reply Score: 2

RE[6]: Dart
by lvl21ogre on Fri 20th Dec 2013 18:33 UTC in reply to "RE[5]: Dart"
lvl21ogre Member since:
2013-07-04

asm.js is also very new technology. They're considering a string type, among other things.

Reply Score: 2

RE[2]: Dart
by modmans2ndcoming on Fri 20th Dec 2013 23:39 UTC in reply to "RE: Dart"
modmans2ndcoming Member since:
2005-11-09

All touring complete languages can do everything any other touring complete language can do so why bother using anything but Assembly?

Reply Score: 3

Not yet, but I really hope so
by protomank on Fri 20th Dec 2013 10:34 UTC
protomank
Member since:
2006-08-03

Anyone who coded in Javascript knows that the languace grown in a way it is now a collection of patches (classes on it are a bad joke) and Dart seems to be a modern restart that avoid some bad heritage and is nice like C#.

Disclaimer: I am a C++ coder, but I do like C# syntax, I worked a lot with Javascript in commercial projects, and I know it is trash.

Reply Score: 4

RE: Not yet, but I really hope so
by AndyB on Fri 20th Dec 2013 11:11 UTC in reply to "Not yet, but I really hope so"
AndyB Member since:
2013-03-22

Personal experience is that you always lose performance writing in compiled languages, although it is usually much easier.

I assume it is run natively on Chrome with no need for Javascript at all, is it compiled in any way or interpreted directly?

Reply Score: 0

protomank Member since:
2006-08-03

Both Javascript and Dart are neither compiled or interpreted. They both use JIT (just in time compiler), that compiles the block/method/function that is being executed in memory. There are more variations of this method that browsers use actually, but this is the basic idea.

The thing is that, a non-organized language is much harder to optimize when compiling (even if using JIT), and Javascript was not designed to run games or keep executing in background during all time, while Dart is.

Reply Score: 6

lucas_maximus Member since:
2009-08-18
protomank Member since:
2006-08-03

"There are more variations of this method that browsers use actually, but this is the basic idea." - you see, it was just an example,. and it is dependent on the browser it runs in. Again, I did not said it was all JIT.

Reply Score: 4

lucas_maximus Member since:
2009-08-18

.Disclaimer: I am a C++ coder, but I do like C# syntax, I worked a lot with Javascript in commercial projects, and I know it is trash.


JavaScript isn't trash. I get fed up of this opinion.

The language has it quirks but is very flexible and it is mis-understood. Especially because C#/Java/C++ guys tend to try to write it like it is C#/Java or C++.

It the only language which I like programming these days.

Edited 2013-12-20 14:39 UTC

Reply Score: 5

protomank Member since:
2006-08-03

Let me clarify: it WAS a language I liked and loved. It grow up to be a ugly monster that eat little kids.

Take, for instance, its object/pseudo-class implementation, it is a nightmare if you are not the one who developed the original code - commong thing in industry, you will always ending with tons of old code someone else wrote and did not care to document. The lack of types, mostly in the object case, is also very bad for mantaining large pieces of code.

Also, it is very easy just say "people don't use the right way" and do not face the problem: people CAN use it in the wrong way very easily.

Reguards.

Reply Score: 5

lucas_maximus Member since:
2009-08-18

I seen horrible things done in Java and C# code bases, it isn't the language it the programmers and you can't blame the language.

Edited 2013-12-20 14:44 UTC

Reply Score: 3

protomank Member since:
2006-08-03

I bet I've seen worse thing in more "evolutionary" and flexible languages like C++ and PHP ;)

Reply Score: 2

Alfman Member since:
2011-01-28

lucas_maximus,

"I seen horrible things done in Java and C# code bases, it isn't the language it the programmers and you can't blame the language."

Obviously languages are subjective, but in principal there's no reason you cannot blame the language for it's cons just like protomank did. Ie having too many ways to do the same thing, confusing abstractions, just look at perl. Also, just because I can personally use the subset of the language that fits my personal preferences doesn't mean I won't have to use other code at times.

It's outright lousy that javascript doesn't have better namespace support. For both performance and coding standards, I prefer a language to have strict typing and static objects, yet with javascript I have no guarantees about any object. Even if I see where an object is declared, I cannot tell if an object has other properties dynamically added somewhere else using dynamic assignments and/or prototypes. I cannot prove the type of any variable without analyzing the entire JS codebase. Since nothing is statically enforced in the language, it makes it much more difficult to predict how a small snipit of code will execute without understanding the program as a whole. JS cannot effectively be "unit tested". This is a con not shared by static languages such as Java/C/C#/etc.

What makes javascript hard to predict for us as humans also affects the javascript JIT VMs too, which is the whole motivation behind asm.js - "don't use these features of js because we cannot convert them to static code".


I don't think javascript is so bad for how it's typically used, but I do think it is bad for the high performance and complete application programming environments that it's being pushed towards. When it comes to robustness, compilers are worth having since they can verify a great many problems that would not show up at all in a JS program until the faulty code executes. As always, the best answer it to choose the language that fits the project. Javascript often gets used because there's no other choice when it comes to native browser support. If I had a choice, it would probably be C#/mono.

Reply Score: 3

galvanash Member since:
2006-01-25

It's outright lousy that javascript doesn't have better namespace support.


That one I will totally agree with. It has caused no end of pain over the years and is something that could have been addressed and dealt with in the beginning.

The problem is not that JavaScript doesn't have them, in practice it does. Its just that there is no specific syntax for defining them. You can always do this:

var your_namespace = your_namespace || {};


And just go to town. The problem is there are like 500 variations of the above, no one agrees on which approach is "best", so there is no consensus on it.

The real problem though isn't a lack of namespaces (that really is mostly just background noise), it is the omission of any kind of concept of module loading... THAT is the worst problem in the language. There are patterns to deal with it, but again there are so many variations, and unfortunately with the modules concept the variations are almost never compatible...

Anyway, these are the kinds of things that make it bad for "structured" development - I personally don't think that dynamic typing and prototype-based OO are it's problems - those are arguably strengths, depending on how you look at it.

Reply Score: 3

Alfman Member since:
2011-01-28

galvanash,

And just go to town. The problem is there are like 500 variations of the above, no one agrees on which approach is "best", so there is no consensus on it.


I agree.

Also there are other practical problems that aren't strictly part of the language, but never the less impede development. An example I came across recently were the difference with XMLHttpRequest . All browsers except IE will start streaming data as soon as readystate>=3. IE throws an exception until readystate=4.

Opera and Chrome won't trigger readyState change until 1024 data bytes are received, from that point forward each additional packet triggers an event regardless of length. Safari and FF trigger as soon as any data is available. Consequently streaming AJAX requests need to be padded with useless characters just to get the client javascript portion to work.

I also found browsers work differently with regards to AJAX HTTP Origin policies. Safari in particular requires additional "preflight" requests, where as other browsers can usually use the http Origin header without an HTTP OPTION request, which can require extra configuration / programming for scripts that wouldn't normally expect an OPTION request.


Anyway, these are the kinds of things that make it bad for "structured" development - I personally don't think that dynamic typing and prototype-based OO are it's problems - those are arguably strengths, depending on how you look at it.


I'm a bigger fan of having a well defined OOP class and I like having a compiler check for errors, but it's just an opinion and ultimately you are right: it depends on how you look at it and what the project requirements are.

Reply Score: 3

lucas_maximus Member since:
2009-08-18

I've never run into these problems because I have a library do the hard work for me.

CORS with IE8 and IE9 support is a PITA, but that all you gotta worry about.

Edited 2013-12-21 12:23 UTC

Reply Score: 3

lucas_maximus Member since:
2009-08-18

Soo many patterns ...

http://addyosmani.com/resources/essentialjsdesignpatterns/book/

There isn't that many, they differ on the toolkit you are using ... but whatever form they are in it is the same basic principle.

Reply Score: 3

Lennie Member since:
2007-09-22

Maybe we should get back on topic: Dart

I don't think javascript is so bad for how it's typically used, but I do think it is bad for the high performance and complete application programming environments that it's being pushed towards.


And Dart is supposed to solve that ? Does it ?

I actually like asm.js approach better.

We all know people need system languages and scripting languages. Most of projects that use system language use both.

Examples: A lot of C-programmers use make in their projects. Many games have a the game logic written in Lua. And the game engine is more generic and handles all the performance critical parts.

You get Javascript and go with asm.js on parts of the code that really needs performance, like calculations.

You always use a compiler for system languages, so that is why asm.js is fine.

Obviously, Google has their solution for that called NaCl.

But here asm.js has the advantage again, it can run in any browser. It is a subset of Javascript which is easier to work with for the VM.

Years ago, Javascript was interpreted only and was 100s to sometimes 1000s times slower than native compiled. Now it's 10 times as slow (actually usually between 6 and 15). With asm.js, with just a few weeks of work, they got half as slow as compiled.

They think they can do a whole lot more. asm.js is like a bytecode. So all the optimizations Java and others use can then be applied to asm.js. And that byte code can still run in any browser (but slower of course).

People used to say, if only the browser supported my preferred language. Now asm.js exists and you can do that. People have also ported other scripting languages by compiling the runtime. Like the Python runtime.

Really, I see no use for Dart and NaCl to be supported in the browsers.

And with asm.js on the table, I see no other browser supporting Dart or NaCl.

Edited 2013-12-21 08:26 UTC

Reply Score: 4

Alfman Member since:
2011-01-28

Lennie,

"Maybe we should get back on topic: Dart"


Until Dart is natively supported by all browsers I want to target, I don't see myself using it. Maybe my preference for native (non-emulated) languages is overblown, but I doubt I'm alone. The situation is not so different from the Eiffel programming language we learned at university (which gets compiled into C).


"But here asm.js has the advantage again, it can run in any browser. It is a subset of Javascript which is easier to work with for the VM."

"Really, I see no use for Dart and NaCl to be supported in the browsers."


Something even better than Dart (or anything else) emulated in javascript, and perhaps even better than javascript itself, would be to have native support for something similar to LLVM within the browser, eliminating the intermediate javascript conversion all together. Finally we could have a great unified platform for both client and server side code.


"They think they can do a whole lot more. asm.js is like a bytecode. So all the optimizations Java and others use can then be applied to asm.js. And that byte code can still run in any browser (but slower of course)."


Without benefit of human readability, you might as well use a bytecode that's designed to be efficiently used as a bytecode. Or at least use a language with trivial grammar (such as Forth) that doesn't have any syntactic sugar and takes very little code to parse.

Unfortunately we are where we are not because it makes great engineering sense to have languages compiling down to javascript, plus complex optimization to compile that down further to native. The reason we are here is because when it comes to browsers, javascript is the starting point which we're largely stuck with.


"And with asm.js on the table, I see no other browser supporting Dart or NaCl."


Well, I think you're probably right that's the best we can expect. Better solutions are technically in reach, but corporate politics being what they are, javascript is going to have a unique role as the least common denominator for the foreseeable future.

Edited 2013-12-21 18:11 UTC

Reply Score: 3

Lennie Member since:
2007-09-22


""And with asm.js on the table, I see no other browser supporting Dart or NaCl."


Well, I think you're probably right that's the best we can expect. Better solutions are technically in reach, but corporate politics being what they are, javascript is going to have a unique role as the least common denominator for the foreseeable future.
"

I think you missed one thing: When Javascript is the bytecode and runs close to native performance you can compile any language LLVM supports for the browser. Even port existing runtimes of other scripting languages if you don't have a compiler/transpiler yet.

If there any language you prefer not on the list ?:

https://github.com/jashkenas/coffee-script/wiki/List-of-languages-th...

This works best with source maps, that minimized or compiled bytecode doesn't have to be completely useless for debugging:
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

Supported at least by Firefox, Opera and Chrome.

Also see this presentation:
http://kripken.github.io/mloc_emscripten_talk/#/
http://www.ustream.tv/recorded/29324270

(there is some annoying music in the start of the presentation which will go away after the first few minutes)

Edited 2013-12-22 00:23 UTC

Reply Score: 3

lucas_maximus Member since:
2009-08-18

I think a lot of programming languages get unfairly picked upon. JavaScript being one of them.

I've recently upgraded an application that been working for years that was VB.NET / .NET 1.1 and VB supposed to be this horrible language, that always creates bad software. The reason why most VB.NET stuff is crap because a lot of novices tended to code in it in the past ... the Language going forward is going to have feature parity with C#.

PHP is another one, it has crap syntax and has a ton of problems again, the community over the years have solved a lot of those problems, and with a bit of Googling you can build something decent.

Reply Score: 3

Alfman Member since:
2011-01-28

lucas_maximus,

"I think a lot of programming languages get unfairly picked upon. JavaScript being one of them."

I'm not sure what you are alluding to in this instance. Never the less, it's true that javascript has dynamic typing & object models and consequently it shares all the cons implied by such models. It's not javascript's fault per say, but it's that the dynamic model is appropriate for some tasks and not for others.

Hopefully none of that is controversial, the problem now is that more and more app development is being pushed into the browser, it's forcing more and more developers to use the dynamic model even in instances where compile time error checking was extremely practical for development.


"PHP is another one, it has crap syntax and has a ton of problems again, the community over the years have solved a lot of those problems, and with a bit of Googling you can build something decent."

PHP was developed by incompetent devs who made made numerous blunders year after year (many which should have been obvious to them). If any language deserves to get picked upon, it's PHP. After many years of compatibility breaking changes, It's admittedly getting better. Some problems, like a disregard for naming conventions in standard functions, may never get fixed. But at least they've got superb documentation.

Reply Score: 3

lucas_maximus Member since:
2009-08-18

Hopefully none of that is controversial, the problem now is that more and more app development is being pushed into the browser, it's forcing more and more developers to use the dynamic model even in instances where compile time error checking was extremely practical for development.


* Unit Tests
* JSHint
* "Use Strict"

You should be using these anyway. Also I fed up of this Static typing argument as it magically gets rid of errors in your program, It doesn't. You are still going to get runtime errors.

PHP was developed by incompetent devs who made made numerous blunders year after year (many which should have been obvious to them). If any language deserves to get picked upon, it's PHP. After many years of compatibility breaking changes, It's admittedly getting better. Some problems, like a disregard for naming conventions in standard functions, may never get fixed. But at least they've got superb documentation.


PHP is pretty good these days compared to the bad old days when I used PHP 4. Again the community has picked up where the language fails.

Need a routing solution for you application? use Flight.php, need a templating solution use mustache for PHP, need a datamapper use the PHPDataMapper project.

Edited 2013-12-23 18:27 UTC

Reply Score: 3

Soulbender Member since:
2005-08-18

with a bit of Googling you can build something decent.


You could build something decent with shell script cgi but that doesn't mean it's good or even acceptable.
PHP has gotten better but considering where it was starting from it still means it's awful.

Reply Score: 2

galvanash Member since:
2006-01-25

Take, for instance, its object/pseudo-class implementation, it is a nightmare if you are not the one who developed the original code


I respect your opinion, so please don't take offense.

Looking at JavaScript and calling its object models "pseudo-classes" demonstrates you have a strong bias towards class based languages. That's fine, to each their own - but prototype based inheritance is not an after-thought or a whim, it was absolutely intentional and is really kind of the fundamental point of JavaScript (it is, after all, a scripting language).

You can model virtually any OO concept (inheritance, polymorphism, encapsulation, Superclasses, subsclasses, factories, etc.) through two simple mechanism in JavaScript - cloning and prototype manipulation, and importantly, both are purely runtime operations...

I'm not saying this approach is necessarily better or anything, but it is powerful. People think of Javascript as a rather simple high level language when it fact it is the opposite - Javascript is like assembler for OO programming. It is actually an extremely low level language, because everything is built up through a very small handful of language features.

Javascript can be molded to work in a variety of ways, it is great for meta-programming, it is great for scripting, etc. It can be great for application programming, in much the same way that Python and Ruby are, but its low level nature makes it quite a bit more quirky. It probably isn't something you would want to classify as a "general purpose" language, but that doesn't make it bad.

commong thing in industry, you will always ending with tons of old code someone else wrote and did not care to document. The lack of types, mostly in the object case, is also very bad for mantaining large pieces of code.


JavaScript has types, it just doesn't have static typing...

I would argue (and have many times before) that static typing is primarily a performance optimization, not a feature. Thing is that there are two schools of thought on this, and I'm in the other one ;) A language that doesn't let me put whatever I want into a variable at runtime is, imo, broken. But that is because I mainly do meta-programming - and you can't really do meta-programming with static typing.

That said I understand the argument for it from the "don't let me shoot myself in the foot" point of view when doing applications/system level programming.

Also, it is very easy just say "people don't use the right way" and do not face the problem: people CAN use it in the wrong way very easily.


Ah... That is it in a nutshell I think. JavaScript biggest problem is it almost too flexible. Almost everyone uses it wrong. But when it is used right it can actually be quite elegant.

Reply Score: 3

protomank Member since:
2006-08-03

Hi, thanks for your reply, and I kinda of agree with it.
Yes, I like languages with a good class semantics, but I coded a lot in plain ANSI C before, so I'm experienced with both types.

Javascript could not add a complete class, with types that can be easily tracked from a function that uses it, surely, the language was never developed with that in mind, so it had to follow the path that was created.
That doesen't mean this is the best scenario, of course, and the debuggers in browsers help you to track types A LOT.

I don't pretend to spit in the dish I've eaten before (PHP and Javascript paid com CC degree), I like to play with javascript, I think some new features like web-sockets are incredible. It is just that, Dart is better in all aspects I've ever looked into.
To be honest, I wish javascript was "fixed" on its weak points instead of a new language to be created, but I do not believe it is possible to do so, while keeping backwards compatibility.

Reply Score: 2

galvanash Member since:
2006-01-25

Yes, I like languages with a good class semantics, but I coded a lot in plain ANSI C before, so I'm experienced with both types.


I think you may have missed my point. ANSI C has no OO features. You can of course using OO techniques in any language, even C, but the language itself wasn't designed with doing that in mind.

JavaScript was designed for OO programming, it just doesn't use the same mechanics as class based languages. In many ways it is in fact far superior to class based languages, at least from the point of view of flexibility.

Javascript could not add a complete class, with types that can be easily tracked from a function that uses it, surely, the language was never developed with that in mind, so it had to follow the path that was created.


It surely could have, but it didn't want to. Most of the things you find fault with are not mistakes, they are features...

You can model class based inheritance (even with typing) in a prototype based language quite easily - but you cannot do the inverse... Granted, it isn't static typing (there is no compile time checking), but adding tags to objects to denote their type and their ancestry is trivial - its just that no one does this because it really doesn't matter. As a javascript programmer, I don't really care what "type" an object is, because the only reason to care about that is to keep you, as a programmer, from doing something to it you "aren't supposed to do".

Type checking doesn't enable any functionality - it only removes it. The problem is there are entire classes of problem solving methods that when passed through the filter of type checking look like mistakes, when in fact they are not...

To be honest, I wish javascript was "fixed" on its weak points instead of a new language to be created, but I do not believe it is possible to do so, while keeping backwards compatibility.


Most of its weak points are honestly in syntax (minor things), not the kind of things you are mentioning - the fact that it is prototype based and dynamically typed are its strong points.

I don't personally have a problem with Dart, because Dart is a language intended for general purpose programming, specifically "structured" programming by teams. That is something that JavaScript is not so great for, and it does it in a way that doesn't break JavaScript - because it is a different language.

Fixing the "weak" points you describe in JavaScript would be, in my opinion, totally destroying the essence of the language.

Reply Score: 3

crystall Member since:
2007-02-06

The language has it quirks but is very flexible and it is mis-understood. Especially because C#/Java/C++ guys tend to try to write it like it is C#/Java or C++.


I agree. While JavaScript is not my favorite language it can be quite nice and effective but you have to change your mindset and best practices compared to C/C++ coding. I come from a full system-level C/C++ background and my first experiences with JS were horrible but after working with experienced JS coders for a while I came to love it. It needs some discipline to get things right but then again every language does.

Reply Score: 3

modmans2ndcoming Member since:
2005-11-09

Javascript is trash (and I write MUMPS/Cache Objectscript)

Reply Score: 1

Soulbender Member since:
2005-08-18

JavaScript isn't trash. I get fed up of this opinion.


Maybe it's just that combined with the awkwardness of html and css it's the trifecta from hell.

It the only language which I like programming these days.


You might need to seek professional help for that ;)

Reply Score: 2

RE: Not yet, but I really hope so
by twitterfire on Fri 20th Dec 2013 20:06 UTC in reply to "Not yet, but I really hope so"
twitterfire Member since:
2008-09-11


Disclaimer: I am a C++ coder, but I do like C# syntax, I worked a lot with Javascript in commercial projects, and I know it is trash.


I'm use both C# and C++ and I also like C# more because it seems cleaner, a little bit easier to do stuff in, and more readable. But while C++ has all the features of C# and more C# has less features.

I also like Java, for the same reasons I like C#.

What I wish is someone writing a compiler to compile C# to native language. I extensively tested C# against C++ and when it comes to do the heavy lifting, C++ is far ahead of C# with exe ngened or not.

I wouldn't say JS is complete trash but it is rather chaotic, averybody and their granny modifying the language. I'd even use Node.JS instead of PHP. For me, PHP sucks more.

Reply Score: 3

Wafflez Member since:
2011-06-26

C++ is far ahead of C# with exe ngened or not.

Well ngen only helps to launch software for the first time faster.

Reply Score: 3

Experience
by kvark on Fri 20th Dec 2013 13:06 UTC
kvark
Member since:
2013-12-20

I used dart for a project (http://kri-web.googlecode.com) in its early development days (pre-1.0). While it does increase the fragmentation on the web, it doesn't provide anything revolutionary to the table. It's still a dynamically typed language, with just a bit more OOP and modern programming idioms.

Now I'm a happy Rust programmer, looking for the moment it gets supported by NaCL, which is a much more promising piece of tech from Google then Dart.

Reply Score: 3

Dart == Google's VBScript
by moondevil on Fri 20th Dec 2013 14:22 UTC
moondevil
Member since:
2005-07-08

Until a customer request us to use it, I will ignore it.

Reply Score: 3

RE: Dart == Google's VBScript
by AndyB on Fri 20th Dec 2013 14:27 UTC in reply to "Dart == Google's VBScript"
AndyB Member since:
2013-03-22

Until a customer request us to use it, I will ignore it.

In the case of my customers, they couldn't care less what I code in as long as it works!

Reply Score: 3

RE[2]: Dart == Google's VBScript
by moondevil on Fri 20th Dec 2013 15:43 UTC in reply to "RE: Dart == Google's VBScript"
moondevil Member since:
2005-07-08

On my Fortune 500 consulting world, the customers are the ones calling the shots for what technology stacks get used.


We are a bit like hired guns, as long as the payment is ok, we use anything.

Reply Score: 3

...
by Hiev on Fri 20th Dec 2013 15:35 UTC
Hiev
Member since:
2005-09-27

I'm a Dart user, I've even have Dart code in production, I feel I'm more productive with it than with JavaScript, the optional typing is very Handy, it has its problems, but for a 1.0 reléase it is very usable.

Reply Score: 3

v Does anyone here use Dart?
by cipri on Fri 20th Dec 2013 18:26 UTC
Not particularly exciting
by lvl21ogre on Fri 20th Dec 2013 18:31 UTC
lvl21ogre
Member since:
2013-07-04

All we're going to get with Dart is one more so-so web language, except this one will run fastest in Google's browser (just as everyone else is finally catching up to V8). I'd rather they focus on asm.js, because that is basically a combination of the best of NaCl and Dart, and with Google's help it could certainly lose its worst aspects far more quickly. It also asks for far less of a commitment from browser vendors to simply optimize their existing engines rather than implement two large-ish Google-blessed specifications in order to get basically the same performance gains.

Reply Score: 3

There can be no good JavaScript
by Derbeth on Fri 20th Dec 2013 19:50 UTC
Derbeth
Member since:
2005-08-12

As a programmer I can say JavaScript is a horrible language, giving lots of subtle and hard to track ways to introduce bugs into code. Even its name is misleading, as it is completely unrelated to Java - Netscape engineers managed to fail even in this field. When you learn how to force JavaScript to create something like "inheritance" known to other programming languages, you come to realise just how ridiculous JS is. I don't think any other programming language used until today has its own libraries/higher level languages fixing JS broken syntax (Underscore, CoffeeScript) and websites like wtfjs.com.

I don't believe JS can be improved, because the industry believes it is the most important to keep the backward compatibility - so I don't think Google does something harmful to the Web trying to introduce Dart.

Reply Score: 1

Just tested it
by twitterfire on Fri 20th Dec 2013 19:55 UTC
twitterfire
Member since:
2008-09-11

I embedded Dart VM in a software to test Dart as a potentential scripting language. I was believing Google who said "it's soooo much faster than regular JavaScript."

Wasted my time. I'd rather use Mono or some kind of Java implementation as a scripting engine.

Reply Score: 2

Better Plan
by twitterfire on Fri 20th Dec 2013 20:10 UTC
twitterfire
Member since:
2008-09-11

1. Make a comitee
2. Throw away parts of JS which are trash
3. Add features if needed
4. Standardize
5. Name it JS 1x
6. Get approval from ISO/IEC
7. ???
8. Profit!

Reply Score: 3

RE: Better Plan
by Soulbender on Sun 22nd Dec 2013 13:10 UTC in reply to "Better Plan"
Soulbender Member since:
2005-08-18

2. Throw away parts of JS which are trash


So...starting from scratch it is then.

Edited 2013-12-22 13:11 UTC

Reply Score: 2

RE[2]: Better Plan
by lucas_maximus on Mon 23rd Dec 2013 08:36 UTC in reply to "RE: Better Plan"
lucas_maximus Member since:
2009-08-18

I really wonder if people would complain about Scheme as much ...

Reply Score: 3

RE[3]: Better Plan
by vivainio on Mon 23rd Dec 2013 16:39 UTC in reply to "RE[2]: Better Plan"
vivainio Member since:
2008-12-26

If you insist on 'lisp' on browser, you can use Clojurescript.

Reply Score: 2

RE[4]: Better Plan
by lucas_maximus on Mon 23rd Dec 2013 18:05 UTC in reply to "RE[3]: Better Plan"
lucas_maximus Member since:
2009-08-18

I'd rather use JavaScript because I am already very good at using it.

Reply Score: 2

RE[3]: Better Plan
by Soulbender on Tue 24th Dec 2013 04:21 UTC in reply to "RE[2]: Better Plan"
Soulbender Member since:
2005-08-18

Since I'm no fan of Scheme either...maybe, although my frustration with JS is probably tied to how frustrating it is to work with the DOM.
At least it's not that random collection of C-library function wrappers known as PHP.

Reply Score: 2

RE[4]: Better Plan
by lucas_maximus on Tue 24th Dec 2013 11:48 UTC in reply to "RE[3]: Better Plan"
lucas_maximus Member since:
2009-08-18

although my frustration with JS is probably tied to how frustrating it is to work with the DOM.


Use jQuery, problem solved.

Reply Score: 2

RE[5]: Better Plan
by Soulbender on Tue 24th Dec 2013 21:49 UTC in reply to "RE[4]: Better Plan"
Soulbender Member since:
2005-08-18

Yeah, because "chain ALL the functions calls" is an awesome philosophy for readable and maintainable code....
That said, JQuery does make things less awful but it's still goddamn awkward.

Reply Score: 2

RE[6]: Better Plan
by lucas_maximus on Tue 24th Dec 2013 21:54 UTC in reply to "RE[5]: Better Plan"
lucas_maximus Member since:
2009-08-18

Yeah, because "chain ALL the functions calls" is an awesome philosophy for readable and maintainable code


Nobody makes you do that. It is just there when it is useful.

Edited 2013-12-24 21:54 UTC

Reply Score: 2

RE[7]: Better Plan
by Soulbender on Wed 25th Dec 2013 04:57 UTC in reply to "RE[6]: Better Plan"
Soulbender Member since:
2005-08-18

Nobody makes you do that. It is just there when it is useful.


Yes I know but it's such prevalent mindset, even in the official documentation, that you'd be hard pressed to find any code that doesn't.

Reply Score: 2

if it has better syntax
by modmans2ndcoming on Fri 20th Dec 2013 23:38 UTC
modmans2ndcoming
Member since:
2005-11-09

if it has better syntax and a better DOM then I say bring it on!!

Reply Score: 2

Yes
by olafg on Mon 23rd Dec 2013 01:19 UTC
olafg
Member since:
2010-05-27

Yes, I use Dart. It is currently the only sane development environment for web applications. Javascript just does not cut it once you reach 1000 lines.

Reply Score: 1