Espruino target audience?

What ultimately is the grand vision for the Espruino project? Is it ultimately the hope that Espruino will be adopted by professionals and used in a lot of consumer products? Or is it intended to be more of an intro-to-embedded devices product?

First of all, I hope it's the former. And it's incredibly impressive what @Gordon has been able to build here. I get the impression that he's single-handedly building the entire embedded JS platform, which is f****g amazing. Something I could never do, I'm just a simple JS developer and inventor.

But certain aspects of the project lead me to wonder if the latter might be a bit true, or if there's a little less focus on one over the other, than there probably should be. For example, the graphical editor seems to me like more of a nice-to-have than a mission-critical sort of feature. And to a lesser extent, the web IDE also. It's really great that I can paste some code into a box, hit run, and see it just works. That's awesome. But once I've decided to start building my product, with Espruino at the heart of it, I'm not going to be working in the web IDE. I use Sublime Text, and the web IDE doesn't have any of the productivity features I use. Performing a copy-paste every time I want to run my code is nuts. I'm confused why there didn't already exist a CLI tool to solve this. True, there is a CLI Espruino tool, but none of the needed features were included.

My point is this: I would have expected the most important features of the web IDE to be available from CLI before a graphical editor was made, if the focus is on professionals. I think that having a focus on professionals will be important to the success of Espruino in general.

There's a couple other items I'd like to draw attention to.

I've been playing with MQTT and my impression is that this interface isn't as much of a priority as other issues. For an IoT platform product, this seems like an important thing to not only support but have in a very robust state. I would think that MQTT + encryption would be very important for professional applications.

I do realize of course that there's zillions of applications for Espruino's, and people building robots will probably care a lot about motor controller stuff before they care about MQTT. And this actually goes to my point, which is that Gordon is taking on sooooo much, I think it's really important to not build certain things, like a graphical editor. The cost of having a graphical editor is not just building it, but then supporting it over time. Case in point, in this thread:

http://forum.espruino.com/conversations/­298305/#comment13410511

It's because the Web IDE was originally made as a website where each file executed in the same scope, and adds itself to the global 'Espruino' variable - I can't just 'require()' everything as-is. Ideally I'd rewrite every file to handle both loading styles, but I don't have the time to do that while also checking it still works fine as a Chrome App, NWjs app, and on the Espruino website.

Gordon, I'm concerned that you've stretched yourself too thin. I would like to offer the friendly suggestion that you even go so far as to drop support for some things, just so you can focus on the truly important areas. Aside from features like this/that whatever for MQTT/BLE whatever, I think unit tests should be in place and with complete code coverage. I use Istanbul and recommend it. I haven't looked at the core Espruino code and don't know if it has tests, but it looks like the Espruino IDE and CLI doesn't have tests.

The thing I'm building is a medical product, and so scrutiny is going to be especially high. JS already has a bad rap (which isn't deserved), but should detractors take a very close look at Espruino under the hood, I worry that the criticisms will be a long list. I suspect people will make blanket criticisms that the system is not robust enough for professional use.

The value of having JS at the heart of the product is the added agility, so it makes great sense to use Espruino as much as possible. Also, the ability to build the product and services all in one language is again a major asset. So my strong preference is to continue using Espruino even in my end product. But overall robustness is a real concern for me.

The web IDE has been buggy lately, and I don't know what's going on. Occasionally the output pane becomes unresponsive, and I have to restart the editor. Then this other issue, I just saw this mystery error tonight:

Connected
Uncaught Error: String too big to convert to float
 at line 1 col 6341
....stringify(process.env),">>",">")
                              ^

^ not in my code. No idea where this is coming from.