Nextion an LCD the makers can benefit from...

...yep, for the display and control of my DIY (Marine) GPS and for some games and touch-painting... I had a small UI system going, very easy to use, very compact. But it did not include 'real' graphices, just buttons, text, checkboxes. Of course, the game stuff had some 'graphics'. If you search for LCD controller ILI9341 LCD CONTROLLER and Touch Screen you may find the posts.

The biggest challenge was the speed and memory... for example, I built an alogrithm for calibrating the touch screen - btw a quite spungy resistive one. The modern, snappier ones are all capacitive now... (combined with other technologies - like Samsung phone screens with stylus - wher the stylus is recognized already from qute far and eventual touch 'point' is indicated with a white little circle...

In a UI of that small size, you need to be able to quickly backup display area for a so-called overlay.... which is not really an overlay because there esists no such thing like layers... This means 2..3 bytes per pixel and FAST to backup, paint the overlay (pain over!), restore from backup (paint-over again). Since pin numbers are limited and a lot - almost all - happens within Espruino, acutual graphical data is transmitted.... and that give the memory issue and the speed challenges (I you do not want to spend GPIO pins to go at least 8-bit, better 16 bit parallel...). For font, built in fonts work faster, but the controller supports not much for that...

A 'display' module like that - with built in render support for all kinds of text/gauges/graphics dsiplay, additional memory, max-parallel access - is quite a nice thing. Nothing has changed: good displays require still 'large, but still very very fast moving parts... like the 'old RAMDAC' (that had to 'feed' the guns for the 'unstoppable' electro-magnetic ray deflection coils 'in' a Cathode-Ray-Tube/CRT display...

The graphics stuff showed some of the limitaitons of the hardware / connectivity setup and in which hardware component functions were (software-aly) implement.

Took a closer look at
https://www.indiegogo.com/projects/nextion-a-cost-effective-high-performance-tft-hmi. It will be fast for sure, design of applications become a bit more tricky - even more than X11 display server and other ultra-light-client-technologies (from the past): nextion display server has to be prebuilt (complemented/loaded with custom UI definitions/components), and application will have to send the commands over serial to make it happen, as well as receive the input over serial. Things that are not preloaded will just take for ever to happen... so displaying some imagery or alike from the internet will be sluggish - even more sluggish that with an SPI, because max speed for plain asynch serial is much lower (and more error prone) than SPI's. With the limitations clearly understood, it can become a wonderful cheap component. For industrial apps though, I'd rather take 'large' up-to-date phone or micro/mini tablet - fablet as client device which has html5 and alike support, where the whole client app can reside and 'behaves' - and only raw / concise data is exchanged with the sensor and motion controller device(s). See also the Shiny UI conversation. The flood very affordable 5..7 tablets provide options on many levels far beyond a tethered, basic TFT display with touch, that makes it easy to justify the cost not so big cost difference anymore.

Since communication has anyway to be availble practically anytime, I feel the approach of thingStud.io / @mkarliner more promising: taking advantage of the existing, very powerful communication and display infrastructure and focus on predefined, custom extendable widgets, data/package formats, and a 'easy to use' IDE to get the things composed on a purposed platform with stub and and test support / regression test support.