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

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

[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...

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.

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.