Dart and Google Cloud Platform • Hacker News Board

Re: Dart and Google Cloud Platform

#11

Post by cromwellian » Sat, Nov 08, 2014, 5:20 AM UTC

azakai wrote: post #10

cromwellian wrote: post #7

Earlier quoted context omitted.

For a less snarky explanation of what's going on: https://news.ycombinator.com/item?id=8495498 We are working on it. Inbox was designed to be 'mobile first' and use "Material Design" animations, and pulling off 60fps animations of that style in an app like Inbox is very complex, in fact, each new version of Chrome broke assumptions and broke animations we had running previously. The Web, as a platform for competing w…

Isn't this still fundamentally a problematic approach, though? Yes, being Chrome-only at launch was a bad idea (and the predictable response was that tweet and its thousands of retweets), but even if it were "Chrome + a notice about Firefox soon", and some time later it does run on Chrome and Firefox, that still leaves out all the other browsers! I understand that you want 60fps flawless performance for your new prod…

If we had the resources and didn't have constraints to co-launch with Android Lollipop and iOS, making it work on all the browsers out launch may have been feasible. We had bugs filed for most of the issues in our internal tracker, but we ran out of time before launch.

This is a problem at big companies like Google and probably Apple, is that we time major sets of released functionality for 'big impact' launches like Google I/O, or other media events, and the poor engineers are left working late into the night to meet the deadlines.

As for just rendering everything with WebGL or Canvas, we could do that (Google Sheets uses Canvas), but it kind of rubs me the wrong way, it doesn't feel "webby". You end up reimplementing tons of stuff: Bidi/I18N text handling, A11Y, system behaviors like text selection, clipboard, it just seems like you're making your own Flash runtime in JS, an alien hybrid that displaces the entire browser engine.

I hope apps like Inbox, and the new focus on mobile web performance by both Google and Mozilla can fix many of these layout/rasterization/composite hazards, either at the spec level (e.g. will-change), or at the implementation level, so much like there is a 'war' on JS performance, there can be a 'war' on layout and paint performance.

Long term, if we want the web to succeed and not be destroyed by mobile native apps, we need it to work -- as the web --, and not as simply opaque WebGL + JS, that's basically just a native app model with a different VM.

Re: Dart and Google Cloud Platform

#12

Post by bootload » Sat, Nov 08, 2014, 6:03 AM UTC

cromwellian wrote: post #7

andyl wrote: post #4

"Runs best in Chrome", coming soon to a browser near you. The spirit of IE lives! https://twitter.com/jashkenas/status/525024739816116224

For a less snarky explanation of what's going on: https://news.ycombinator.com/item?id=8495498 We are working on it. Inbox was designed to be 'mobile first' and use "Material Design" animations, and pulling off 60fps animations of that style in an app like Inbox is very complex, in fact, each new version of Chrome broke assumptions and broke animations we had running previously. The Web, as a platform for competing w…

"... Inbox was designed to be 'mobile first' and use "'Material Design' animations, ... each new version of Chrome broke assumptions and broke animations we had running previously ..."

Cognitive friction.

    "... Cognitive friction doesn't come from technology, 
     but from the people who control technology. The are 
     the masters because they know how to think in ways
     that are sympathetic to silicon, and they imagine
     that everyone thinks in the same way. ..." 
     Alan Cooper

"... The Web, as a platform for competing with mobile-style interfaces, is in a rickety state at the moment, where performance is non-deterministic not only across browsers, but across versions ..."

    *"... As engineers, they think more about gears 
    than aout leather, so the interface to the human 
    user is expressed in those 'implementation' terms,
    which is why I call products designed this way as 
    having an *implementation model*. ..."
    Alan Cooper

For those who have read, "The Inmates are running the Asylum", SAMS, Al Cooper, 2003. Welcome to the dancing bear.

Re: Dart and Google Cloud Platform

#13

Post by shadowmint » Sat, Nov 08, 2014, 6:16 AM UTC

JoshMilo wrote: post #2

This is good news; I'm still waiting for the DartVM to get integrated into Chrome.

realistically, this is unlikely to ever happen for both technical and political reasons.

Theres certainly no immediate path forwards towards that end goal at the moment.

Dart2js, atscript and other compile to javascript things are where its going to be at for the forseeable future.

Re: Dart and Google Cloud Platform

#14

Post by cromwellian » Sat, Nov 08, 2014, 6:35 AM UTC

bootload wrote: post #12

cromwellian wrote: post #7

