How will the semantics of Dart impact the generated code by the DDC?

[Joao Pedrosa]

Hi all,

I'm trying to imagine life with the new compiler that will take types as hints

when generating the JavaScript code. TypeScript also takes types as hints,

but unlike Dart, TypeScript can enjoy semantics that are shared with

JavaScript. Dart for example implements its own versions of map, arrays,

etc right? Even with the effort to match the clean code that TypeScript

generates, I'm wondering about the slight bloat caused by differences in

semantics.

Say you use Dart to create a couple of JavaScript libraries, and each one of

them would bring some common code, like the custom implementations of

map and so on.

I also have no idea about what it would happen with Dart's custom

implementation of the HTML APIs. Which increase the differences of

semantics.

Dart has been losing the runtimes. We lost the Dart on the browser. And

folks thought it was great since the dart2js would improve. We have now

also lost the Dartino [1] runtime. And folks maybe thought it was great since

more focus would go into other more popular runtimes.

We can hope that Dart will succeed with Flutter, Fuchsia, AoT, Dartweb etc.

But Dartweb which was the focus of this post seems to have become one

more and the writing could be on the wall with TypeScript. TypeScript 2

is hyping up non null types and my only concern with TypeScript seems to

be slow compilation, but I can't tell yet since I may start using it just now.

If Dartweb is gone tomorrow, some folks would again be happy "well we

can all focus on TypeScript instead."

Cheers,

Joao

[1] - https://groups.google.com/forum/#!msg/dartino-discuss/U3fzZjoOdKg/0CB8ON6RCAAJ

[Filipe Morgado]

I'd rather have a language with clean semantics that targets a lot of platforms, than being semantically bound to JS.

It's easy to be TypeScript, they only target JS. But they can't go where Dart can.

Also, I can't imagine Google supporting TypeScript. Most big IT companies have their own language and software stack. I don't know any alternative within Google that comes anywhere near Dart in a lot of imports aspects. And I don't think Google is fooling around with Fuchsia and Flutter.

If you run your code only in a JS engine, maybe TS is more focused for what you need. But it still depends on your criteria.

IMO, anything that extends JS is a mess.

And I like Dart's dev cycle and tooling. I'm not giving that up so others find my compiled code more appealing.

My 0.02 cts :P

[Danny Tuppeny]

I'm a big fan of Dart for server-side stuff, but I do feel it's fallen way behind TS for the browser. Yes, it's semantics are nicer, but TS is on the verge of having non-null, union types and really nice type checking (narrowed types based on conditions, etc.). AFAIK we don't even have any idea if/when Dart will get non-null or union types :-(

--
For other discussions, see https://groups.google.com/a/dartlang.org/

For HOWTO questions, visit http://stackoverflow.com/tags/dart

To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Alec Henninger]

> AFAIK we don't even have any idea if/when Dart will get non-null or union types :-(

Non-null types are undergoing experiments now: https://github.com/dart-lang/sdk/issues/27231

[Danny Tuppeny]

On Sat, 3 Sep 2016 at 17:45 Alec Henninger <aleche...@gmail.com> wrote:

> AFAIK we don't even have any idea if/when Dart will get non-null or union types :-(

Non-null types are undergoing experiments now: https://github.com/dart-lang/sdk/issues/27231

Good spot! Very Interesting! Nulls are my biggest complaint with almost every language; we've known how stupid forced nulls are forever and we keep churning out languages that have them!

Let's hope it all goes well and we're not waiting many more years for it!

[Filipe Morgado]

On Saturday, 3 September 2016 17:45:56 UTC+1, Alec Henninger wrote:

Non-null types are undergoing experiments now: https://github.com/dart-lang/sdk/issues/27231

YAY!

Too bad it's not coupled with union types. >.<

It's fundamentally the same feature.

On side note, it seems people sometimes forget that Dart is not only a programming language. It's a programming environment.

Although it's simple and easy to learn, I'm not a big fan of the language itself. It's missing expressiveness and boldness, IMO.

But I'm a big fan of the SDK, observatory, analyzer, the VM ... pretty much everything else but the language.

Kudos to the Dart team on that one.

I recognize that it's not easy to add language features without compromising simplicity and learning curve, but I have high hopes for Dart 2.0 :P

[Danny Tuppeny]

On Sat, 3 Sep 2016 at 20:15 Filipe Morgado <pix...@gmail.com> wrote:

