Replacement for IDE?

Google has deprecated Chrome Web Apps like the IDE and you can now no longer install them into your browser. In early 2018 they will be removed entirely.

Is there going to be a replacement for the IDE or is the terminal the route of choice now?

There is the native version at the bottom of the page:

https://www.espruino.com/Web+IDE

Here is a pre-built installl for windows.

Thanks. Looks like the NPM based install would be most practical for OSX.

I'll put an installer for a MacOS and Linux app on the website tomorrow. Google gave app owners ZERO warning of this, so there's a bit of a delay I'm afraid.

If you have node and xcode then an npm install could be fine, but because of native modules the install can still be a pain. NW.js is definitely the easiest path at the moment, but I'll package it up to make it easier.

Thanks Gordon! No rush here, I just saw the news item and went, "hang on, there's one app I definitely need".

Once again, great product. Thank you so much!

Was the article you saw this one? https://arstechnica.com/gadgets/2017/12/google-shuts-down-the-apps-section-of-the-chrome-web-store/

Interestingly, while the apps section is shut down, you can still reach the Espruino IDE using its URL (linked from the getting started page - https://chrome.google.com/webstore/detail/espruino-web-ide/bleoifhkdalbjfbobjackfdifdneehpo) so it's not quite as serious as I had imagined - yet.

The problem I now have is that Google will almost certainly remove the chrome.* APIs from Chrome quite soon, so in 6 months they'll disappear from NW.js as well and I'll be stuck using an old version of NW.js.

I'm considering creating a native websocket-based server app instead - it'd be substantially smaller (Maybe 500 kB vs. 60MB for NW.js or Electron), and would finally mean I'm not wholly dependent on Chrome (it should work with Safari or Edge too). I could move everything towards using espruino.com/ide as well, which might open up some neat options (for instance for online storage of code/modules).

Does anyone have any strong concerns/thoughts about it? Right now it's my preference because I don't want to have to revisit this in 6 months - and building native modules for NW.js or Electron is way harder than just building a C++ app.

From what I read from Google is that they are trying to push the browser standards themselves so that no Google Chrome specific APIs should be needed. They have been speaking about it for over a year now (see https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html). From that it appears that the espruino.com/ide direction is future-proof.

@Gordon What exactly is there in the IDE that doesn't work in a browser? The terminal communication? What else is there that you would need the native server app you are writing about for?

Yes, it's a reasonable aim - the problem is they haven't provided equivalent functionality outside of the chrome web apps.

What exactly is there in the IDE that doesn't work in a browser?

• Serial port access
  
• Bluetooth LE access on Windows
  
• TCP/IP access (for those that use Telnet to ESP8266)
  
• Decent Filesystem access (eg for local module support)
  
• Proper 'storage' that's synced between devices
  
  

There might be a few more that I'm missing :(

While I could use the 'native messaging API', it's another chrome specific thing (although Firefox does implement it too) so I wouldn't be surprised if it disappears in a year or two.

From that point of view a local WebSocket based server seems easier, it's just one more annoying hoop users have to jump through.

100.00 USD is on the way.

Wow, thanks!

I'm working on the WebSocket server now and it's actually looking really promising - I'm using Qt and everything's slotting together really well. I have it working for Serial right now, and Bluetooth LE support should happen by the end of the day - and with any luck that'll be for all platforms.

Woo! Bluetooth LE support is now working - so hopefully tomorrow I'll do a bit more tweaking, will modify the Web IDE website to use it, get an installer done and we'll be sorted!

any chance to not be dependent on Qt ?

any chance to not be dependent on Qt ?

No.

Not unless you want to write and debug platform specific TCP/IP, Bluetooth LE and Serial interface code for Windows, Mac OS and Linux - plus installers.

What's the issue with Qt?

I am not fond of multi platform frameworks – the UI reimplementation looks out of place, bloated and you still have to fiddle with each platform quirks.

But I will wait for a beta and provide more concise feedback then.

The whole point of this is that there is a completely minimal UI - the actual Web IDE will run inside the browser. I'm far more concerned with making something that reliably and safely allows people to use Espruino boards with a browser of their choice.

The best kind of feedback would be in the form of a pull request. It's open source, so if you don't like the look of it then you're welcome to try and improve on it.

@Gordon The fact that we can start working with Espruino with just a browser is a killer feature IMO.

From the link provided at https://developer.chrome.com/apps/api_index it appears that the easiest migration path could just be to build an Chrome Extension (instead of Chrome App) as described at https://developers.chrome.com/apps/migration. The extension APIs are here to stay I think. But other stuff, like the USB access might need to get migrated to their web equivalents.

Not sure about the native installer.... at least the default use-cases for the Espruino boards should IMO just work directly from the IDE website for easy starters.

For more I would perhaps think about doing plugin for stuff like https://code.visualstudio.com/ or https://atom.io/ where the binary is maintained by the community already and it is a matter of installing a plugin (both could be based on Node.js infrastructure).

The fact that we can start working with Espruino with just a browser is a killer feature IMO

I know - but sadly there's no way around it (apart from via Puck.js, and perhaps at some point the WiFi-connected devices).

Extensions won't work as they can't use the serial API, so that means that you will have to install something on your computer to use USB (Web Bluetooth will still work) - so then we're left with a few choices:

• Install an native messaging extension for Chrome. You'll also need Chrome, as well as some crazy setup steps, and there's no guarantee that it won't die in the future as well.
  
• Install an NW.js/Electron app - this is what I do already on Windows and it's around 60MB (and is super slow to load), but the serial SPI will probably disappear in a few months when Google takes it out of mainline Chromium, so then I'll be back to building and packaging native modules into NW.js.
  
• Install a websocket server - small, fast, and works with all modern browsers using the same espruino.com/ide link as for Web Bluetooth
  
  

doing a plugin ... based on Node.js infrastructure

This just adds more pain. I don't know if you've tried to install the Web IDE with node.js from GitHub, but it's a nightmare. For instance if you have to build the native modules for serialport, that's a 15GB download and installation of Visual Studio tools so you have a C compiler. It's not a big deal for a Node.js developer that's already done it, but it's hardly 'plug and play' for anyone else.

Having the websocket server actually opens the door to having proper plugins for other Node.js apps though. I'll package the executables up into a Node.js module so there should finally be a plug & play Node.js system that doesn't require compilation if you have a non-standard node.js version.

@opichals, I usually keep 'things' separate, but

The fact that we can start working with Espruino with just a browser is a killer feature IMO.

comes close to be seconded with an Amen.

No matter modern thinking, the path is NOT the goal here: The tooling is not what I want be be bothered with, and Espruino Eco System really helps with focusing on what you want to do: enjoy MCs, explore IoT, and then making things...

@Gordon you are right, I am biased in that I already have the native node.js module requirements setup so I didn't see that.

Wouldn't WebUSB usable in the browser app (Chrome only too https://caniuse.com/#search=USB, with future uncertain it looks like)?

I was really hopeful about WebUSB, but it won't communicate with 'normal' USB serial devices - you need to put special firmware on them first... so then you still need something native to update the firmware so it'll work with the browser!

Also Google will probably kill it soon anyway :)

