Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #7185 > unrolled thread

Google Dart Released Today

Back to article view | Back to comp.lang.javascript

Contents

  Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-10 10:44 -0700
    Re: Google Dart Released Today "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-10 14:24 -0700
      Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-10 22:36 -0700
        Re: Google Dart Released Today David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 23:41 -0700
        Re: Google Dart Released Today "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-11 05:33 -0700
          Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-11 14:06 -0700
            Re: Google Dart Released Today Swifty <steve.j.swift@gmail.com> - 2011-10-12 07:13 +0100
        closure bindings (was: Google Dart Released Today) Andreas Bergmaier <andber93@web.de> - 2011-10-11 23:56 +0200
          Re: closure bindings (was: Google Dart Released Today) David Mark <dmark.cinsoft@gmail.com> - 2011-10-11 16:20 -0700
          Re: closure bindings Bwig Zomberi <zomberiMAPSONNOSPAM@gmail.invalid> - 2011-10-12 15:02 +0530
            Re: closure bindings Antony Scriven <adscriven@gmail.com> - 2011-10-12 05:12 -0700
              Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 18:27 -0700
          Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-12 13:24 +0200
            Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-12 08:56 -0700
              Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-12 21:15 +0200
                Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-12 15:21 -0700
                  Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-13 20:56 +0200
                    Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-13 21:36 +0200
                    Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-13 16:41 -0700
                      Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-13 22:39 -0700
                      Re: closure bindings "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2011-10-14 09:03 -0700
                      Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-14 20:05 +0200
                Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 18:38 -0700
                  Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-14 23:34 +0200
                    Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-14 16:56 -0700
                      Re: closure bindings Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-15 02:44 +0200
                        Re: closure bindings dhtml <dhtmlkitchen@gmail.com> - 2011-10-14 21:18 -0700
              Re: closure bindings David Mark <dmark.cinsoft@gmail.com> - 2011-10-12 18:28 -0700
        Re: Google Dart Released Today Antony Scriven <adscriven@gmail.com> - 2011-10-11 15:13 -0700
          Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-11 22:33 -0700
        Re: Google Dart Released Today Scott Sauyet <scott.sauyet@gmail.com> - 2011-10-12 07:27 -0700
          Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 18:29 -0700
          Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 08:21 +0000
            Re: Google Dart Released Today Scott Sauyet <scott.sauyet@gmail.com> - 2011-10-13 04:46 -0700
              Re: Google Dart Released Today unbewusst.sein@fai.invalid (Une Bévue) - 2011-10-13 14:03 +0200
                Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 12:40 +0000
                  Re: Google Dart Released Today unbewusst.sein@fai.invalid (Une Bévue) - 2011-10-13 17:51 +0200
              Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 13:31 +0000
                Re: Google Dart Released Today Duncan Booth <duncan.booth@invalid.invalid> - 2011-10-13 15:17 +0000
              Re: Google Dart Released Today Karl Tikjøb Krukow <karl.krukow@gmail.com> - 2011-10-14 13:02 +0200
                Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-14 12:36 -0700
                  Re: Google Dart Released Today Karl Tikjøb Krukow <karl.krukow@gmail.com> - 2011-10-15 19:30 +0200
    Re: Google Dart Released Today David Mark <dmark.cinsoft@gmail.com> - 2011-10-10 22:23 -0700
    Re: Google Dart Released Today Matt McDonald <matt@fortybelow.ca> - 2011-10-12 19:48 -0600
      Re: Google Dart Released Today dhtml <dhtmlkitchen@gmail.com> - 2011-10-12 21:04 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#7401

On Oct 14, 4:02 am, Karl Tikjøb Krukow <karl.kru...@gmail.com> wrote:
> On 13/10/11 13.46, Scott Sauyet wrote:
[...]
>
> I think it is to early to evaluate the Dart-JavaScript
Why? It's officially released code; why can't we look at it?

E.g.  "IE9 dom fixes: Add check for __proto__ before using it and add
some name workarounds. (issue 8277016) "
https://groups.google.com/a/dartlang.org/group/reviews/browse_thread/thread/e2fc44af2bb35b25
--
Garrett

[toc] | [prev] | [next] | [standalone]

#7452

