Forgot your password?
typodupeerror
Chrome Google Programming

Google Is Building a Chrome App-Based IDE 209

Posted by timothy
from the never-close-your-browser dept.
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."
This discussion has been archived. No new comments can be posted.

Google Is Building a Chrome App-Based IDE

Comments Filter:
  • by Neuroelectronic (643221) on Friday November 22, 2013 @07:59PM (#45497299)

    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.

    • by girlintraining (1395911) on Friday November 22, 2013 @10:13PM (#45497941)

      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.

      • One need only look to the recent example of Java and it's failed sandbox to recognize the problem here.

        Yes but this one is web so its in the cloud where as java is legacy.

    • by Anonymous Coward

      what value are they getting? control. and, more people that use their shit, the more people see their name, make apps in their store (which generates lots of user data for google to mine), use their browser, use their tracking / analytics bullshit, use their mail, and when google makes an 'offline' client-side framework, think of all the data they can collect off local devices....

  • by Joining Yet Again (2992179) on Friday November 22, 2013 @08:01PM (#45497313)

    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.

    • by Rob Y. (110975) on Saturday November 23, 2013 @11:23AM (#45501035)

      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?

  • by Anonymous Coward on Friday November 22, 2013 @08:03PM (#45497319)

    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.

    • I like the idea of Firefox OS phones though, in that environment you don't have that many layers, just the web crap and javascript host that you needed anyway to look up web pages. It has the uglyness and inefficiency you complain about but at the same time the OS is kept small, gets security updates and you would be able to download those security updates easily enough through 3G/4G or wifi. The execution speed problem is dealt with by throwing brute force at it (low power, 1GHz ARM). If security/privacy f

      • I like the idea of Firefox OS phones though, in that environment you don't have that many layers, just the web crap and javascript host that you needed anyway to look up web pages. It has the uglyness and inefficiency you complain about but at the same time the OS is kept small, gets security updates and you would be able to download those security updates easily enough through 3G/4G or wifi. The execution speed problem is dealt with by throwing brute force at it (low power, 1GHz ARM). If security/privacy features are adequate that's the first smartphone/phablet thing I can consider owning. (domain blocker, NoScript equivalent, fine grained permissions along with global rules like "any application that uses GPS can't use networking")

        exactly, the *idea* of FFOS. how do you know carriers don't add tracking / spying software into the phones running FirefoxOS? i don't think FirefoxOS is in some commanding market position where they can demand carriers don't touch the software of devices running on their network.

        • by narcc (412956)

          exactly, the *idea* of FFOS. how do you know carriers don't add tracking / spying software into the phones running FirefoxOS?

          If you're paranoid, just build it yourself. [mozilla.org]

        • by Lennie (16154)

          Buy your own FirefoxOS phone instead of paying your carrier, usually paying for it yourself actually turns out to be cheaper.

          At least in Europe SIM-free (unlocked) is a lot cheaper than a subscription with phone.

          If you take the difference you pay extra per month, the phone is usually slightly more expensive on contract than off contract.

      • global rules like "any application that uses GPS can't use networking"

        How should a navigation application that doesn't use networking obtain maps of the area around the device? Or how should a navigation application that doesn't use GPS know where the device is located?

        • I can zoom the map myself to know where I am, and as for the GPS data it can be used to record trips on local storage without sending the data to Google or another 3rd party.

          • by tepples (727027)

            I can zoom the map myself to know where I am

            But how would you know on which point to zoom if the application cannot use GPS to display your current location as an icon on the map?

            and as for the GPS data it can be used to record trips on local storage

            Perhaps I don't know how people use GPS-enabled devices in the real world, but I was under the impression that far fewer people have a need to "record trips" than to see where the stopped vehicle is located with respect to the map around it right freaking now.

        • Disclaimer, the settings/options I talk of are a wishlist rather than something I know is existing, I don't know how stuff work on current - still early - Firefox OS. Never seen a phone with it yet.

    • by squiggleslash (241428) on Friday November 22, 2013 @10:11PM (#45497925) Homepage Journal

      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.

    • by swillden (191260)

      I really don't get the point

      Hardware and OS independence?

      • by noh8rz10 (2716597)

        except it will never be truly hardware and os dependent. right now even web pages do better or worse depending on the 'puter i'm using. don't you see? the dream of independence is just a mirage.

        • by Lennie (16154)

          But the 'web runtine' (HTML, CSS, JS) is a lot closer than all the other runtimes at being operating system independent.

          It usually is just a matter of not using the very latest features. Everything pretty much works.

          You are forgetting an other advantage of the web is: there is nothing to install, the runtime is already available.

    • Often a device manufacturer is willing to expose a web browser but not a compiler to the unwashed masses of amateur developers. For example, the first Wii homebrew games appeared in early 2007 as Flash objects and JavaScript programs running inside the "Internet Channel" browser by Opera.
    • This browser based app must bring something new to the table to be relevant. My guess is that it will greatly simplify multiple people collaborating on the same project. Solutions already exist but they are not nearly as seamless as they could be. I still remember seeing Smultron [peterborgapps.com] for the first time and being very impressed. As far as text editors go, it's nothing special but the ability for several people to edit the same file at the same time was (and still is) impressive.

      No one knows exactly how th

      • greatly simplify multiple people collaborating

        A decent VCS won't work better just because you're connecting to a development machine in the cloud via RDP/VNC - and neither will it just because you connect to it via HTML+Javascript.

        No one knows exactly how this project will turn out but you can bet Google has their reasons for funding it.

        Yeah, to advertise to you, or to gather your data to sell to advertisers. The same reasons Google does absolutely everything.

        • by Lennie (16154)

          Distributed VCS is how collaboration is solved.

          Sometimes you want realtime collaboration though, someone to talk to, to show you how to do things, to tell you what you are doing wrong while you are doing it.

          Or just straight pair programming.

          The web already provides all the pieces: microphone/webcam support, real time communication, just look up webrtc.

          Combine that with an online editor like etherpad or more advanced for collaborate online code editor.

          • Remind me again why developers would not install development software? If you're sitting at a PC 8+ hours a day for weeks/months/years then you're sure as hell going to spend 30-60 minutes (or 5-10 minutes, if your IT dept are good) setting everything up properly to make it as efficient as possible.

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      But what else are people supposed to do? Technology has allowed farming to occupy barely 1% of the population compared to 50% in the 19th century. We've decided as a society to not accept this progress to reduce the workweek. We still expect everyone to "work" to "earn" things, even though we all keep saying how "productive" we are and how technology is powerful.

      Yet now we need both heads of a family to work, to pay more taxes than ever, to get fewer services as we hire more and more "competent" (they went

    • You hit the nail on the head. Keeping people employed is not a bad thing though. If a tool allows mediocre developers to be productive members of society
      without retraining, that is a GOOD thing, even if the tool isn't optimal in the absolute sense.

  • Local webapp (Score:5, Interesting)

    by paugq (443696) <pgquiles AT elpauer DOT org> on Friday November 22, 2013 @08:06PM (#45497325) Homepage

    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.

    • I think that, what they do well is go cross platform easy. moving C++/C# From windows, to mac to linux is hard, takes time. But webapps generally work anywhere. I agree that JS, CSS and HTML are a pain in the ass... I'd love to see something new that compared to C# in ease of coding and power, but had the interoperability of JS. I myself will stick with the more robust languages. I still learning and not a great coder yet so all the wishy washynes of JS, etc... drive me nuts.

      • Seconded. Programming languages --- you can have any 2 of: easy, universal, powerful --- but never ALL 3. Drives me crazy sometimes.
        • by Lennie (16154)

          But the web isn't about the programming languages. It's about the runtime that is already installed everywhere.

      • by Lennie (16154)

        If the only think you want (which might not apply to you) is other syntax then just transcompile to Javascript. Lots of 'languages' to choose from these days.

      • by paugq (443696)

        Local webapps are easy to port only because they are simple apps. Start adding the kind of complexity and features you have in native app developed in C++, C# or Delphi and we'll talk about porting complexity.

        Also, C++, C#, Delphi apps are expected to integrate PERFECTLY in the platform: colors, behavior, etc. Local webapps do nothing of that. No wonder there are no "porting complexities". Ugh.

    • Re:Local webapp (Score:5, Interesting)

      by Junta (36770) on Friday November 22, 2013 @08:36PM (#45497481)

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

      • I've even seen scenarios where developers have advocated for http over TCP as IPC for multiple processes that are related by common fork() ancestry

        Although I admit it sounds a bit odd on the face of it you get to use whatever frameworks help you deal with REST communications, plus also later you could more easily actually move those operations to separate servers.

        SOAP which of course has been plaguing the world for a long time

        It has been but it's really a paper tiger at this point, few people use SOAP anymo

    • by Ukab the Great (87152) on Friday November 22, 2013 @09:09PM (#45497691)

      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: (Score:3, Insightful)

        Beautifully put.

      • by LoztInSpace (593234) on Friday November 22, 2013 @10:59PM (#45498241)
        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.
      • by swillden (191260)
        So, what's the next insufficiency? At some point the web folks will say that web apps can replace desktop apps, and there won't be anything left that isn't covered. I think we're actually getting very close to that point.
        • So, what's the next insufficiency?

          Note that web apps still underpowered in terms of graphical capability.

          At some point the web folks will say that web apps can replace desktop apps

          Just like at some point it's inevitable we'll have flying cars?

        • So, what's the next insufficiency? At some point the web folks will say that web apps can replace desktop apps, and there won't be anything left that isn't covered.

          Good luck getting robust gamepad, webcam, 3D graphics, audio/video codec (WebM vs. MP4 format war), and shipping label printer support working across more than 90 percent of desktop and mobile browsers. For example, Apple has implemented WebGL in iOS but allows it only in iAds because WebGL in regular web apps would compete with the $99 per developer per year plus 30% of sales it gets from the App Store.

          Good luck getting robust multitasking and memory management in a mobile web application. In Chrome for

          • by swillden (191260)

            Good luck getting robust gamepad

            Lack of standardization may be an issue there, true. But games of significant complexity in general are going to be platform-specific. Of course, the bar for games that can work as web apps keeps rising.

            webcam

            That problem is already pretty well-solved. Google video hangouts work well across a wide variety of systems, for example.

            3D graphics

            There's no real reason that should be hard. We've had solid 3D graphics standards for decades, and while fragmentation due to rapid progress has been an issue (plus some deliberate MS-in

            • gamepad

              Lack of standardization may be an issue there, true. But games of significant complexity in general are going to be platform-specific.

              Yet somehow, SDL manages to abstract gamepad access across multiple PC platforms. True, the button order for non-Xbox 360 controllers varies considerably [pineight.com], but there are ways around that. I seem to remember XBMC maintaining a device description repository for game controllers.

              Drivers [for printers] in the cloud.

              That would just let Google see everything you print and mine it for keywords.

          • by Lennie (16154)

            Cisco said they would release a free H.264 encoder/decoder:
            http://gigaom.com/2013/10/30/mozilla-will-add-h-264-to-firefox-as-cisco-makes-eleventh-hour-push-for-webrtcs-future/ [gigaom.com]

            At least free in the sense of: free to download, I don't need to pay MPEG-LA or be worried about their patents.

            Cisco is paying for that.

      • I doubt there will be a time when we wont be using fat clients but I see myself and the general public using and needing them less as every year passes.

        I have a pretty decent rig by any standards these days, full capable of running Crisis 3 at max settings and 60 FPS with about 12 terabytes of local storage available. I used to log onto my PC every day and sit there poring over documents, reading crap off the net, looking at pictures of cats and wasting time on slashdot. I'd fire up my IDE and get some work

      • by Lennie (16154)

        The advantage for the 'web folks' is:

        The operating system on the device people buy already comes with a runtime for running 'web apps', aka browser.

        By default you run it in a sandbox and the application running in the sandbox is automatically updated every time you open it. A website is updated on the server, anything that needs downloading again gets downloaded again (even if it's a HTML5 offline 'application').

        No other runtime has these advantages.

    • by jon3k (691256)
      I think you make a good point, but I also think the ability to deliver apps easily and provide broad cross-platform compatibility with web apps (html+css+javascript) offers some advantages as well. It also allows us to use the same set of tools to develop local applications as web based applications, which is more accessible to a broader set of developers.
  • What kind of terrible crackpots are these guys. Any PHB will tell you if it wont look right in IE 6 then something MUST be wrong with the developers.

    After all they create things with FrontPage 2000 all the time. How hard can it be?!

    • Anything on the web which requires more than IE6 is excessively complicated or needless eye-candy.

      The web is first rate for delivering information, and third rate for delivering software.

      • I hate IE6 -- being a normal sensible human being --- but your statement is so true about the kludge of the level of reliability and consistency of "online software".

        (Which is sadly why a lot of it is made in Flash and avoiding browser kludge --- ugh!)

        One example: My Android phone's default web browser cannot use the Gmail.com site correctly!
  • by Qbertino (265505) on Friday November 22, 2013 @09:08PM (#45497683)

    What's all the excitement? The General Interface Builder [generalinterface.org] 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.

    • by Gramie2 (411713)
      GIB looks interesting, but the last release was more than two years ago.
    • by Lennie (16154)

      Cloud9 IDE is also exists, but a large company pouring money in this space might have an even bigger impact.

      At least that is how I see these articles.

  • by Anonymous Coward
    What's next? An IDE that lets me browse the Web? A word processor that lets me drive CNC machinery?
    • by chill (34294)

      EMACS was released in 1976 and I'm pretty sure can do both of those things.

      • by narcc (412956)

        EMACS is pretty amazing. I'd switch over myself, but it really needs a better text editor.

  • by Karlt1 (231423) on Friday November 22, 2013 @11:01PM (#45498263)

    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.

    • by narcc (412956)

      What?

      Of your examples, the first comes closest to reality. It's wrong, of course, but you could make a good argument.

      The original iPhone browser wasn't (and still isn't) good enough for high-quality web apps. Of course, at the time, neither was any browser. If you'll recall, Apple didn't seem interested in third-party apps at the time. They were much more interested in controlling what apps were on the platform. (The ability to local/offline local/offline web app with a nice icon on the home screen icon

  • Komodo, anyone? (Score:2, Interesting)

    by Anonymous Coward

    So, basically Google is taking it on itself to do for Chrome what ActiveState did for Mozilla years ago -- which led to the excellent and constantly improving Komodo IDE (build on the Mozilla framework)?

  • This is just about the most inefficient programming combination ever devised, with the possibly exception of machine code without libraries. Why in the world doesn't Google provide a real language so we can bypass the archaic syntax and semantics of html and css? HELP! I'M STUCK IN THE MESOZOIC ERA OF PROGRAMMING AND I CAN'T GET OUT!!!
  • For those who don't know, Chrome packaged apps are written in HTML, JavaScript, and CSS,

    I didn't, but now I know to avoid them like the plague.

    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

    And there's another good reason.

Forty two.

Working...