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.
>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).
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.
"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?
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.
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.
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.
* 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.
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!
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.
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)
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 :-)
> 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?
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.
* 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.
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.
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.
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).
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).
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.
"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.
[+] [-] spankalee|12 years ago|reply
[+] [-] RivieraKid|12 years ago|reply
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 :)
[+] [-] spankalee|12 years ago|reply
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.
[+] [-] zobzu|12 years ago|reply
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.
[+] [-] ahoge|12 years ago|reply
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.
[+] [-] coldtea|12 years ago|reply
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).
[+] [-] techzomby|12 years ago|reply
[+] [-] reidrac|12 years ago|reply
If you want an example, see OpenOffice.org and LibreOffice.
[+] [-] isaacwaller|12 years ago|reply
[+] [-] pkulak|12 years ago|reply
[+] [-] magicalist|12 years ago|reply
[+] [-] ams6110|12 years ago|reply
[+] [-] haberman|12 years ago|reply
- 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
[+] [-] wepple|12 years ago|reply
[+] [-] balac|12 years ago|reply
* 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.
[+] [-] dragonwriter|12 years ago|reply
They are the "native" apps for ChromeOS that, incidentally, can also run anywhere else* that Chrome OS runs.
* except iOS
[+] [-] tluyben2|12 years ago|reply
[+] [-] mythz|12 years ago|reply
[+] [-] dgregd|12 years ago|reply
Eat your own dog food. Google developers test new HTML5 APIs.
[+] [-] taude|12 years ago|reply
[+] [-] bmelton|12 years ago|reply
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.
[+] [-] trentmb|12 years ago|reply
It's basically Java, but Google made it. Your Chrome Apps can run wherever Chrome does.
[+] [-] ChuckMcM|12 years ago|reply
[+] [-] mariusmg|12 years ago|reply
[+] [-] nmb|12 years ago|reply
[+] [-] yeukhon|12 years ago|reply
Go, Dart, Angular.js and now Dart and Polymer. Am I the only one seeing the next wave of confusions?
[+] [-] svachalek|12 years ago|reply
[+] [-] bitemix|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] nhebb|12 years ago|reply
[+] [-] daliusd|12 years ago|reply
* 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.
[+] [-] busterc|12 years ago|reply
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.
[+] [-] mythz|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] Grue3|12 years ago|reply
[+] [-] dgregd|12 years ago|reply
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.
[+] [-] laureny|12 years ago|reply
Seems like it's yet another technology that Android will soon be steamrolling.
[+] [-] daliusd|12 years ago|reply
[+] [-] ecesena|12 years ago|reply
[+] [-] Rafert|12 years ago|reply
[+] [-] ghostdiver|12 years ago|reply
[+] [-] wiradikusuma|12 years ago|reply
[+] [-] ahoge|12 years ago|reply
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.
[+] [-] untog|12 years ago|reply
[+] [-] TIJ|12 years ago|reply
[+] [-] coldtea|12 years ago|reply
[+] [-] islon|12 years ago|reply
[+] [-] toddan|12 years ago|reply
[+] [-] frodopwns|12 years ago|reply
[+] [-] patrickaljord|12 years ago|reply