On 14/10/11 21.36, dhtml wrote:
> On Oct 14, 4:02 am, Karl Tikjøb Krukow<karl.kru...@gmail.com>  wrote:
>> On 13/10/11 13.46, Scott Sauyet wrote:
> [...]
>>
>> I think it is to early to evaluate the Dart-JavaScript
> Why? It's officially released code; why can't we look at it?
>
> E.g.  "IE9 dom fixes: Add check for __proto__ before using it and add
> some name workarounds. (issue 8277016) "
> https://groups.google.com/a/dartlang.org/group/reviews/browse_thread/thread/e2fc44af2bb35b25
> --
> Garrett

Of course you can look at it, but I find it quite likely that the output 
will change significantly before they expect anyone to use it. So for 
instance criticizing size or performance is not to interesting to me - 
obviously they'll have to fix that before releasing a production version 
(the entire sentence was:

"I think it is to early to evaluate the Dart-JavaScript compiler by its 
output (at least in terms of code size and performance).")

But I do think evaluating w.r.t. browser scripting, e.g., your example, 
makes perfect sense (since that it not likely to change much unless 
someone gives direct feedback to the project).

/Karl

[toc] | [prev] | [next] | [standalone]

#7192

On Oct 10, 1:44 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> Dart is a new language by Google with new syntax and new operators.
>
> A language overview here:http://www.dartlang.org/articles/idiomatic-dart/
>
> Goals:http://www.dartlang.org/docs/technical-overview/index.html#goals
>
> | You will be able to run Dart code in several ways:
> |
> |  Translate Dart code to JavaScript that can run in
> |  any modern browser:    Chrome, Safari 5+, and
> |  Firefox 4+ (more browser support coming shortly).
>

That's quite a contradiction, but exactly what I would have expected
from Google. Don't even have to look at the code to know it's another
non-starter. They just can't get their collective brains around cross-
browser scripting.

What that should have said is:

"Works in Chrome (versions?), Safari 5+, FF 4+ and compatible browsers
and does *nothing* anywhere else."

The pattern is:-

if (hostfeatureworks) {
 // create the wrapper
} else if (hostfeaturealternativeworks) {
 // create alternate version wrapper
} else {
 // do nothing!
}

Apps then detect the presence of the wrapper(s) with the damnable host
object details hidden behind the scenes. This allows old forks (e.g.
legacy IE BS) to be removed without breaking apps and add-ons. Seems
like a very simple proposition to me. If you are to abstract an
unknown environment, you have to account for the "none of the above"
cases. Host features come and go over the years, so there will always
be the chance of environments that can't run the app (or enhancements)
under any circumstances.

I've explained this concept to many developers (particularly JS
library authors) over the years and the number one answer as to why
they don't use this pattern is that they don't want to wrap their apps/
enhancements in an - if - statement. Of course, leaving off the
"gateway" won't break anything that isn't already broken. The only
difference is that the calling code will fail immediately on trying to
call a *library* method that doesn't exist (something easily remedied
with a gateway) rather than deep inside some ridiculous library.

So jQuery, Google, etc. all write code based on this pattern:-

if (hostfeatureworks) {
 // create the wrapper
} else {
 // create alternate wrapper come hell or high water (sometimes
impossible).
}

This is the "normalize at all costs because that's cool" pattern.

So have they made the situation for the calling app worse or better?
Clearly much worse as a potential impossibility has been glossed over
in the - else - fork. The calling app can't tell whether the features
it needs are available or not. In other words, short of digging into
the host objects themselves (what the library is supposed to be
hiding), apps based on such code are oblivious to their environment.
First call to a library method trying to use a host object that does
not exist blows up. Nothing to keep add-ons in line either.

The end result of this is jQuery and others still have lots of old
(and badly done) workarounds for legacy browsers (e.g. IE 6/7/8) with
no way to remove the code. I suppose they could take a poll of all
library developers and if a majority says IE 6/7 (for example) are
"irrelevant" (as they see it), then they can remove a ton of lousy old
code. But then the library-based sites that don't care to break in IE
6/7 are unable to "upgrade" and orphaned by the project.

So I don't see how Google replacing the *language* is going to help
anybody but Google. And if they are trying to take a leadership
position in cross-browser scripting, they've got a long (and seemingly
insurmountable) way to go. Their previous effort was based on Dojo for
God's sake. :(

[toc] | [prev] | [next] | [standalone]

#7313