On Saturday, 3 September 2016 17:45:56 UTC+1, Alec Henninger wrote:

Non-null types are undergoing experiments now: https://github.com/dart-lang/sdk/issues/27231

YAY!

Too bad it's not coupled with union types. >.<

It's fundamentally the same feature.

I'm sure someone on the Dart Team (Bob?) said it would be silly not to implement it the same union types (eg. type? is just sugar for type|null) so I have faith that union types will follow on :-)

[Erik Ernst]

On Sat, Sep 3, 2016 at 10:08 PM, Danny Tuppeny <da...@tuppeny.com> wrote:

On Sat, 3 Sep 2016 at 20:15 Filipe Morgado <pix...@gmail.com> wrote:

On Saturday, 3 September 2016 17:45:56 UTC+1, Alec Henninger wrote:

Non-null types are undergoing experiments now: https://github.com/dart-lang/sdk/issues/27231

YAY!

Too bad it's not coupled with union types. >.<

It's fundamentally the same feature.

The current experiment is focusing on syntax only, but when we get to the semantics I find it both likely and attractive to model a nullable type as a union with `Null`. We haven't committed to user-specifiable union types at this point, though.

I'm sure someone on the Dart Team (Bob?) said it would be silly not to implement it the same union types (eg. type? is just sugar for type|null) so I have faith that union types will follow on :-)

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Erik Ernst  -  Google Danmark ApS

Skt Petri Passage 5, 2 sal, 1165 København K, Denmark

CVR no. 28866984

[Bob Nystrom]

On Mon, Sep 5, 2016 at 1:38 AM, 'Erik Ernst' via Dart Misc <mi...@dartlang.org> wrote:

Too bad it's not coupled with union types. >.<

It's fundamentally the same feature.

The current experiment is focusing on syntax only, but when we get to the semantics I find it both likely and attractive to model a nullable type as a union with `Null`.

I'll second this. The semantics we have in mind treat nullable types as a union type, and everything else naturally falls out from that.

We haven't committed to user-specifiable union types at this point, though.

Right.

Union types are appealing, as are intersection types, but having them is a general purpose type system feature is a big change with a lot of consequences to work through. I could see us doing it, but it's a ton of work and we have a lot of other stuff to get through too. It's also not clear to me how much real value they provide in end user code. My intuition is that most cases where union types would be used would be better served by overloading.

Cheers!

– bob

[John Messerly]

On Sat, Sep 3, 2016 at 7:41 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

I'm a big fan of Dart for server-side stuff, but I do feel it's fallen way behind TS for the browser. Yes, it's semantics are nicer, but TS is on the verge of having non-null, union types and really nice type checking (narrowed types based on conditions, etc.). AFAIK we don't even have any idea if/when Dart will get non-null or union types :-(

TypeScript is (intentionally) unsound though, so that's one big thing you can get from strong Dart.

For example, if you say "message: string" in TypeScript, "message" could be absolutely anything when you (your users) run the application. And there's no guarantee of an error if it's not a string, you could get a silent implicit coercion somewhere (much) later on.

[Danny Tuppeny]

On Tue, 6 Sep 2016 at 18:27 'John Messerly' via Dart Misc <mi...@dartlang.org> wrote:

TypeScript is (intentionally) unsound though, so that's one big thing you can get from strong Dart.

Sounds except for nulls :P

For example, if you say "message: string" in TypeScript, "message" could be absolutely anything when you (your users) run the application. And there's no guarantee of an error if it's not a string, you could get a silent implicit coercion somewhere (much) later on.

Sure; I'm not saying TS is better but it's definitely way ahead of Dart in some places (non-nulls, unions, type narrowing and even a working incremental compiler that outputs nice JS ;-))

[John Messerly]

Yeah, I think the advantage Dart will have with non-null is we'll be able to make it the default, and have it work great with the core libraries. Whereas JS language/libraries are a lot harder to retrofit. But yeah, they're different approaches with different tradeoffs, feel free to choose what works best for you :)

--

[Don Olmstead]

Unions are used pretty heavily in the WebIDL https://www.w3.org/TR/WebIDL/#idl-union. That would potentially be a big plus of having them.

[Danny Tuppeny]

On Tue, 6 Sep 2016 at 20:50 'John Messerly' via Dart Misc <mi...@dartlang.org> wrote:

