Open pfalcon opened 6 years ago
So, porting an existing project would be more realistic, even as an intermediate step. Yes, we'll end up with something bloated and which still will require digging into JS bloat to e.g. short-circuit something, but at least result "will work" (as good as the original).
PyDashie was ported as a proof of concept: #2.
What about a semi-compatible library to jQuery like Umbrella.js? ([https://umbrellajs.com/]) I've been looking for a small JS script that is easy to deliver with an ESP8266 PicoWeb app. It is what I could find. Haven't run it through it's paces though.
@joewez: There's a gazillion of such libraries, e.g. http://microjs.com . The problem arises when you try to do non-trivial things, e.g. grid layouts, advanced widgets, charts, etc. All that stuff is available as jQuery plugins and known to work and integrate well enough with each other. Some of that stuff also exists in VanillaJS form, but often it's missing features (or goes big too), has various issues, lacks support, etc.
This is not my first attempt to hack up a dashboard, can dig previous attempt(s) too.
So, I had a look at what I was working on ~3 years ago. There, I exactly followed approach "try to make widgets independent from backend". Thus, all widget js/html/css loading was handled by JS itself, and by extension, I also bothered to implement pull-style processing in widgets, ajax-loading pages, filtering, parsing them, and them performing HTML templating.
That worked in expected way - poor Android browser this ran in regularly stopped to updated some widgets, then locked up/crashed. Starting the webapp now, some widgets come out completely empty, because there was some error during JS parsing/templating them, which are of course boring to debug, etc.
So, NOWAI. There should be push-style approach, as much processing as possible should happen on Python side. Q: It's cute PoV when widget shows just a single scalar value, but reality, there're lists, tables, etc. ... A: Yeah, render HTML on Python side and push like that.
Would it be acceptable to assume that the browser accessing the dashboard has Internet access? In that case, you can have the client fetch the heavy JS libs from a CDN, not from the micropython device.
Would it be acceptable to assume that the browser accessing the dashboard has Internet access?
No: http://www.vmwareinfo.com/2017/09/smart-home-lessons-from-hurricane-irma.html
In that case, you can have the client fetch the heavy JS libs from a CDN, not from the micropython device.
Sure, that can be a particular case (and everyone would start like that), but a "universal" solution should provide a fully "self-hosted" option, and thus think about the size of JS stuff (and about serving it gzipped, etc.).
That makes sense.
On Nov 27, 2017 4:38 PM, "Paul Sokolovsky" notifications@github.com wrote:
Would it be acceptable to assume that the browser accessing the dashboard has Internet access?
No: http://www.vmwareinfo.com/2017/09/smart-home-lessons- from-hurricane-irma.html
In that case, you can have the client fetch the heavy JS libs from a CDN, not from the micropython device.
Sure, that can be a particular case (and everyone would start like that), but a "universal" solution should provide a fully "self-hosted" option, and thus think about the size of JS stuff (and about serving it gzipped, etc.).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pfalcon/udashboard/issues/1#issuecomment-347336873, or mute the thread https://github.com/notifications/unsubscribe-auth/AFUXxrz40ESFJ78RWqWvGHkveDCM1nDSks5s6yvxgaJpZM4QqWP4 .
General development approach:
Expected result approach:
Widget approach:
Data delivery approach:
Regarding this, we apparently want to do as little as possible in JS, and as much as possible in Python. (Up to a point, a browser devices may have more resources than MicroPython device).
Tabbed interface: