Opening up the web to embedded (CSS post thoughts ctd)
-
Nordic just released a WiFi6 capable embedded radio. The Espressif ESP line of chips have WiFi, albeit older. The trajectory seems to be connected IoT devices doing more and more. HTML5 is relatively simple. It can be processed top down for the most part. They did a good job cleaning up HTML4 and making the spec more coherent. It's already what I'd consider mostly appropriate for embedded. CSS, not so much, and it's where I'd like to see some kind of formalized standard for a CSS subset compatible with forward only processing. What's the value in this? Frankly, being able to run web interfaces on sub ARM Cortex A chips opens the web up to far more affordable hardware. An ESP32 devkit with an integrated screen costs $18 on amazon. An RPi with no screen is in the ballpark of $100. They're different kits entirely, but I'm talking about the little guys. Currently to make a connectible device talk to the web it requires a dedicated UI for that web app, and usually a REST or MQTT based communication on the back end. What if you could provide your simple UI from online sources that update all devices immediately when the back end changes? just for example. CSS is the big blocker, in my experience, because of the DOM requirement. Simply choosing the right subset of selector syntax for embedded would be wonderful, but they can probably remove some of the heavier features such as font and image embedding as well. I think what will *probably* happen instead is the price on webkit capable devices will bottom out, and then everything will have 128MB of DDR3 or better instead of 512KB of SRAM. That will solve the problem too, but is much more power hungry. I think it's nice when a capabilities problem can be largely solved by pruning and spinning off an existing standard. I think it's possible with web stuff.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Nordic just released a WiFi6 capable embedded radio. The Espressif ESP line of chips have WiFi, albeit older. The trajectory seems to be connected IoT devices doing more and more. HTML5 is relatively simple. It can be processed top down for the most part. They did a good job cleaning up HTML4 and making the spec more coherent. It's already what I'd consider mostly appropriate for embedded. CSS, not so much, and it's where I'd like to see some kind of formalized standard for a CSS subset compatible with forward only processing. What's the value in this? Frankly, being able to run web interfaces on sub ARM Cortex A chips opens the web up to far more affordable hardware. An ESP32 devkit with an integrated screen costs $18 on amazon. An RPi with no screen is in the ballpark of $100. They're different kits entirely, but I'm talking about the little guys. Currently to make a connectible device talk to the web it requires a dedicated UI for that web app, and usually a REST or MQTT based communication on the back end. What if you could provide your simple UI from online sources that update all devices immediately when the back end changes? just for example. CSS is the big blocker, in my experience, because of the DOM requirement. Simply choosing the right subset of selector syntax for embedded would be wonderful, but they can probably remove some of the heavier features such as font and image embedding as well. I think what will *probably* happen instead is the price on webkit capable devices will bottom out, and then everything will have 128MB of DDR3 or better instead of 512KB of SRAM. That will solve the problem too, but is much more power hungry. I think it's nice when a capabilities problem can be largely solved by pruning and spinning off an existing standard. I think it's possible with web stuff.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
An interesting thought. Are you suggesting also dropping the Javascript virtual machine from the client environment also? A real back to basics web page with no CSS and no interactivity via Javascript?
-
An interesting thought. Are you suggesting also dropping the Javascript virtual machine from the client environment also? A real back to basics web page with no CSS and no interactivity via Javascript?
I think so, short of IoT MCUs being able to interpret JS** which isn't very realistic. Still having it presented declaratively and on the web as HTML5/CSS as stripped down as it may be for embedded: A) Should reduce cost of development, as you can hire people to do basic HTML and CSS (EDIT: see notes) instead of knowing C or C++ B) Can potentially be a server templatized/dynamized page and spun off of a full fledged website when an embedded device hits it. This is already often done for smartphones C) Would provide pain free UI updates that instantly roll out across all devices. There are probably other benefits that aren't occurring to me right now, but those are some major ones I see. ** it has been done, but i think it's precompiled and uploaded, or at least semi-compiled. CSS notes: CSS can be forward only processed if you limit the CSS selector syntax to specifying ids and classes, or maybe only slightly more complicated than that. In theory you could do like .foo/bar/baz potentially and it could still be forward only, but would be more complicated. I'd be inclined to ditch that feature, but if it was in there it wouldn't be a performance killer. Parent references would be, as well as forward searches in many if not all cases (i haven't baked it all out in my head at this point)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I think so, short of IoT MCUs being able to interpret JS** which isn't very realistic. Still having it presented declaratively and on the web as HTML5/CSS as stripped down as it may be for embedded: A) Should reduce cost of development, as you can hire people to do basic HTML and CSS (EDIT: see notes) instead of knowing C or C++ B) Can potentially be a server templatized/dynamized page and spun off of a full fledged website when an embedded device hits it. This is already often done for smartphones C) Would provide pain free UI updates that instantly roll out across all devices. There are probably other benefits that aren't occurring to me right now, but those are some major ones I see. ** it has been done, but i think it's precompiled and uploaded, or at least semi-compiled. CSS notes: CSS can be forward only processed if you limit the CSS selector syntax to specifying ids and classes, or maybe only slightly more complicated than that. In theory you could do like .foo/bar/baz potentially and it could still be forward only, but would be more complicated. I'd be inclined to ditch that feature, but if it was in there it wouldn't be a performance killer. Parent references would be, as well as forward searches in many if not all cases (i haven't baked it all out in my head at this point)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You would have to eliminate all HTML events (like onclick, onblur, onfocus, etc.) Right?
-
You would have to eliminate all HTML events (like onclick, onblur, onfocus, etc.) Right?
I would eliminate JS, and "active CSS" elements that deal with the dom yeah, so no dom events. The whole idea is to make it renderable without keeping the entire document in memory. Basically forward only, render as you go, and then toss once you've rendered.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I would eliminate JS, and "active CSS" elements that deal with the dom yeah, so no dom events. The whole idea is to make it renderable without keeping the entire document in memory. Basically forward only, render as you go, and then toss once you've rendered.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
OK, got it. Reminds me of the old IBM Block mode terminals that had a physical map (with all literal fields and color specs, input specs and protection specs) and a data map that was only the fields that returned values. Both were sent to the terminal which would use a forward only processing to paint the screen and enable the unprotected fields. Any action key on the terminal transmitted only the data map to the invoking program. It was up to the program to split the data map back into fields and do any validation and processing of the data. (very efficient use of transmission bandwidth in the old days.) :)