Yeah, I think the advantage Dart will have with non-null is we'll be able to make it the default, and have it work great with the core libraries.

Sure; if Dart gets those things, it'll absolutely be better. But at the moment it's not clear if/when, whereas TS is in the verge of releasing it!

 

Whereas JS language/libraries are a lot harder to retrofit. But yeah, they're different approaches with different tradeoffs, feel free to choose what works best for you :)

I'm writing Dart editor extension in TypeScript! Not sure if I'm getting the best or worst of both =)

Switching between the two is quite annoying (private vs _, e => thing vs  (e) => thing, (x, y) => { } vs (x, y) { })!

[Joao Pedrosa]

Hi Filipe,

On Sat, Sep 3, 2016 at 10:28 AM, Filipe Morgado <pix...@gmail.com> wrote:

I'd rather have a language with clean semantics that targets a lot of platforms, than being semantically bound to JS.

It looks we though we are bound to the JavaScript runtime more than anything. It is difficult to impose a new runtime

on others. And even within a single company it may be inconvenient to fight a battle to insert a second runtime as

we have seen it with Dart. The path of least resistance then always leads back to JavaScript.

 

It's easy to be TypeScript, they only target JS. But they can't go where Dart can.

It's not too easy for them either. I was watching a recent video with Anders Hejlsberg [1] and he said that TypeScript

can only works its magic for the frontend side of the compiler. The backend which is what you may want out of a

compiler with faster code and so on may have to wait. Still, I was left wondering when Microsoft would have some

kind of backend for their TypeScript code.

TypeScript generated code needs to interface with a plethora of code that exists only in JavaScript. Sometimes their

type definitions may not even cover all of the possible combinations, so we may need to extend things on an adhoc

basis to make them visible to the TypeScript compiler. For example, NodeJS has APIs that work with a file name,

a buffer or a file descriptor id number. And the type definition focused more on the file name at times as it was the

most common one. I extended one to add the file descriptor id number call. [2]

 

Also, I can't imagine Google supporting TypeScript. Most big IT companies have their own language and software stack. I don't know any alternative within Google that comes anywhere near Dart in a lot of imports aspects. And I don't think Google is fooling around with Fuchsia and Flutter.

Google is plenty happy to make use of TypeScript. In their view TypeScript is a free tech that they can use

themselves. Of course, Google has to treat it carefully so that they don't come to depend on Microsoft's will like

they have had with Java and Oracle. So there may be some caution when using trademarks that belong to Microsoft

and so on. TypeScript could also be seen as a practical research experiment that will empower everybody.

I think that once Fuchsia becomes established, that they may allow JavaScript to run on it based on their V8 engine.

Either that or it would become another community project.

Dart does serve as an example to others when it comes to static code and static declaration of code. JavaScript code

has just recently started to get some declarative modularity with the ES6 modules and it has been a painful transition

to them. I saw some discussion they had about it and it went on for over 600 comments and they weren't able to solve

it.

 

If you run your code only in a JS engine, maybe TS is more focused for what you need. But it still depends on your criteria.

IMO, anything that extends JS is a mess.

TypeScript can be compiled automatically to JS with the help of their editor and compiler. In some ways it reminds me

of the early days before pub took it over in Dart. The catch is that we'd like to share code between TypeScript, the browser

and the NodeJS, and I don't know of a better approach yet for that than just trying to use Webpack. Angular 2 JavaScript

has started to use a custom compiler and also Webpack.

Webpack is this thing that is at the heart of the JS ecosystem. What it does covers so many bases that it is even

hard to explain it. React for example is often found coupled with Webpack. Webpack understands the old module

style that is extremely imperative and the new ES6 module that is more declarative, I think. Webpack then funnels

all of the files that are necessary for running a web application to the browser. I think it becomes necessary when

you are trying to reuse code from other modules that you have not published on your web server of choice.

Which happens often with JavaScript and NodeJS.

As some developers like to say, distributing your application may be the hardest thing to do. And Webpack may be

the MVP of the JS ecosystem when it comes to packaging up one's application. The JS ecosystem may be a mess

that only Webpack can make sense of. But then you could restrict yourself to the browser only and have TypeScript

with a packaging tool called Rollup that compiles the code into a single JavaScript. For simple applications this last

resort may be the way to avoid the Webpack way. Here's the catch though, we all want to bring components to the

web, which would mean an explosion of code and dependencies, and then something like Webpack would be the

