Google Is Building a Chrome App-Based IDE

An anonymous reader writes "Google's Chromium team never ceases to amaze. Its latest project is a Chrome app-based Integrated Development Environment (IDE) codenamed Spark. For those who don't know, Chrome packaged apps are written in HTML, JavaScript, and CSS, but launch outside the browser, work offline by default, and access certain APIs not available to Web apps. In other words, they're Google's way of pushing the limits of the Web as a platform."

Comments

A browser is not an iPod

[Neuroelectronic]

and the way Google does this is by moving processing to the client but maintaining control of the APIs. Which raises the question, in my mind, exactly what value is Google providing that you can't get from existing open APIs and platforms? Seems like the only thing they are "providing" is an expectation in your clients that you support Chrome only, and an API that is guaranteed to break and need maintenance in the near future.

Re:A browser is not an iPod

[girlintraining]

the only thing they are "providing" is an expectation in your clients that you support Chrome only, and an API that is guaranteed to break and need maintenance in the near future

You're forgetting; A browser is supposed to be a sandbox app. That is, its job is to render data and present an interactive interface to the user -- but not allow automated access to resources on the host system. Their APIs break that. Badly. One need only look to the recent example of Java and it's failed sandbox to recognize the problem here.

spam wonderful spam

[Joining Yet Again]

An "anonymous reader" wrote:

Google's Chromium team never ceases to amaze... ...Google's way of pushing the limits of the Web as a platform.

There's nothing amazing about making everything into a fucking HTML+Javascript app with a lowest common denominator of UI features requiring a PC built in the last 3 years and being sufficiently crippled that you'll want to store everything on the "cloud", i.e. on Google's servers.

No, fuck off, Google. I've done dumb terminals, and then terminals with a bit of intelligence+local storage to make things just bearable enough that you're still conned into giving yourself over to someone n thousand miles away who cares as much about your data as he worries about losing the $0/month you're paying him for service.

Re:spam wonderful spam

[Rob Y.]

Who said the cloud servers have to be Google's?
Any application based off of a central database has no business being built as a desktop application. The support of web-based apps is just orders of magnitude simpler, and they work better than fat-client apps when deployed across multiple locations. Anything that makes building this kind of app easier and cross-platform, while producing a richer user experience than existing HTML stuff is a good thing. You don't have to use it for everything, but why are you so opposed to it existing?

What the hell is the point?

[Anonymous Coward]

I really don't get the point, other than keeping computer people employed through layers and layers and layers and layers. As computers get more powerful, it seems software only gets more needlessly complicated and accomplishes the same thing at the same speed as it used to using old hardware and far less code and layers.

Re:What the hell is the point?

[squiggleslash]

Basically everyone recognizes Eclipse is a load of crap.

Some would say this is because it's a poorly designed mismatch of "integrated modules" written by developers who had half of a good idea, implemented half of it, and then gave up, leaving the rest of us to put up with things like autocompletion systems that physically get in the way, bizarre default file associations, and "features" like network access that are rendered virtually unusable by being buried by several layers of confusing "user friendly" GUIs.

Others, such as Google, however, believe the problem with Eclipse is that it's written in Java. If only it were written in something logical like CSS, maybe coupled with something readable like HTML, perhaps held together with something stable and feature complete like Javascript, which can control the other elements using something intelligently designed, standardized, and completely quirkless like the Document Object Model, you'd have an IDE that would truly shine.

Re:What the hell is the point?

[squiggleslash]

There was more than a dash.

That said, I kinda felt bad slamming JavaScript - I don't mean "Web browser" (which most people who slam JS mean, ie "I hate JS, there' no way to create a file, and manipulating the DOM sucks!" is not a criticism of JavaScript, it's a criticism of web standards that integrate JavaScript) - I think it's a woefully underrated language that gets a bad rap because most people have to use it in conjunction with the aforementioned terrible APIs.

It's clean (mostly), scores well for readability (there's a reason programmers prefer JSON to XML) and allows the kind of casual programming that, say, PHP is famous for without having any of the "features" PHP is infamous for.

I'm glad projects like node.js are taking off, these are giving the language, finally, a chance to shine.

That said, of course, in this case, we're talking about the holy hell that is JS-in-Web-APIs. Even given Google is giving the system additional APIs so it can save files locally, the fact it's going to have to interact with the user through the DOM will ensure the language continues to get slammed for no good reason.

Local webapp

[paugq]

First we tried to replace desktop apps with webapps and that's why we stood the awkwardness and immaturity of JavaScript, CSS and HTML. At least, we could justify it by saying "you'll be able to access the application from everywhere" (not true: new versions of browsers broke apps everytime)

Now, we are using those same immature and awkward technologies (JS, CSS, HTML) to develop local apps, which could be developed in C#, C++ or even Delphi in a fraction of time, integrate better with the platform and have more direct access to local APIs. I'm sorry but I don't understand this.

And yes, JavaScript, CSS, etc are way immature if you compare with what you can do in C# (WinForms, WPF), C++ (Qt, Boost) or even Delphi. The debugging process in itself is a nightmare.

Re:Local webapp

[Joining Yet Again]

Show them a traditional fat client and they think it's weird and awkward.

