Google is building a Chrome app-based development environment | Hacker News Reader

Google is building a Chrome app-based development environment

thenextweb.com

128 pointsiamtechaddict97 comments

https://github.com/dart-lang/spark

This actually isn't a cloud-based IDE, it's a Chrome App and runs completely locally and offline, editing a project on the local file system. You won't need to log into anything or store your code on anyone else's servers, though there is git integration.

Honestly, I don't see a point. Presumably, it originates from the belief that the the web is the future and that it will finally replace native platforms. I used to strongly believe in that too but now I don't think it will happen any time soon, if at all.

Currently there are two kinds of platforms: the web, initilly intended for documents and native platforms, designed primarily for apps. Both have different strengths. The web: no installation, hyperlinking, decentralization and openess, etc. Native plaftorms: window manager, speed, collaboration between apps, much richer API, centralization (enabling human interface guidelines for example), etc.

A third platform having the best of both worlds would be great but that's just my utopic dream :)

You can try to get there by bringing the benefits of the web to apps, and by bringing the benefits of apps to the web. We're already seeing this with ChromeOS, FirefoxOS, Cordova, etc. on the web side, and various efforts to streamline app installation, add deep linking, and other things on the app side.

Personally, I think browsers can be a quite good application platform - they're basically a view hierarchy, with a layout and styling system, an event model, and scripting engine. With efforts like the *OS APIs, custom elements, asm.js/PNaCl/Dart, WebGL, canvas, Service Workers... there's a lot you can do, all in a stack that's easily accessible to millions of developers.

"they’re Google’s way of pushing the limits of the Web as a platform."

Nope, they're Google's way of extinguishing non-Chrome browsers. Only Chrome/Chromium will be supported. That's called vendor lock-in - regardless of being open source.

Firefox's addons also only work with Firefox. Thunderbird and Komodo also only work on top of the Mozilla platform. Eclipse and Netbeans needs Java. A bunch of apps need Air.

You can make this work inside XULRunner if you want. You only have to write some library which provides the same API as the chrome_gen package (reading/writing files etc) and then import it instead of chrome_gen or just overwrite the package. Everything else is regular web stuff.

Anyhow, using some apps which use Chrome as runtime doesn't meant that you have to use Chrome as default browser. You only need to have it installed. Just like any other runtime you're using.

These apps don't run on Chrome the browser. They run on the Chrome runtime, and open outside the browser. So, if they're extinguishing non-Chrome browsers, they're extinguishing Chrome browser too - which is obviously not the case.

>Nope, they're Google's way of extinguishing non-Chrome browsers. Only Chrome/Chromium will be supported. That's called vendor lock-in - regardless of being open source.

In order for it to be "vendor lock-in", people should care about those apps in the first place. Which they don't, much. In fact, they are quite niche.

So, yes, they'll might lock a 0.1% of people with that.

Now, if they did the same for Search, Mail or YT I'd be worried.

(Hint: even after all those years, Google Docs, a flagship has an insignificant user base -- and that one is not even Chrome-locked).

"vendor lock-in" and "open source" are incompatible. Google won't stop anyone that wants to add support for other browsers. In fact, anyone could fork Spark.

If you want an example, see OpenOffice.org and LibreOffice.

I don't understand Chrome apps. They require installation and only work on Chrome, so they come with none of the benefits of the web. They are slower and uglier than native Windows/Mac/Linux apps. What's the point?

The main benefits as I see them are:

* Its an easy way to build simple(ish) cross-platform apps using HTML/CSS/Javascript. * A native app platform for Chromebooks * Promotion of your app the Chrome store. * For users their apps are available anywhere Chrome is.

They are just apps that use the ChromeOS development library (JS, HTML, CSS and some custom APIs). Think of it like Cocoa on OS X. Except they can also run in the Chrome browser on other OSes. I don't understand why people get so riled up about this.

Is there someway to do standalone installs as well? It seems like that might be against Google's motives in getting everyone to use Chrome as a browser, but it would make it easier to distribute applications in a "traditional" manner.

Plus, it would be nice to have dedicated icons, etc...

https://github.com/rogerwang/node-webkit

Can you run Chrome Apps with that though? It looks like it might be just nodejs.

No, you cannot build Chrome Apps with Node-WebKit, but you can target Win/Lin/OSX. See my comments below: https://news.ycombinator.com/item?id=6778882