way to go. The Progressive Web Application that Google wants to support needs to come up with an alternative to

Webpack soon!

 

And I like Dart's dev cycle and tooling. I'm not giving that up so others find my compiled code more appealing.

Dart has nice features. But without runtimes to make full use of them, it's just not competitive all the time.

My 0.02 cts :P

Thanks!

Cheers,

Joao 

[Filipe Morgado]

Hi João,

Quite a post you wrote and you're making quite a good case for TypeScript.

I don't know WebPack, it's probably great.

But that highlights the plethora of non-standardized tools one has to use to make sense of a JS source code.

Quite a steep learning curve to get structure.

Also, you seem to focus only on the web. There I agree that JS is there to stay. There's no putting another runtime there.

But, I'm using Dart mostly on the server, so I get to use the Dart runtime.

And I'm looking forward to try Flutter, there's a Dart runtime there as well.

My client side is mostly Dojo (old version) and Flash. That's what I use at work, I'm too familiar with both and bad habits die hard (well Flash for mobile is hard to replace).

But when I throw myself into Angular Dart and the like, I'll be glad to be able to share a lot of code with other platforms and get the same development experience.

In the end, it's not about the runtime.

OK, it's nice to have a dedicated one and get at least 2x the performance of JS when we can.

It's about productivity and ease of development.

Sane language semantics and unified tooling is a must.

Even if it produces sub-optimal code for a single platform.

Anyone who needs performance is not running in a browser anyway.

I still agree with you that TypeScript is probably a safer bet for those who only need to target the web (node.js doesn't count, it's even messier).

It's no wonder it's successful.

But IMO Dart offers so much more.

Again ... my opinionated and speculative 0.02 cts :P

[Joao Pedrosa]

hi Filipe,

Also, you seem to focus only on the web. There I agree that JS is there to stay. There's no putting another runtime there.

But, I'm using Dart mostly on the server, so I get to use the Dart runtime.

And I'm looking forward to try Flutter, there's a Dart runtime there as well.

I know that the web is kind of stalling when compared to the exponential growth of mobile. For example, I'm still

trying to make sense of Google deciding the deprecate the Chrome apps, even if it was a niche market. As it helped

to encourage developers to migrate to web tools. Electron as an alternative is not the same thing, as it makes it harder

to cover all of the Chrome platforms at the same time.

Google deciding to market the "Progressive Web App" is still a work in progress. From what I've seen so far, developers

are still skeptical about it.

I don't think that it's in Apple's heart to bring Swift to all platforms out there. The LLVM toolset is just too big a dependency

for community projects to deal with. For example, the Swift package manager depends on Clang to deliver static

packages and so on. Go by comparison can create cross-platform deployment very easily, fortunately for Go!

JavaScript can compete with those languages when it comes to reaching out platforms. With React Native they can

even grow outside of the browser environment. Mostly though, JavaScript is a stable platform to build on top of.

It is annoying when languages change too much between releases. I recently had the experience of having to

edit perhaps around 3% of the lines of some Swift projects to update them from 2x to 3x. It is true that static typing

points to where we need to edit, but they are still working on having a stable ABI in order to support modules.

In JavaScript they have source code compatibility and ABI compatibility, even if many developers would live to break

those in order to "fix" JavaScript. JavaScript makes up for a great deposit of code. JavaScript can work even when

the APIs don't match, so long as the APIs don't get called either, due to late binding. When Microsoft created their

systems they used to use a module around COM that was dynamic. Nowadays, JavaScript may serve about the

same purpose.

In Dart we went with static declaration of code and for the most part we also had type checking. While that helped

Dart to become a better compilation language, we may have stopped being able to compete with the dynamic

parts of JavaScript. Dart is in the same boat of C#, ActionScript and so on. There is likely a reason that none of

those languages were ever chosen when cross-compiling into JavaScript. Mapping out different semantics to

JavaScript becomes too costly and in the end it may never map well enough. For example, JavaScript does not

have int type. Even if JavaScript may have been acquiring more types as of late, so who knows?

 

My client side is mostly Dojo (old version) and Flash. That's what I use at work, I'm too familiar with both and bad habits die hard (well Flash for mobile is hard to replace).

But when I throw myself into Angular Dart and the like, I'll be glad to be able to share a lot of code with other platforms and get the same development experience.

