Google's Web App announcement

Google just announced that towards the end of 2017 they'll be phasing out Web Apps (of which the Web IDE is one):

http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html

I've been contacted a bit about this already, and there is an issue open in the Espruino repositories here: https://github.com/espruino/EspruinoWebIDE/issues/144

But basically:

• There's no panic, nothing is going to change for at least a year
  
• I have a plan B, in that there is a native version of Espruino already available in the form of an 'Electron' app - I'll just have to start producing platform-specific installers for it, and might have to tweak a few things to keep the 'projects' plugin working.
  
• This may end up being good(ish) - it might mean Google open up Web USB and allow you to use the Web IDE without having to install anything at all, which may mean Android support too.
  
  

But yeah, either way it's more work for me, reimplementing stuff that previously worked fine, and less time I get to work on making Espruino better - so it's not great.

Also pretty shitty of Google to just announce it without having given any warning to owners of apps on their platforms. If you're as fed up as I am, feel free to let them know on their blog post

To me Chrome is like ChromeOS hosted by other OSs... like host and guest OS without having to install/run VM... So yeah... some changes are in store.

Perhaps they are pushing "Progressive Web Apps" instead of "Chrome Apps", while this is totally uncool now, in the future it could be.
"Progressive Web Apps" wouldn't be chrome dependent and would work on all OS's, as-long as they have a browser like Chrome or Opera. They would be fully usable without installing anything first, then if you return to use the service again it will ask if you'd like it in your app draw/home-screen.
In that scenario using the Espruino IDE could be as simple as clicking a link (Provided WebUSB fix whatever it is they are doing) to use it the first time. Then if you use the IDE again it will prompt you to "Install" it (Sort of bookmark it to your home screen, but cache it to work off-line, and look more native)

So in the short term, this sucks and its a pain in the ass for anyone who developed for Chrome. I first thought, "WTF? Won't this just make nobody make apps for ChromeOS? Why would they do that?" but after reading about these PWAs I think it will make developing "Native" apps far easier, only a little more work than the website itself. I was looking into the "Ionic Framework" to build some apps to communicate with the PuckJS when that drops, but if these "Service Workers" can do what they say, It could be far easier to make a website and make it a PWA, they can even do notifications, even when the app is closed.

PWAs could be useful for PuckJS, if WebBluetooth is available it could let us share our partner apps with the community without having to pay the fee to get an app onto the market, then they could also work from PCs and Phones.

I'd suggest checking this out, read it, then just go mad following links learning about everything it has to offer. My favorites are the PWA Service Workers, Push API and the Background Sync API.

TL;DR: This sucks, its a pain. But PWAs are cool.

Totally - PWAs are definitely the way to go, and I'm hoping to tweak the Web IDE such that it can run as one, fully offline. It already works pretty well as-is.

The problem is the IO. There is currently no way for a PWAs to:

• Access your filesystem in any meaningful way (so no projects/modules any more)
  
• Access a USB serial port
  
• Make standard socket connections (so no Telnet connection to ESP8266 any more)
  
  

and probably some other stuff I've forgotten too.

And that's what sucks - Google just removed a load of functionality that actually cannot be replaced with PWAs at the moment, even if I did spend the time rewriting the Web IDE.

"Don't you know that life has moved to the cloud? What are you dicking around with I/O for?"