Earlier quoted context omitted.

For a less snarky explanation of what's going on: https://news.ycombinator.com/item?id=8495498 We are working on it. Inbox was designed to be 'mobile first' and use "Material Design" animations, and pulling off 60fps animations of that style in an app like Inbox is very complex, in fact, each new version of Chrome broke assumptions and broke animations we had running previously. The Web, as a platform for competing w…

"... Inbox was designed to be 'mobile first' and use "'Material Design' animations, ... each new version of Chrome broke assumptions and broke animations we had running previously ..." Cognitive friction. "... Cognitive friction doesn't come from technology, but from the people who control technology. The are the masters because they know how to think in ways that are sympathetic to silicon, and they imagine that eve…

Umm, no, absolutely 100% backwards. Inbox was designed 100% as a goal directed product based on making the user more efficient and satisfying his needs, technical decisions came later. Product design was done by product managers and interaction designers by taking into account usability study feedback. We didn't just have engineers making stuff up cause they liked it, our users told use what their email pain points were. None of the internal presentations on Inbox's development by the designers mention the client implementation details. It's not the inmates running it, it's the people outside the asylum. The basic facts on the ground. Most access to email is going mobile. The design is to fit the users as they are coming.

If we designed product features based on technical decisions, we would not have had so much trouble, because we would have simply picked the lowest common denominator we could get away with to deliver the product and not pushed on sharp edges in the stack.

We take a design based on how the product must or should behave, the engineers do not run the show.