I recall Dojo. I once tried Flash and its data grid was so slow at the time. Flash was optimized for different

things, graphics...

I'm not yet sure about what kind of code sharing we'll have with Dart. Dart is in some ways on the same boat

as TypeScript, in that if you use Dart to target the browser, you may have to avoid calling code that is not available

on the browser or that messes it up. For example, now that Dart is focusing on the compiler rather than the

runtime, we are asked to avoid using Mirror. Considering that Dart makes declarations static and is not

entirely dynamic like JavaScript, choosing what libraries to use can have a lasting effect. JavaScript is like

having a C preprocessor on, all the time. Whereas in Dart we don't have that kind of self-changing code.

One of the good aspects of static code declaration is that it can help with security. Many developers choose

security over features. Even if that can bite us back from time to time, like when Apple restricted JIT on

their platforms.

 

In the end, it's not about the runtime.

OK, it's nice to have a dedicated one and get at least 2x the performance of JS when we can.

The runtime is the reason that if Dart had it, Dart would be 2x faster than JavaScript. And without it and

when we cross-compile to JavaScript, Dart can be 2x slower instead, unless we start writing hot code in

JavaScript and call it from Dart. I once had a small piece of code in Dart that if it was in JavaScript, it

would have made that difference. But if we depend on JavaScript code from Dart, that again restricts

the platforms that the Dart code could run on. Unless we had 2 versions of it.

 

It's about productivity and ease of development.

Sane language semantics and unified tooling is a must.

Even if it produces sub-optimal code for a single platform.

Anyone who needs performance is not running in a browser anyway.

A lot of people would beg to differ there. As Anders Hejlsberg said, users are quick to notice a 100ms

difference. There is a story about one of the Google founders being able to tell how long a query took.

Once JavaScript became fast, the DOM started to become the bottleneck. The DOM was just difficult

to master. Games that chose to the DOM never worked well enough. Nowadays though there is the

WebGL and who knows something might come out of it, even if mobile is strangling it.

 

I still agree with you that TypeScript is probably a safer bet for those who only need to target the web (node.js doesn't count, it's even messier).

It's no wonder it's successful.

But IMO Dart offers so much more.

Again ... my opinionated and speculative 0.02 cts :P

With more users, Dart could work out the kinks out of the platform. Before there was NodeJS, they

used to use just a small JavaScript runtime. It was used for a simple REPL or some quick test. It took

a community to come up with NodeJS. Large companies just have different goals. Google measures

its goals in the millions and billions. It's hart to be in the 1k-100k range.

Cheers,

Joao

 

[Filipe Morgado]

Hi,

Responding late, I've been out.

I've taken your point ... just a few comments.

On Wednesday, 7 September 2016 06:29:27 UTC+1, Joao Pedrosa wrote:

JavaScript can compete with those languages when it comes to reaching out platforms. With React Native they can

even grow outside of the browser environment. Mostly though, JavaScript is a stable platform to build on top of.

JS is here to stay, it's stable and browsers are obligated to run code written 10 years ago.

But when you start a new project, or new modules, you don't care about backward compatibility.

Even if the Dart language changes, the semantics are so simple that it's easy to write tools to upgrade your code.

And, given that you target only browsers, you Dart code will keep running just the same.

I recall Dojo. I once tried Flash and its data grid was so slow at the time. Flash was optimized for different

things, graphics...

That DataGrid was from Flex, a full-featured but poorly written framework. That's a different beast.

Flex would have been slow even if it was written in C.

I'm not yet sure about what kind of code sharing we'll have with Dart. Dart is in some ways on the same boat

as TypeScript, in that if you use Dart to target the browser, you may have to avoid calling code that is not available

on the browser or that messes it up.

It seems your goal is to write libraries that other people can use in the browser.

In that case, Dart may not be your best choice. 

I'm not familiar with DevCompiler, so maybe it is your best choice.

But if you have your own project, you don't care about that.

You can use any JS library through jsInterop.

If you're alone, or in a small team, Dart makes you a lot more productive and it's a LOT easier to share code within the team.

If you're in a big team, Dart is similar to Rust, it prevents interns or newcomers from crewing with your assumptions.

We all know it's so easy to abuse prototypes, global variables and so on.

The runtime is the reason that if Dart had it, Dart would be 2x faster than JavaScript. And without it and

when we cross-compile to JavaScript, Dart can be 2x slower instead

