Info about this controller began as a web page which is now at http://www.anotherguywithabeard.com/node/108 in the Developer's section.
For updates and/or comments on that item, please follow that link to it's page.
Info about this controller began as a web page which is now at http://www.anotherguywithabeard.com/node/108 in the Developer's section.
For updates and/or comments on that item, please follow that link to it's page.
Sorry if this isn't the…
Sorry if this isn't the right place, hoping this thread is for general development using the ESP8266.
I've been learning Javascript the last few days and have got these functions written. While we can do most of this stuff in C/C++, some things are easier to accomplish in Javascript like string parsing. My thought is to do as much as I can with Javascript and then send a completed command to the ESP to send out.
I think you're right. The…
I think you're right. The web pages are best for presentations and the forum is better for discussions. Either works. Use either you'd like. The most valuable aspect is the sharing of info - however you folks want to do that.
I do see the wisdom in handling a good portion of the command processing on the client side and then handing that off to the ESP to do the deed. Another advantage of Javascript is that it has JSON handling built in. The Arduino IDE libraries for handling JSON input are clumsy and not nearly as attractive for use. That situation favors handling complex data structures on the client side and trafficking more simplistic data to the server side.
The main things to keep on eye on when shifting processing to the client-side are:
The script that I used as the starting point for this adaptation used jQuery and it took way too long to download all that bloat-ware. One of the first things I did was figure out how to avoid using jQuery in the controller setup. Part of the reason jQuery is bloated is because of #2. It includes stuff to figure out what browser is being used and how to talk to that browser using code it is likely to be happy with. Impressive, but adds a lot of code that has to be downloaded.
Ordinarily, I'd expect page performance to improve once the jQuery files have been downloaded and cached. But I didn't see that during the early stages of adapting the code. Not sure why, but things remained maddeningly slow as long as jQuery was in the picture.
To avoid caching delayed update headaches, I put most of the Javascript directly into the web page for the stuff I gave you and Jorge. Users always have so much fun trying to wrap around the whole Javascript/style sheet caching concepts and how to force updates to those goodies. But the code may need to be pushed out to a separate .js file if it grows to the point where it's too much to handle in the HTML page. Guess we cross that bridge when we come to it, eh?
Another function that could be migrated to the client side by using Javascript might be the one that calculates the 0x9? value to complete code snipets that lack the leading 0x9? value. I became addicted to leaving that chore for the server to handle. But it probably would work better to handle that in Javascript on the client-side. What do you think?
I agree on the web pages…
I agree on the web pages being good for presentations of our individual projects. We can continue to tack on updates, notes, and changes as we need them. Kind of like writing an article, I guess? We present things differently when it's a forum post vs. an article.
JSON is one of those things that while I like the format of it, the libraries of non-Javascript languages are spotty at best. I was having issues with one library outputting a JSON array because it was possible to include malicious code. While we can move bits and pieces client side, there's some stuff that should be kept server side. Things like playing a show should be kept server side for correct timing. However, once string parsing and some other settings are set up there's no reason we can't transfer control back to the server. When I was first looking at things I wanted to keep as much server side as I could, we have a whole 1024 KB for server side code. While on the client side, things are programmed in text which takes up a lot more space. However, we have space. As much as I want to optimize things to be tiny I have to remember, we have space. Even Don's index.htm where he keeps all of the HTML, CSS, and JS is only 7.7KB, that's 0.25% of the SPIFFS flash.
I didn't even know there was issues with JS on different browsers, I thought that was mostly CSS that had issues. The more you know. Actually now that I think about it there's different JS engines so that makes total sense. The reason I even thought about using JS for some of this was with string parsing. It's really clumsy doing it yourself, even my own C code to work through it is specific and does some lazy things.
The only library I was looking at using was Snap.svg and that's 27KB pre-gzip. Does the ESP Webserver even support gzip? As I'm poking around at jQuery info, there's also dependencies that I remember being mentioned. For me, I want things to be as self-contained as possible. Webdev is a whole new world 🎶 for me and I'm sure most of us; so much to explore and learn.
I've been developing using JS in a separate file but I can see the issue with the client caching it and not getting the updates, crossing that bridge when we get to it.
On the 9X length value, I have code for it above, just rolled into the testCRC function. I was getting lazy about abstracting it out at that point. It's just a matter of counting the number of parsed two letter hex digits and adding it to the front of the array.
Anyways, got home a few hours ago and a nap seemed more important than coding at the time. Maybe I'll find some dinner and get some coding done. I need to figure out this CSS thing and probably actually learn HTML properly.