You're just making shit up. "Apps" are the Big New Thing. Never before have there been so many "traditional fat clients". The thing is they're only being released for mobile platforms, while the PC platform desperately tries to get rid of them. And why? Because two or three huge companies hate Microsoft, and think this is the way to wrest control of the APIs.

It's working.

But it's not for the user's benefit - at all.

Re:Local webapp

[Junta]

Adding my rant, particularly about how this is far from an isolated incident...

Some notable examples....

Palm's WebOS bragged on how developers *got* to use javascript and css to develop local applications.... Despite some decent UI design elements, the thing was a beast to develop for in that model.

Gnome 3 in it's infinite wisdom has gone to javascript and css for their shell...

iPhone in its original vision figured web browser would suffice before realizing pretty quickly that a decent framework would be called for...

Of course we also have the peculiar entity of Node.js, because web developers had to deal with languages that were just too reasonable in the webapp server space (yes, I know the I/O semantics natively act in a reasonable manner, but things like eventlet bring that sort of model to python).

It's related to the phenomenon where so many vocal developers believe if you do *anything* over a network it better be http. I've even seen scenarios where developers have advocated for http over TCP as IPC for multiple processes that are related by common fork() ancestory, meaning they couldn't possibly run on distinct servers (ignoring the massive security exposure it represented on top of the weirdness).

Now there are decent and reasonable things in the space (e.g. network apis that reasonably *can* map to REST semantics can be explored decently) among the abominations (e.g. SOAP which of course has been plaguing the world for a long time, but still it's the best example of a widespread moronic standard over http for no good reason on top of being a mess in and of itself). Of course everyone jumping on the 'REST' bandwagon means a great deal of interfaces claim to be that way without really usefully being in that camp, and even in apis where it's done mostly correctly, developers think they suddenly have no obligation to write client libraries or utilities or even so much as document it. It's the latter that seems to be most prolific sadly...

Re:But...

[Blaskowicz]

Because the Chromebook. They already have a desktop web OS, which competes with Windows and Apple laptops, and it sure makes sense being able to develop web apps or Chrome apps from that environment.

Re:But...

[Joining Yet Again]

Imagine if Microsoft had released an MS-branded laptop which only allowed you to use HTML+Javascript and Silverlight apps, and then released a development environment which ran under Silverlight.

That'd be as retarded as this is.

Re:But...

[Anonymous Coward]

But this is Google! Goooooooooooogle!

Intriguing ...

[TrollstonButterbeans]

"They already have a desktop web OS [Chomebook], which competes with Windows and Apple laptops"

I guess Chromebooks are selling well --- but I haven't seen one in a store (I avoid "un-Best Buy") --- or one in real life.

Yet ...

I'll have to keep an eye out ...

Nothing new. GIB has been a browser IDE for years.

[Qbertino]

What's all the excitement? The General Interface Builder is basically full-blown bsd licensed browser-based offline IDE of Eclipse proportions. It's quite amazing, certainly speeds up development of non-trivial GeneralInterface Ajax Applications quite a bit and is very well matured.

I'm not holding my breath for Google to catch up on GI anytime soon.

My 2 cents.

Web People vs. Desktop People

[Ukab the Great]

Here's my memory of what happened. Maybe it's falsely implanted by the NSA. Feel free to mod down -1 Heretical.

When the web first was popular, the web folks told us that web apps would replace desktop apps. And the desktop people said "what about dynamic and interactive GUI's that fat client apps provide?" And the web people told the desktop people "users won't really miss that. HTML by itself is good enough." And when no one was looking, the web folks snuck JavaScript and DHTML through the back door to cover up the insufficiency they denied existed with web apps

Then later on, the web folks told us that web apps would replace desktop apps. And the desktop people said "what about asynchronous network communication that fat client apps provide?" And the web people told the desktop people "users won't really miss that. HTML + DHTML + JavaScript by itself is good enough." And when no one was looking, the web folks snuck Ajax through the back door to cover up the insufficiency they denied existed with web apps.

Then later on still, the web folks told us that web apps would replace desktop apps. And the desktop people said "what about the offline storage that doesn't require network communication that fat client apps provide?" And the web people told the desktop people "users won't really miss that. HTML + DHTML + JavaScript + Ajax is good enough." And when no one was looking, the web folks snuck HTML5 offline storage through the door to cover up the insufficiency they denied existed with web apps.

From my point of view I see an endless cycle of web zealots who keep saying that fat clients are irrelevant, yet who seem to be adding one layer of kludge after another just to keep up with basic fat client functionality that they keep denying is unimportant to users. After all I've seen, I really can't take web people very seriously.

Re:Web People vs. Desktop People

[LoztInSpace]

Very nice. Don't forget also that once introduced, each iteration is then actually hailed as something revolutionary rather than something missing and that was solved/commonplace years ago.

Haven't we heard this before?

[Karlt1]

2007 Apple - you don't need native apps. You can build great web apps. Developers complain. Apple released a native SDK.

2009 Palm. You can build great apps using the web technologies you already know. Developers complain. Palm releases native SDK.

2011 RIM announces that you can build great apps using the technology you know. Developers complain. RIM releases native SDK.

Re:Embrace and extend

[K. S. Kyosuke]

Except they're not forcing these extensions on anyone, Chrome the browser is still very much W3C compliant (for better or worse). It's just that it has an "extra mode" for running something HTML-based outside normal web browsing. I say let them experiment with whatever they want, that's perfectly fine with me.