Hi Filipe,
Post by Filipe MorgadoJavaScript 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.
Post by Filipe MorgadoI 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.
Post by Filipe MorgadoI'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.
Post by Filipe MorgadoThe 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!
Post by Filipe MorgadoA 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!
Post by Filipe MorgadoAnyway ...
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] -
--
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+***@dartlang.org.