I think people get riled up because the humble browser is rapidly turning into this: http://i.imgur.com/XNRtCGh.jpg

So browser extensions are bad now?

When can HN get off the hate train for everything new? This place is seriously starting to depress me.

Well, most browser extensions relate to browsing. Google, on the other hand, is trying to turn the browser into an OS. This is a really big shift that may very well determine the future of computing, so I think there's plenty here for people to get legitimately angry about. Not really the same kind of "hate train" that occasionally shows up on project posts, I think.

What's wrong with the Chrome browser becoming an OS? What you get is a fast and secure OS. Most users spend most of the time on the browser anyways - why not leverage that to make user's lives easier?

I don't know about others, but for me, it just doesn't make any conceptual sense. Would you use Excel as a word processor? Would you use Lightroom for mapping? The modern operating system offers so many amazing frameworks and features; why throw that all away and start anew on a shaky foundation of Javascript, HTML, and insanely complicated rendering code, all originally designed for a completely different purpose?

I prefer my software to adhere to the single responsibility principle as much as possible.

EDIT: Why are you downvoting me? If you disagree, that's what the reply button is for. I'd like to think that HN is better than Reddit.

Why would I want a crippled, vendor locked-in OS inside my fully capable and free OS?

>What's wrong with the Chrome browser becoming an OS? What you get is a fast and secure OS.

Citation very much needed.

Fast? It's slower than native, and --for some tasks, like any kind involving multimedia editing-- useless.

Secure? When did OS+browser became more secure than just OS?

> Secure? When did OS+browser became more secure than just OS?

You can't get a virus from visiting a web page.

You don't give a web page access to all your files just by visiting it.

Running a native app requires significantly more trust than running a web app. Web apps are significantly more sandboxed.

>You can't get a virus from visiting a web page.

You very much can.

In fact, that was one of the most common attack vector for viruses: web browser exploits, from applet bugs to native web browser code buffer overflows and other issues.

Applets are very different from web extensions.

Do I really have to spell things out in legalistic precision to make what should be a very obvious point?

Are you really going to argue that native apps and web apps are equally secure because web browsers can occasionally be compromised to give you the permissions that native apps give you by default?

Are you really going to argue against the security of today's web browsers because security of browsers used to be comparatively atrocious?

If I give you the choice of either running my malicious native app or visiting my malicious website, are you really going to say that they are equally risky?

>Are you really going to argue that native apps and web apps are equally secure because web browsers can occasionally be compromised to give you the permissions that native apps give you by default?

By default in which system? Because sandboxing for native apps has been a default on OS X for the last 2 OSes at least.

Plus, there's another differentiator at play.

People don't only stick to a few large websites (like Google and NYT). People visit THOUSANDS of sites every month, and each can be an attack entry point if there's a browser/applet/etc exploit.

OTOH, with apps the situation is different. People use far fewer third party apps (say, less than 20 for the average user), and have the option to get them from legit (and verified/encrypted) sources, like several App Stores, the services of official vendors like Adobe etc, official software sites and such.

I never had a virus from a legit app purchase/download. How many cases are there were the upstream sources is poisoned?

I don't think that's a fair comparison..

1) Web apps in this case are downloaded from an app store (and people complained about it too)

2) Average people also use fewer sites: I wouldn't be surprised if regular use comprehends just gmail/outlook, facebook, wikipedia, youtube/netflix

3) You need a browser running in the OS anyway

4) App -> sandbox -> OS vs. App -> Javascript sandbox/Nacl sandbox -> browser -> sandbox -> OS... The latter looks more secure to me

Are people angry about building an OS that incorporates Chrome? Or are they angry about Web apps shipping on the desktop, turning Chrome into an application platform? These are separate things (Linux does not ship with your desktop browser, for example), and frankly, criticizing either is ignoring the couple of years' worth of successful desktop applications running mostly in embedded WebKit. Making this environment useful through a centrally-controlled and sandboxed runtime and, now, a development toolkit, is simply not worth being angry about at this point.

> Google, on the other hand, is trying to turn the browser into an OS

This isn't new, not since Marc Andreessen said "[Netscape will soon reduce Windows to] a poorly debugged set of device drivers" - in 1995. Which I take to mean he fully intended to make everything above device drivers the domain of the browser.

It's not an OS, it's a development platform. Linux/Windows/Mac is the OS.

Chrome Apps as far as I know can only be installed via a proprietary web store. You can't actually package them up as an exe or dmg to distribute yourself. They also don't have access to the system tray - they're not really first-class standalone desktop apps.

