Here’s an evolving overview of tools and IDEs for NodeMCU. At the moment it’s my personal scratch pad for this post.

If you see your tool listed here with inaccurate information please get in touch with me so I have a chance to fix this.

Types of tools

The categorization is a logical separation based on the feature set and the intended use of the tool. As you can see in the table above some tools offer features for several categories.

Flasher

A “flasher” or “flashing tool” is responsible for transferring the NodeMCU firmware binary from a host system to the ESP8266 (or similar) device. In its most common form that means transferring data from a computer with USB connection over a USB cable and a USB-to-serial converter to the device. While “higher-order” modules like NodeMCU devkits, WeMos D1 mini, etc. usually have a USB-to-serial chip integrated and thus offer a USB connector the more basic modules like ESP-07, ESP-12, etc. need to be connected to an external converter.

Uploader

The terms upload and download sometimes confuse inexperienced makers. The process of transferring/copying (Lua) code to a NodeMCU device is called uploading. Thus, a tool that supports that process is an “uploader”.

For a long time ESPlorer despite all its shortcomings has been the tool of choice in this category for many.

IDEs

An IDE, by definition, must offer more than a limited set of features. It covers more than just a single use case. The heart of every IDE is a code editor, though. Below I further separate the available IDEs based on their deployment model.

Desktop

This is (still) the default model if one talks about IDEs. You download it and run it on your computer. It allows editing Lua code and uploading that to a device. It may also offer flashing (and sometimes even building) new firmware to a device.

Web

By “web” I mean code editing directly on the device through a web browser. This is achieved by first uploading the IDE code, one or several Lua files, to the device. Usually they then start some form of HTTP server which serves the HTML IDE GUI. Code changes are posted back to the device and stored on its file system.

–> see “Security concerns” below

Cloud

tbd

–> see “Security concerns” below

Security concerns

Web and cloud IDEs must be carefully analyzed for security issues. Web IDEs running an HTTP server omit the first and most important line of defense: they operate as servers instead of clients. This should really be avoided if you release IoT nodes into the wild.

Cloud IDEs often get that right in that they operate on a publish / subscribe model. The code you write is pushed to a message queue on an external broker. The device is subscribed to the same message queue. It operates as a client and consumes & processes code updates asynchronously.

However, since you usually don’t have control over the messages exchanged between the message broker and your device this raises a whole set of new concerns. Furthermore, it makes quite a difference whether a public broker, one you might even have access to, or a closed / private / proprietary broker is used.