I believe there are specific case where Dart is slower than JS, specially where Dart semantics have to be preserved.

But the last time I saw an official benchmark (they brought it down since then), compiled Dart code was outperforming idiomatic JS.

And I believe compiled Dart will be pretty much equivalent in the most common cases.

But if you care about performance that much, maybe you shouldn't use JS O.o

 

A lot of people would beg to differ there. As Anders Hejlsberg said, users are quick to notice a 100ms

difference. There is a story about one of the Google founders being able to tell how long a query took.

Once JavaScript became fast, the DOM started to become the bottleneck. The DOM was just difficult

to master. Games that chose to the DOM never worked well enough. Nowadays though there is the

WebGL and who knows something might come out of it, even if mobile is strangling it.

Like I said ... I doubt you'll be getting any noticeable performance difference by using Dart.

And if you do, I believe the Dart team will be quick to fix it.

Dart does have a heavy runtime when translated to JS.

Not that heavy when compared to JQuery, and actually lighter when compared to others.

But it still gets the blame.

If you need a really fast load time, I agree, you shouldn't be using Dart. But you won't be using anything at all.

You'll write pure HTML/CSS with minimal vanilla JS. Even then, your bottleneck are probably images.

I don't see much pages that do a full fetch on every click, nowadays.

Dart for the web is mostly for single-page apps.

Trust me, users don't care much if the first load a little longer, as long as navigation within you site is smooth.

Anyway ...

I'm a guy that has written a substantial amount of code in C#/Java/PHP/JS, using a few libraries/frameworks

(JS and PHP being the ones I always cursed at).

Then, I've finally found a language that satisfies my needs and in which I feel quite productive

Comes another guy telling me that I'm wrong, that the tool I'm using has no future, even though I'm building stuff with it right now.

Of course I won't take it lightly ... specially when they're trying to sell me another tool which I cursed at quite a few time.

It's amazing how emotional a programmer can get about its tools.

EDIT: typos

[Joao Pedrosa]

Hi Filipe,

On Wednesday, 7 September 2016 06:29:27 UTC+1, Joao Pedrosa wrote:

JavaScript can compete with those languages when it comes to reaching out platforms. With React Native they can

even grow outside of the browser environment. Mostly though, JavaScript is a stable platform to build on top of.

JS is here to stay, it's stable and browsers are obligated to run code written 10 years ago.

But when you start a new project, or new modules, you don't care about backward compatibility.

Even if the Dart language changes, the semantics are so simple that it's easy to write tools to upgrade your code.

And, given that you target only browsers, you Dart code will keep running just the same.

I think both Dart and TypeScript are waiting for browsers to implement the async features so that they can

more easily adopt it. At the same time, I came across a quote from a JavaScript developer who said that

we'll be transpiling forever. Imagine that browsers do get async. We'll still have to support older browsers. So it would

be a perhaps 2 or 3 transpiling layers before it was final and ready for end-users. Dart developers have even 

hinted at perhaps generating TypeScript code from the DDC. So we could get something like

Dart > TypeScript > ES6 > ES5. Weeeeeeee! But even just 2 or 3 steps would be a lot to cope with. Right now in

TypeScript, I'm imagining it like TypeScript > ES5 with ES6 modules > ES5 bundle.

I think more tools will support TypeScript natively, so one day they could have TypeScript > ready to use ES5.

A lot of the challenge that the web faces when compared to the server and desktop is simply the unfairness of

having to create super small packages. JavaScript has coped with it by being super smart about delaying parsing

work and so on. But it needs to be aided to keep up with the underpowered mobile networks and devices still, 

which compounds the unfairness of it all.

With Dart we can create relatively compact packages. But one could challenge Dart to make them even smaller.

A mismatching semantics with JavaScript does not help Dart with keeping the packages smaller though. Both

TypeScript and the ES6 modules gives JavaScript a chance to cut back on the amount of code that they need

to ship, which can make them more competitive with Dart.

 

I recall Dojo. I once tried Flash and its data grid was so slow at the time. Flash was optimized for different

things, graphics...

That DataGrid was from Flex, a full-featured but poorly written framework. That's a different beast.

Flex would have been slow even if it was written in C.

Yes, it was Flex. But Flash was known to peg the CPU to 100%. Game engines are very much resource hungry.

Mobile games get away with it because only one game is active at any time. I was watching a recent video