There is a PhoneGap wrapper for Chrome Apps, which you can probably eventually use also for packaging for the desktop OSs (even though now the focus is understandably on iOS and Android as Chrome apps work on the other platforms):

https://github.com/MobileChromeApps/mobile-chrome-apps

Define "installation"? My definition of installation is whether or not I can install it on a PC that is locked down by a system's administrator. While it may (or may not) be possible to lock down Chrome from being able to install apps, I've never been anywhere that did, despite those machines being otherwise locked down.

Otherwise, the benefits are

- being able to develop in just HTML/CSS/JS

- being able to deploy to Windows, Linux, OSX, anywhere Chrome runs

- No infrastructure costs to host / distribute (unless your app has server-side functionality)

etc., etc.

In addition to all the siblings' points, it does look like we're going to be able to have Firefox and Chrome compatible apps someday (I can't find a link right now, but it's been a secondary goal for both teams, Mozilla especially as they define APIs for Firefox OS that will be compatible with the open (but with permissions) web). Hopefully the teams keep working on this.

Just to add a few:

- They work offline, like native apps, but are cross-platform, like web apps.

- You can develop and distribute them without running your own server infrastructure (the Chrome store will distribute them and the run locally).

- They work on ChromeOS

That’s a funny definition of cross-platform. You mean, it’s cross-platform if you use Google’s browser.

And as far as offline goes, that’s an active area of development within the HTML5 spec. It doesn’t strike me as a particular draw given that it’s at least possible, if still somewhat painful, to build truly cross-platform apps with offline capabilities.

Why should I support ChromeOS? ChromeOS is not the web!

Yeah, and Java apps are cross-platform if you use the JDK. It's cross-platform from an app developer's perspective because the runtime exists on multiple platforms. Pretty standard definition of "cross-platform."

I'm not telling you what you should do. I'm telling you why this model is attractive to me.

Java is only cross platform if you use the JDK, Flash is only cross platform if you use Adobe's plugin, etc. So I don't think this is a completely funny definition of cross platform.

>>It doesn’t strike me as a particular draw given that it’s at least possible, if still somewhat painful, to build truly cross-platform apps with offline capabilities.

If you can achieve a cross platform experience using something that's installed on most PC's, and if it offers features or simplicity that is not available in the truly cross-platform spec, then that seems like a strong draw.

TBH JDK has open, 3rd party implementations. I'm running one right now.

Chrome's API don't have this. Chrome == Chromium, and there's nothing else under the sun that either have it or want it.

HOWEVER - Chrome has the largest marketshare by far, thus enforcing whatever it wants. Knowing competitors will not pick up the functionality because "its really made just for Chrome, not for the open web", that's called "extinguishing" competitors. But I'm sure everyone is all too familiar with that concept.

jdk is not open source, or wasn't at the time. So 3rd parties open implementations were required. Chrome through chromium is an open implementation by default and it's highly maintained, tested and optimized. Reimplementing it wouldn't make much sense and so would complaining about the lack of implementations.

> Reimplementing it wouldn't make much sense and so would complaining about the lack of implementations.

I do not think that Chromium represents the best possible implementation of the Web stack. Having multiple implementations of HTML and the various related specs is what has pushed them forward so rapidly.

so you say we should ditch all browsers and only use chrome. my issue VERY exactly.

Chrome apps can also be compiled to cordova so chrome apps can run natively on iOS and Android too, no need for chrome. This was just announced at the chrome dev summit and a bit earlier at the cordova conf in Amsterdam.

It's cross Google ;-) Croogle apps.

>That’s a funny definition of cross-platform. You mean, it’s cross-platform if you use Google’s browser.

Cross platform just means they run in different platforms. Nothing in the notion depends on if they do so with native code or with some supporting layer (like the JVM, WxWidgets or Chrome).

>Why should I support ChromeOS? ChromeOS is not the web!

Why should you support ANYTHING for that matter? Including the web. If you want to do so, do it. If not, don't. You don't "have to".

In addition to the other points made here - it's far simpler to adapt a web application you've already built to an off-line chrome app, than it is to start again in a native language.

The productivity of web-based development, with access to richer API's and local storage, on the reach and cross-platform of Chrome, with the visibility of publishing it on the Chrome Web Store, and only 1 browser to test it on = Win, Win!

> What's the point?