Yeah, I imagine the idea that someone might actually want access to something in the real world didn't occur to Chrome's management at all :(

Those of us old enough to have been around for the development/introduction of java, plug-ins, etc., have seen this dance before. The Chrome Web App dealio was nice, but nothing innovative. It's all been tried before.

And it seems to always end the same way. The reasons are obvious: As long as there are different platforms (which will always be), there will be cross-platform work necessary to support applications across them. This reduces the issue to simply, WHO is going to do that on-going engineering? The app developer or the platform provider?

As another entrant in this space, we have Flash as well. And others. It's an intractable problem.

Google should be ashamed of their treatment of developers for things like this.

"Here, use this new framework, it'll be awesome!" Couple years later, "oh, you used it like we told you to? Sucks to be you, we're dropping it" and they hang all the developers who trusted them out to dry.

As far as local TCP, I've been working hard on integrating web socket server in the esp8266. It's a fairly simple protocol on top of the initial HTTP handshake and browsers can connect to it no problem. I could help code up support if you wanted to head that direction.

Yeah, I imagine the idea that someone might actually want access to something in the real world didn't occur to Chrome's management at all :(

Actually I was one of the main people pushing for access to the local filesystem in chrome apps and got the API added. There were people in product management that explicitly were opposed to this because it's not the direction they wanted to go with ChromeOS. It allows too much offline autonomy. I thought I had won the war when we got is pushed through and Google would have to support the API forever, but I guess they showed me.

Generally speaking, Google engineers are amazing people who do amazing work, but their management sometimes shuts down good ideas if it doesn't line up with the company's product vision. (Which to be fair is their job.) We only get upset and angry when we forget that we developers aren't their stakeholders and they do something not in our best interest.

Google should be ashamed of their treatment of developers for things like this.

I think so - but the news of this seems to have been and gone and nobody really cared. I guess it'll hit the news again when everything stops working though :)

WHO is going to do that on-going engineering? The app developer or the platform provider?

Yeah, Web Apps looks great to me specifically because I'd done multiplatform app development before and knew how much it sucked and what a support headache it was... But with these platfiorms they don't make money from on the actual apps people make - so it's hardly surprising it's hard to justify continued funding.

The issue for me is that with Java, you had a JRE redistributable that you could use. Even if Sun/Oracle died, you had that file and could bundle it with your application. With Chrome you don't have that - Google are actively pushing updates so even if people could install the correct version of Chrome, Google would blow it away with one that didn't have the features.

@creationix that'd be great. You know that https://github.com/espruino/EspruinoWebIDE can do WebSockets via node.js now (check out server.js)? So realistically you just need to embed the server, and then serve up index.html.

You can do it right now in JS - something like:

function onPageRequest(req, res) {
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end(iframe_linking_to_webide);
}

var server = require('ws').createServer(onPageRequest);
server.listen(8000);
server.on("websocket", function(ws) {
    ws.on('message',function(d) { LoopbackB.write(d); });
    LoopbackB.on('data', function(d) { ws.send(d); });
    LoopbackA.setConsole();
});

But it'd be great if Websockets could be added to the existing C-based HTTP server as a first class citizen (it might still need to bit of work to cope with software resets, but it shouldn't be too painful)

Of course the other option is for someone to make a web service that accepted socket connections from an ESP8266 and served up the Web IDE?

Ideally there would be some secure connection though (unless it was local only)

The web service idea works fairly well and is what I did for my talk in Paris
. It's also how all the IoT startups are doing it, but I suspect this is partially so they have a service to sell and some degree of control.

I don't like that it depends on active internet which is often a problem for my use cases (hacking while commuting/traveling). Also it's a pain to switch the microcontroller to a new wifi network when you change locations.

With AP that serves websockets, a webpage can connect and configure the device to use the local wifi or simply stay in AP mode if the programmer doesn't need or have internet.

You probably don't want to do the server in JavaScript. My experience doing this with nodemcu is it's too heavy for the poor little ESP8266. Making a minimal server that does just enough HTTP to perform a websocket handshake won't be too hard. It could also serve a minimal http page that bootstrapped the full IDE from the net and cached the resources locally in the browser so the IDE could work offline, but without the chip hosting all the content.

Anyway, I'm currently working on the offline-first web IDE platform and will happily bring over the tech once I've worked out the kinks. I might just give up on making my own langauge and use espruino since it's so nice.

I should mention that a local web server that serves the website as well as listening for tcp connections works well, but then you're back to needing a local native app (chrome app for ChromeOS or something else for everything else), but perhaps a minimal node server installed via npm is easier than a full on electron app.

but I suspect this is partially so they have a service to sell and some degree of control.

:) Yeah... It does seem to be the business plan of 90% of IoT companies...

You probably don't want to do the server in JavaScript.

The HTTP server in Espruino is actually written in C. It's relatively efficient... Currently WebSockets are in JS but it wouldn't be desperately hard to add websocket support in C as well.

The only gotcha is that the server uses JavaScript variables to store state + data, so when doing a full reset (or load/save) the websocket connection would need to reset. I don't think that's such a big deal though.

Either way, IMO it's not a great idea to have two HTTP servers in Espruino, so finding a way to use the existing one would probably make life easier :)

I think so - but the news of this seems to have been and gone and nobody really cared. I guess it'll hit the news again when everything stops working though :)

More "punch drunk" than uncaring.. SEO moving goalposts, Google Reader retirement, various API deprecations, and now Chrome Apps.. It's what we've come to expect/accept.

What you mean is
YOUR life has moved to the Cloud. Embedded projects have NOT per se moved to the Cloud.