with Lars Bak and Kasper Lund [1] and at one point they reminded us that browsers used to kill the JavaScript

process if it took too long to process something. I think that browsers can still get annoyed at long running scripts

though. It is one of the downsides of trying to use the browser for anything other than showing HTML.

A lot of the downsides of browsers with JavaScript would still affect the WebAssembly/asm.js approach, I'd

take a guess. For example, a recent annoyance for me with the browser was when the browser started delaying

the playing of sound once JavaScript took it over from Flash. So I'd start the browser alarm that I had created,

and I'd miss the alarm since the browser wasn't able to play it. I workaround it now by remembering to play

the sound when I set the alarm, which allows the browser to play it again when it's time and I can do other stuff

with the browser until then.

 

I'm not yet sure about what kind of code sharing we'll have with Dart. Dart is in some ways on the same boat

as TypeScript, in that if you use Dart to target the browser, you may have to avoid calling code that is not available

on the browser or that messes it up.

It seems your goal is to write libraries that other people can use in the browser.

In that case, Dart may not be your best choice. 

I'm not familiar with DevCompiler, so maybe it could be your best choice.

But if you have your own project, you don't care about that.

You can use any JS library through jsInterop.

If you're alone, or in a small team, Dart makes you a lot more productive and it's a LOT easier to share code within the team.

If you're in a big team, Dart is similar to Rust, it tries to prevent interns or newcomers from crewing with you assumptions.

We all know it's so easy to abuse prototype and global variables.

I've been thinking about the DevCompiler. But like I said above, I think the Dart team may be waiting for 

JavaScript to get async features so that they can more easily transpile to JavaScript then. But we'd still

be 1 or 2 transpilations away from the final output.

It is a challenge to use interop when calling to JavaScript. JavaScript just has way too many APIs that we'd need

to call into. For example, Dart users have demonstrated interest in the NodeJS and Electron APIs. And before that,

Dart users may have tried to use the APIs from the Chrome Apps. And then we also have all of the JavaScript

libraries that we could make use of.

If we are going to be using the DDC, Dart may have to support its libraries in the JavaScript layer by perhaps

compiling them with the DDC. Then other Dart programs could make use of them without having to import them

on an individual basis. But once we get to the JavaScript side of things, we'd be back to having to use the

JavaScript tools to package up, test and so on.

 

 

The runtime is the reason that if Dart had it, Dart would be 2x faster than JavaScript. And without it and

when we cross-compile to JavaScript, Dart can be 2x slower instead

I believe there are specific case where Dart is slower than JS, specially where Dart semantics have to be preserved.

But the last time I saw an official benchmark comparison (they brought it down since then), compiled Dart code was outperforming idiomatic JS.

And I believe compiled Dart will be pretty much equivalent in the most common cases.

But if you care about performance that much, maybe you shouldn't use JS O.o

I recall those comparisons. Dart had some advantage when it came to OO code. For example, the Dart

benchmarks used a lot of "method" calls. But when it gets to for loops and the like, with numeric computation,

Dart also had code called "interceptors" that could impact the execution time, together with out of bounds

checks and so on. Dart also traded a little performance in order to create smaller packages. So they used

meta-programming when generating the classes at runtime.

With modern JavaScript tools, they generate code that is friendly to the JavaScript runtime. I think for example

that ES5 prototype chain is still the fastest way to create classes in JavaScript. Because JS was very optimized

to it. JS also does not check for out of bounds on its JS layer at least. So for example there is no need to

have smart hoisting out of the loops. Although the JS VM can do that optimization later on.

One problem with current JavaScript tools though is that their methods may still handle parameters of different

types on the same slot, which may cause the VM to deoptimize it and generally screw it up. With TypeScript though,

we start to be encouraged to have single type parameters.

 

JS kicks butt when it comes to performance. When we compare it to other scripting languages. The amount

of optimizations that went into JS just make it impossible for the other popular scripting languages to match it.

For example, JS compiles the RegEx to native code. Simple for loops may put JS ahead of all of the other ones.

Mostly though, the amount of scrutiny that goes into every JavaScript VM release due to its immense popularity

makes it sure that if any slow down happens, it could be caught up and fixed. NodeJS these days helps to keep

the browser VM honest. When Dart had the benchmarks up, we could see that the JS VM was catching it up!

 

A lot of people would beg to differ there. As Anders Hejlsberg said, users are quick to notice a 100ms