It's basically Java, but Google made it. Your Chrome Apps can run wherever Chrome does.

> They are slower and uglier than native Windows/Mac/Linux apps. What's the point?

They are the "native" apps for ChromeOS that, incidentally, can also run anywhere else* that Chrome OS runs.

* except iOS

With the Chrome Apps PhoneGap wrapper you can package them for iOS too: https://github.com/MobileChromeApps/mobile-chrome-apps

When you put it that way, they sound a lot like.... ActiveX

Except that ActiveX works only on Windows IE and not built on web tech. Chrome Apps run on ChromeOS, Windows, OSX, Linux, Android and IOS. And they are built using HTML and JS.

I don't think Chrome Apps work on iOS or Android. If they do, mind linking to confirmation?

Chrome apps do work on android

http://gigaom.com/2013/10/03/newest-chrome-beta-integrates-w...

That's only talking about normal web-apps, with access to only the normal web APIs.

> They are slower and uglier than native Windows/Mac/Linux apps. What's the point?

Eat your own dog food. Google developers test new HTML5 APIs.

Uglier? In general to me that doesn't seem to be the case, at least compared to Win/Lin applications.

I prefer using my email in the browser over any native email client. And as an added bonus, I get nearly the same user experience across my many disparate devices.

Seems kind of obvious yes? I mean if you're building an OS (ChromeOS) and you want to do native development, you build your tools to work in the OS right? Or am I missing something here? One of the coolest things about early databases was the 'web based' development environment, except for the sql injection attacks of course :-)

There's no "native" development. It's just HTML and CSS. Don't know why we would need another "IDE" to write html but whatever....

The native runtime environment for apps in ChromeOS is HTML/JS/CSS. The term "native" is not always used to refer to on-the-metal environments.

There will be at least three development platforms called Spark now, the others being http://spark.incubator.apache.org/ and https://github.com/meteor/meteor/wiki/Spark

> Dart meanwhile is Google’s open-source Web programming language, which has an ultimate goal of replacing JavaScript. Polymer is Google’s library for the Web, built on top of Web Components, and “designed to leverage the evolving web platform on modern browsers.”

Go, Dart, Angular.js and now Dart and Polymer. Am I the only one seeing the next wave of confusions?

Because the web was simple and homogenous before this?

I will be fair and the answer is no, but at least for the last 2-3 years we have a little stable environment. If it's ruby app we know it's rail, if it's Python we know it's either Django or Flask (or Pyramid). When we think about client side we think of jQuery and pure Javascript. I know there are coffee script lovers and I admit it's great that people coming up with new tools, but we have too much to digest.

There is a certain degree of peer pressure coming from our co-workers and our webdev community - if you are programming in PHP you are doing it wrong or if you are still doing MVC and not single-page app or node.js you are behind the trend. I have little knowledge about what Dart does but from multiple sources people seem to think Dart is Google's alternative to Javascript, which makes me uncomfortable because I start to feel like I am at the second Web/browser war where large organizations like Google is pushing their own version of "Javascript" (back then we got what? javascript, active script? etc?).

>I will be fair and the answer is no, but at least for the last 2-3 years we have a little stable environment. If it's ruby app we know it's rail, if it's Python we know it's either Django or Flask (or Pyramid). When we think about client side we think of jQuery and pure Javascript.

If you think that, then you're misguided.

Supposedly nothing is stopping angular.dart from working with polymer.dart.

What is the practical use case here? Before this there were Microsoft HTA's and Mozilla's XUL apps, neither of which had widespread adoption among developers.

Short:

* HTML apps potentially will work everywhere (if you will take care they will at least work on Firefox, Opera and Chrome).

* There are HTML5 tools and knowledge already in place. Plus years of experience in HTML can be used.

Long:

IMHO developers should look into the future here not into today but even today you can do quite a lot. XUL most probably failed because there were no tools, learning material and libraries (I'm not sure about HTA). In addition XUL worked only on single browser. I have managed to write XUL app 7 years ago but I had to invest quite a lot of time and the whole development process was quite slow.

HTML apps meanwhile do not require quite a lot of investment and if you already have some HTML5/CSS/JS knowledge there are only several holes of knowledge to fill. The only problem is to select good tools, find out right information and you can start right now. E.g. if you have canvas based game or static web site with useful information you can create app now: just add application cache's manifest file, add some meta information (in case of Firefox OS create *.webapp file) and you are done.

My background: I don't know HTA. I am familiar with XUL. In addition I'm familiar with QtQuick (QML + JavaScript), Firefox OS Apps, I guess I could learn developing Chrome Apps pretty quickly. I'm familiar with native development for Windows, Linux Desktop, Android and iOS.

HTA (HTML Application - http://en.wikipedia.org/wiki/HTML_Application) was Microsoft's foray into sandboxed HTML + CSS + JS applications back in 1999.

Ouch, I have worked with this once. That is living (dead?) proof that ideas are nothing and implementation is all what matters. I remember that I had even to do some very exotic workarounds using C++ to overcome one shortcoming of HTA.

Dandy, but Chrome Apps will only ever be marginally more widespread than ChromeOS.

Q. Why? A. Node-WebKit Apps aren't crippled with the sandboxing of the Chrome App API and easily let me target Win/Lin/OSX without requiring the Chrome runtime.

FWIW, I like ChromeOS and would buy a couple of ChromeBoxes for family members, if they had reasonably sized hard drives (200+GB)(SATA) for pictures & videos, and weren't so dependent on Google Drive. Non-tech savvy _NEED_ ChromeOS, they don't need GDrive.

How many of us need yet another IDE for HTML5, CSS & JS? Not me, thanks though. Please Google, get back to autonomous cars and get serious about ChromeOS already.

Great looking forward to this, as I believe this strategy of being able to hack directly on a shared code-base from a browser-based IDE will end up being the most productive environment, especially if it's integrated and can easily consume managed PAAS infrastructure services without the hassle of maintaining or trying to scale them yourself. Having an auto-updated IDE will also be a nice change.

I haven't been excited about web-based IDE's previously as all the ones I've tried have been clunky and slow, but it looks like this is being built with Dart so should offer better start-up and runtime performance given it will be running natively on the DartVM inside Chrome App.

Looking forward to the day that I'm able to login, hassle-free to any ChromeOS PC and have instant access to my working environment. Which will be useful if you ever want to upgrade your workstation, e.g. when it breaks down or a shiny new model comes out.

Chrome is becoming the new IE6. Just yesterday I got notified of some new feature in Gmail... of course it worked only in Chrome. Fuck that.

> Chrome is becoming the new IE6

Web developers hated IE6 not for new features it had. It was hated for lack of bug fixes and no new releases.

IE7 was released 5 years after IE6. Chrome is updated every 6 weeks.

Before Android, I would have been super excited to read this, but now...?

Seems like it's yet another technology that Android will soon be steamrolling.

Could you give any reason for your excitement for Android? Android is popular now but that does not mean that it will be popular forever. Fort Model T and Sony Walkman are good examples of things that were popular once.

I never said I was excited about Android nor that it will be popular forever.

I was just observing that Google's strategy regarding Chrome OS makes no sense to me in the presence of Android.

Android is quite poor desktop OS :)

Quick link: https://github.com/dart-lang/spark

Any relationship to the cloud IDE Brightly that seemed to have been killed somewhere in 2011-2012? The leaked 'Future of Javascript' Google memo from 2010 mentions they expected Brightly to be the first app written in Dart (which was called Dash at the time).

Chrome Apps did not work so far(zero traction), why do they want to waste ever more time on it?

So this is like Adobe AIR? (FYI Adobe AIR also supports HTML in addition to Flash)

No. This is a development environment, not a runtime.

Yes, Chrome Apps can make use of the Chrome Platform API which allows them to do all kinds of privileged things (if the required permissions were given).

http://developer.chrome.com/apps/api_index.html

So... yea, it's very similar. Both are some sort of web-related runtime which can be used for all kinds of applications thanks to additional APIs which make the environment less restrictive.

they gonna end up giving such developer access to everyone where we'd be making standalone app every other day in short more power and more apps i am super excited about it.

Yes, just what we need, more crappy apps.

how can you be so sure of that and even if i will come up with crappy apps maybe some big professional company comes up with something that you will end up using you never know...;)

"Dart meanwhile is Google’s open-source Web programming language, which has an ultimate goal of replacing JavaScript." Good luck on that. On my side if I were to see JS replaced I would choose Lua as a replacement.

why not byte code then we all get what we want.

Integrate with Google Drive and I'm sold.

Files will use the chrome file syncing api.

I look forward to the day when chrome is the only OS and all the proprietary OSs have finally died out.

You don't see Chrome OS as proprietary? It might be "open" but Google surely has a massive stake in it?