Everything is up here now: https://github.com/espruino/EspruinoHost

If you install the Qt dev tools and compile and run that, then go to https://espruino.github.io/EspruinoWebIDE/, you should see all your local devices!

It works for me on Linux, but so far I've only got it working on Mac and Windows with secure websockets disabled (which you have to do by tweaking the code) - but I believe the steps to fix that aren't too hard.

So then it's just a matter of getting pre-built software and installers :)

There are now builds available for Windows, Linux, and Mac OS - and instructions here: https://github.com/espruino/EspruinoHost/blob/master/README.md

If anyone wants to give this a try (with USB or BLE devices) I'd be really interested to hear how you get on!

Unfortunately it's not 100% plug and play because you need to use HTTPS, which requires that you install a trusted certificate for your PC. However this would appear to be something that can be done automatically by the installer in most cases.

LATER EDIT: quick fix to make it working on OSX.

steps:

1. brew install qt
   

2. copy files from /usr/local/Cellar/qt/5.10.0/lib to

   /Library/Frameworks/QtBluetooth.framework
   /Library/Frameworks/QtCore.framework
   /Library/Frameworks/QtGui.framework
   /Library/Frameworks/QtNetwork.framework
   /Library/Frameworks/QtSerialPort.framework
   /Library/Frameworks/QtWebSockets.framework
   /Library/Frameworks/QtWidgets.framework
   

quick feedback:

• 'Select a port' window:
  – items jump around as Bluetooth devices appear/disappear making it hard to select
  – duplicates for same device
  – unable to read the whole id due small window
  – lots of USB devices (outgoing and incoming) make it hard to browse

• connecting to a puck.js and sending commands works 👍

Great! glad it's going! Is it possible to copy those libs into the app package itself? I might just stick them on GitHub if so.

To be honest the items popping around has been an issue in all Web IDEs. It should settle down once everything has been discovered?

Also, you mention duplicates? What of? USB, or Bluetooth?

With the ID, I should just crop it down or something. For some reason MacOS doesn't let you access the device's MAC address, so the ID shown there is effectively useless.

What USB devices do you see? I don't see that many on my Mac - perhaps it could be filtered down though.

• copy frameworks inside the app – will make the app 35MB 😮
  
• duplicates - Bluetooth. saw same puck.js several times (3 times). then it disappears (after 5 seconds) and reappear again. maybe has to do with the scanning.
  
• USB devices - Bluetooth Incoming Port, not connected bluetooth speakers (incoming and outgoing)
  

Ok, thanks - I'll see about filtering them out. Annoying about the frameworks - I think it is possible to statically link, but that legally Qt was lots of money to let you do that.