On 10/10/2011 11:44 AM, dhtml wrote:
> Dart is a new language by Google with new syntax and new operators.
>  [...]

Aside from the supremely bloated language, what I found most concerning
was the DOM interpretation Google are implementing.

I picked up the following link from Twitter today:
http://www.dartlang.org/articles/improving-the-dom/

The first folly begins in the third section entitled
"Better querying". It seems that the myriad of NodeList-fetching
methods and HTMLCollection-fetching properties are too verbose,
and not expressive enough. The solution? Why, CSS-style querying,
of course! Certainly, nothing beats a square peg lovingly jammed
into a triangular hole. The religious blurb in the jQuery paragraph
says it all, really.

Next up, we have a "collections" section. Here, the Dart team
have implemented an HTML 5 classList API, except using attributes.
What a nice way to remind developers of the (ir)relevance of
attributes. Later on, we're reminded of how cumbersome child node
accessing is. Clearly, `el.childNodes.length`, `el.firstChild` or
`el.childNodes[0]`, and `el.appendChild(childNode)` are just too
difficult to type up.

Now, on to DOM element construction. Dart's DOM improvisations
propose drudging up the Element constructor. Thought that was
bad enough? How about a jQuery-inspired innerHTML wrapper?
Nothing beats kludging through strings instead of nodes!

It frustrates me daily to see the pitfalls that have been made
thanks to frivolous crap like jQuery. Now, Google's pet project
is proposing to nearly extend it? It's both pathetic and
unsettling that the IT company most people look up to can foul
something so important up. The icing on the cake is seeing
John Resig, the Dart team, et al echo that that DOM is
fundamentally broken.

Garrett, you're bang on. Web developers really are stupid.

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#7319

On Oct 12, 6:48 pm, Matt McDonald <m...@fortybelow.ca> wrote:
> On 10/10/2011 11:44 AM, dhtml wrote:
>
> > Dart is a new language by Google with new syntax and new operators.
> >  [...]
>
> Aside from the supremely bloated language, what I found most concerning
> was the DOM interpretation Google are implementing.
>
> I picked up the following link from Twitter today:http://www.dartlang.org/articles/improving-the-dom/
>
> The first folly begins in the third section entitled
> "Better querying". It seems that the myriad of NodeList-fetching
> methods and HTMLCollection-fetching properties are too verbose,
> and not expressive enough. The solution? Why, CSS-style querying,
> of course! Certainly, nothing beats a square peg lovingly jammed
> into a triangular hole. The religious blurb in the jQuery paragraph
> says it all, really.
>
> Next up, we have a "collections" section. Here, the Dart team
> have implemented an HTML 5 classList API, except using attributes.
> What a nice way to remind developers of the (ir)relevance of
> attributes.

That would be true only if they are clear about the difference between
attributes and properties. It is a disturbingly common mistake, and
particularly so after all the noise on this NG and after that long
article I wrote.

Again, we should see some code. Somebody go download this thing and
make a gist, etc.

[...]

> Now, on to DOM element construction. Dart's DOM improvisations
> propose drudging up the Element constructor.
The syntax difference is minimal to me. I don't mind much either way
of:

| document.createElement("div");
| new Element.tag("div");

Though the latter starts with "new". The only problem with that is
that they have now to create some unnecessary delegation. They
possibly have to contend with error propagation where createElement
throws.

Given a standard and wide browser support for `new Element.tag` sure,
that'd be fine, but that is not reality. Just
`document.createElement("div")` works.

Thought that was
> bad enough? How about a jQuery-inspired innerHTML wrapper?
> Nothing beats kludging through strings instead of nodes!
>
That's not a bad idea for a spec proposal, per se, but like with `new
Element.tag` it isn't natively supported or specified anywhere except
by Google. This means an additional abstraction layer is required
(Dart DOM library), and that must be downloaded, interpreted, run by
the device, and stepped through when debugging.

The jQuery wrapper tries again to do something general with innerHTML
and innerHTML has a lot of quirks. That's not to say innerHTML is bad,
but it is wildly inconsistent. The other problem with the way
`jquery.buildFragment` is designed is that it uses overloading and
typechecking with using host objects. That doesn't work.

But what is inherently wrong with building HTML fragments with
strings?

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/6f97e834996670c3
--
Garrett

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.javascript

csiph-web