difference. There is a story about one of the Google founders being able to tell how long a query took.

Once JavaScript became fast, the DOM started to become the bottleneck. The DOM was just difficult

to master. Games that chose to the DOM never worked well enough. Nowadays though there is the

WebGL and who knows something might come out of it, even if mobile is strangling it.

Like I said ... I doubt you'll be getting any noticeable performance difference by using Dart.

And if you do, I believe the Dart team will be quick to fix it.

Dart does have a heavy runtime when translated to JS.

Not that heavy when compared to JQuery, and actually lighter when compared to others.

But it still gets the blame.

If you need a really fast load time, I agree, you shouldn't be using Dart. But you won't be using anything at all.

You'll write pure HTML/CSS with minimal vanilla JS. Even then, your bottleneck are probably images.

I don't see much pages that do a full fetch on every click, nowadays.

Dart for the web is mostly for single-page apps.

Trust me, users don't care much if the first load a little longer, as long as navigation within you site is smooth.

I agree that Dart has an easier time with the SPA. It becomes too heavyweight otherwise. But then we have

these mobile efforts to bring down the size of the packages. SPAs even in JavaScript are just too wasteful.

Google are always striving to make the web more mobile friendly. Then we have the need for polyfills to

support the older browsers.

Even JS has to try harder to bring down the size of their packages. I think the closure tools could try to make

use of TypeScript and give it the treatment of statically declared code. Maybe even Microsoft could at some

point come up with their own version of the "closure tools" for TypeScript. For now, Microsoft has done well

by showing that TypeScript can be compiled to neat JavaScript code. But that would not stop them from

coming up with a highly minified and obfuscated version of it for deployment purposes!

 

Anyway ...

I'm guy that has written a substantial amount of code in C#/Java/PHP/JS, using a few libraries/frameworks

(JS and PHP being the ones I always cursed at).

Then, I've finally found a language that satisfies my expectations and in which I feel quite productive

Comes another guy telling me that I'm wrong, that the tool I'm using has no future, even though I'm building stuff with it right now.

Of course I won't take it lightly ... specially when they're trying to sell me another tool which I cursed at quite a few time.

It's amazing how emotional a programmer can get about its tools.

Dart was created with a lot of hints from ECMAScript 6, Java, C#, C++, etc. TypeScript code is not too

different, but TypeScript does place the types after the names. As I got used to it in Swift, TypeScript feels

OK in that regard to me.

What JS has that Dart may lack is a huge community that is prolific when it comes to publishing modules,

vapor.js notwithstanding. :-)

We can say that Dart is OK with having fewer modules, as they are better curated and more secure. Whereas

JavaScript gets away with more creativity.

At the end of the day we may choose a tool less for their sophistication and more because they just get

stuff done.

I've asked for example to have a Flutter view on the desktop, to help with trying it out. If I could

have asked for anything else from Google, it would have been on having Skia exposed more directly from

a Dart project. But at the end of the day, we are all led back to the browser for the UI. And then, tools like

Electron are all the better and they use NodeJS underneath them. After we get developing something, then

we'd also need to be able to distribute it, so having binaries for Windows and perhaps Mac/iOS/Android 

would help. Google are not wrong in wanting to have a stable UI that has accessibility features and so on.

My struggle in Dart is in seeing all of the other tools that are JS oriented. I too like the features that Dart

has like int types and general consistency, the "==" for comparison. I'm worried that with TypeScript/ES6

I will have to start using a different syntax with "for of" and "let".

In Dart I still want to try out the AoT. It could be good for faster start up?

At the same time, I feel that in Dart we are living in a bubble, away from a lot of JS libraries that we cannot

use right away and with ease. And if we do use them, perhaps we'd have to get to know the JS tools in

order to produce slimmer packages with them too.

I don't want to scoff at NodeJS. NodeJS is practically running the world. We get news like the largest

telecom in South Korea would start using it for all of their services or something. I'd love Dart to be

used instead of NodeJS for that.

I hope that you will feel good though. I didn't mean to make you feel bad. As Lars Bak said in the recent

video, Dart is being used a lot and folks will have to cope with it. Dart may be our only try at creating

an alternative to JavaScript. I don't think that heavier weight languages like Swift can steal many

JavaScripters away. Even if Swift can help to create super tight programs!

 

[1] - https://www.youtube.com/watch?v=P8ltWIqDPzo