Google going to push a new client-side language - Thoughts?

[Joe Developer]

http://markmail.org/message/uro3jtoitlmq6x7t

[Rasmus Wikman]

The Road to Hell is Paved With Googled Intentions.

On Sep 10, 2011, at 3:14 AM, Joe Developer wrote:

> http://markmail.org/message/uro3jtoitlmq6x7t
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Joshua Kehn]

I'm not so concerned.

Regards,

-Josh
___________________________
http://joshuakehn.com
Currently mobile

[Mark Hahn]

I can't believe they are pushing for adoption by all browser vendors but then say in passing: "and--worst of all--Google’s leadership position on the web would be seriously damaged".  Not a good way to get cooperation between vendors.

[Martin Wawrusch]

Reminds me a lot of what Microsoft used to say when they announced Silverlight. We all know how that one went...

[Joshua Kehn]

*long whistle* – splat!

Regards,

-Josh
____________________________________
Joshua Kehn | @joshkehn
http://joshuakehn.com

[Ryan Schmidt]

On Sep 9, 2011, at 19:14, Joe Developer wrote:

> http://markmail.org/message/uro3jtoitlmq6x7t

tl;dr but I got that it's about Google developing a new Dash language to replace JavaScript in the browser. The message was sent November 2010. Today, Googling "Dash language" or "Google Dash" doesn't get me anything relevant. Did anything ever happen with it?

[Martin Wawrusch]

It seems that it is now called DART (http://www.extremetech.com/computing/95417-google-announces-dart-programming-language and http://www.readwriteweb.com/hack/2011/09/google-confirms-hints-dropped.php)

and will be officially unveiled October 10th: http://gotocon.com/aarhus-2011/presentation/Opening%20Keynote:%20Dart,%20a%20new%20programming%20language%20for%20structured%20web%20programming

[Oleg Slobodskoi]

somebody has done a huge effort to make this joke, lets laugh :)

2011/9/10 Joe Developer <joe.d.d...@gmail.com>:
> http://markmail.org/message/uro3jtoitlmq6x7t

>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

--
regards,
Oleg Slobodskoi
--------------------------------------------------------------------
Xing: https://xing.com/profile/Oleg_Slobodskoi
Twitter: https://twitter.com/oleg008
Github: https://github.com/kof

[Nicolas Chambrier]

That don't seem more laughable than coffee script or fibers... Wait n see. If that will be embedded in v8, then we could enjoy the ability of using js or dart depending on which one is better for the task to be done.

My personal experience tells me to wait before laughing too loud...

[Daniel Latter]

More FYI: http://m.theregister.co.uk/2011/09/09/google_dart_web_programming_language/

[Joe Developer]

My random thoughts on this:

My experience of performance issues in the client is that it is DOM bound - very rarely do I find that JS is holding the interface back, rather it is the creation and manipulation of DOM elements that is the source of interop and performance issues. 

While using 'double-buffering' techniques with DOM-fragments helps me overcome some of this - the cost of reflows when dealing with moderately complex ( 5k+ dom element ) is quite high. This is true for 'modern' browsers such as FF6 and Chromium as well, time spent in reflows can be orders of magnitude higher than in the processing which triggers them.

In these scenarios there are also bottlenecks stemming from the CSS selector engines.

The biggest factor in this however is having to support browsers with very disparate performance characteristics. An app that is fluid with 5k elements in Chromium and FF6+ can slow to a crawl on IE8. The heterogeneous landscape is on one hand a welcome sign of progress - without competition and leapfrogging we would be unlikely to be enjoying the actual gains that we have had - on the other it also serves as a reminder that Dart is, to put it mildly, unlikely to address this.

Personally, I would much rather see vendors coming together to fix and enhance DOM interactions and reflow triggers - for current applications this is the pain point ( in my experience ).

For applications and games of the future I would be more interested at seeing adoption of WebCL and WebGL - and an interface ala C++ AMP for abstraction of client processing resources.

Your thoughts and experiences?

[Edward Decker]

I think the browser could really benefit from a more efficient
language, I'm open to the idea.

On Sep 9, 5:14 pm, Joe Developer <joe.d.develo...@gmail.com> wrote:
> http://markmail.org/message/uro3jtoitlmq6x7t

[Marak Squires]

a.dem...@gmail.com is a known troll and he's trolling the mailing list ( in many threads ).

I've requested he be banned. 

[Mark Hahn]

Why are you repeating this OT message?  Has this guy been on this list lately?

[Angel Java Lopez]

Bracha’s position about Javascript:

The Truthiness Is Out There

For the past 5 years or so, I (like many others) have argued that Javascript is the assembly language of the internet platform. Over this period, some of the obstacles that limit the applicability of said platform have been slowly pushed aside. Things like client side storage, or decent performance.

However, Javascript remains a seriously limited language for platform implementation. Here are some of the problems…

[Joe Developer]

Well, it has gotten me somewhat intrigued, though some of the points strike me as slightly opportunistic - or perhaps I am just not on the same plane of abstraction.

Orthogonal persistence is the responsibility of the executing environment - hence it would be more appropriate to argue that JS VM's / browsers should implement snapshot functionality ( save tab state ). The argument seems to only be relevant insofar you are building a VM *in* JS in which case the complexity of granting orthogonal persistence to host programs seems to be more of an annoyance than an impossibility.

Google Chrome now incorporates a 'fix and continue' debugger - or something so close to it that it hardly seems to make a difference.

The main problem that I have with his objections as stated there, is that they aren't written from the point of view of a person writing apps in JS - they are written from the point of view of a person who wants to write apps in another language and implement the VM for it in JS.

I think it is fair to say that the majority of web developers are not tasked with writing VMs.

That said, I find that Newspeak doesn't look unattractive: 

http://langexplr.blogspot.com/2009/04/parsing-json-with-newspeak.html

But I think that one of the commentators hit on a near-perfect solution: Standardizing VM bytecode, or at least expose a set of standardized bytecodes - this could allow a similar explosion of languages in the browser as we have seen on JVM a much more attractive and forward looking vision, imo.