As an aside, I value the Web not because of implementation details (I'm not a particular fan of CSS or JS) but because of high level properties it has that native mobile apps do not have. That's why I'd rather see a return to web applications over time. Web apps produce positive net externalities that native silos do not.

These don't matter for the short term, or the individual, but they matter collectively over the long term for society. I may not be able to access content siloed to apps 30 years from now, but I'll probably still be able to find Web content indexed and stored on archive.org

I view developing for the Web as planting trees in a forest that is logged for value over time by society, by businesses, that extract value. We are caretakers of it, and should put back into it so that the those who come after us can derive value as well.

I'm not sure how developing a native iOS app, for example, will help our grandkids the way making an open ecosystem and publishing lots of content that can be freely indexed, mashed up, and repurposed will. I imagine future archaelogists will have a much easier time digging up value from the Web than trying to dig up App Stores for information.

Re: Dart and Google Cloud Platform

#15

Post by WoodenChair » Sat, Nov 08, 2014, 6:46 AM UTC

shadowmint wrote: post #13

JoshMilo wrote: post #2

This is good news; I'm still waiting for the DartVM to get integrated into Chrome.

realistically, this is unlikely to ever happen for both technical and political reasons. Theres certainly no immediate path forwards towards that end goal at the moment. Dart2js, atscript and other compile to javascript things are where its going to be at for the forseeable future.

Care to elaborate? I believe it has been publicly stated in the past by the team that this is something being actively worked towards once OilPan (or whatever it's called) is finished? Has this changed?

Re: Dart and Google Cloud Platform

#16

Post by XtianThrowaway » Sat, Nov 08, 2014, 8:11 AM UTC

cromwellian wrote: post #14

bootload wrote: post #12

Earlier quoted context omitted.

"... Inbox was designed to be 'mobile first' and use "'Material Design' animations, ... each new version of Chrome broke assumptions and broke animations we had running previously ..." Cognitive friction. "... Cognitive friction doesn't come from technology, but from the people who control technology. The are the masters because they know how to think in ways that are sympathetic to silicon, and they imagine that eve…

Umm, no, absolutely 100% backwards. Inbox was designed 100% as a goal directed product based on making the user more efficient and satisfying his needs, technical decisions came later. Product design was done by product managers and interaction designers by taking into account usability study feedback. We didn't just have engineers making stuff up cause they liked it, our users told use what their email pain points w…

It is just amazing that you can write this post after having created, essentially, a native Chrome application.

Your head is filled with Google jingoism tailored to almost fit the ideals you're trying to spout, but you failed to create an open application.

Re: Dart and Google Cloud Platform

#17

Post by 1stop » Sat, Nov 08, 2014, 1:32 PM UTC

XtianThrowaway wrote: post #16

cromwellian wrote: post #14

Earlier quoted context omitted.

Umm, no, absolutely 100% backwards. Inbox was designed 100% as a goal directed product based on making the user more efficient and satisfying his needs, technical decisions came later. Product design was done by product managers and interaction designers by taking into account usability study feedback. We didn't just have engineers making stuff up cause they liked it, our users told use what their email pain points w…

It is just amazing that you can write this post after having created, essentially, a native Chrome application. Your head is filled with Google jingoism tailored to almost fit the ideals you're trying to spout, but you failed to create an open application.

I thought it was explained rather well. They are working on making it work on other browsers.

But even if they stopped at Chrome only support, that is still better than Android/Windows/iOS app, as at least you can install Chrome on anything.

Do you give crap to every iOS developer out their for releasing only for 1 platform? Or is this just "Google is evil" cargo-culting?

Re: Dart and Google Cloud Platform

#18

Post by greghendershott » Sat, Nov 08, 2014, 3:12 PM UTC

cromwellian wrote: post #7

andyl wrote: post #4

"Runs best in Chrome", coming soon to a browser near you. The spirit of IE lives! https://twitter.com/jashkenas/status/525024739816116224

For a less snarky explanation of what's going on: https://news.ycombinator.com/item?id=8495498 We are working on it. Inbox was designed to be 'mobile first' and use "Material Design" animations, and pulling off 60fps animations of that style in an app like Inbox is very complex, in fact, each new version of Chrome broke assumptions and broke animations we had running previously. The Web, as a platform for competing w…

Thanks for sharing that. It's helpful to understand it from your perspective.

To share my perspective, outside Google:

A similar "error/ad" appears for other some other Google features. Such as trying to edit a picture in Google+ -- I've seen that example for so long now, it seems there's no intent ever to change it.

With each such example, the cumulative effect is to remind me of bad days in the past. My feeling isn't snarky, it's unease. I've seen stuff like Prodigy and CompuServe. I saw Microsoft pivot MSN 1.0 from being another such service, to instead be a web site.

And ever since, I've seen a succession of attempts to "put the open internet genie back in the bottle", including but not limited to Internet Explorer. So far these attempts have failed... but they haven't been from a company as powerful as Google.

So as someone who had loved Google for many years as a supporter of the open internet, it makes me unhappy and confused to see more examples of "Download Chrome!" as an error message in Firefox.

Having said all that, I'm happy to hear that you plan to address this at least for Inbox on Firefox.

Re: Dart and Google Cloud Platform

#19

Post by mark_l_watson » Sat, Nov 08, 2014, 3:34 PM UTC

cromwellian wrote: post #14

bootload wrote: post #12

Earlier quoted context omitted.

"... Inbox was designed to be 'mobile first' and use "'Material Design' animations, ... each new version of Chrome broke assumptions and broke animations we had running previously ..." Cognitive friction. "... Cognitive friction doesn't come from technology, but from the people who control technology. The are the masters because they know how to think in ways that are sympathetic to silicon, and they imagine that eve…

Umm, no, absolutely 100% backwards. Inbox was designed 100% as a goal directed product based on making the user more efficient and satisfying his needs, technical decisions came later. Product design was done by product managers and interaction designers by taking into account usability study feedback. We didn't just have engineers making stuff up cause they liked it, our users told use what their email pain points w…

I totally agree, especially with the last two paragraphs.

Native mobile apps rub me the wrong way if they could have been open standars web apps, with some reasonable definition of open standards.

The web is a repository of knowledge, with also a lot of cruft, and that knowledge should be accessible well into the future.

Re: Dart and Google Cloud Platform

#20

Post by azakai » Sat, Nov 08, 2014, 6:10 PM UTC

cromwellian wrote: post #11

azakai wrote: post #10

Earlier quoted context omitted.

Isn't this still fundamentally a problematic approach, though? Yes, being Chrome-only at launch was a bad idea (and the predictable response was that tweet and its thousands of retweets), but even if it were "Chrome + a notice about Firefox soon", and some time later it does run on Chrome and Firefox, that still leaves out all the other browsers! I understand that you want 60fps flawless performance for your new prod…

If we had the resources and didn't have constraints to co-launch with Android Lollipop and iOS, making it work on all the browsers out launch may have been feasible. We had bugs filed for most of the issues in our internal tracker, but we ran out of time before launch. This is a problem at big companies like Google and probably Apple, is that we time major sets of released functionality for 'big impact' launches like…

I get what you're saying about i18n in the alternate approach. It's harder to do those things there.

But isn't "designed for Chrome and Firefox" just a marginally better thing than "designed for Chrome"? It's still tailor-made for specific browsers, just 2 instead of 1. That's very un-"webby".