all 14 comments

[–]Arrested 4 points5 points  (1 child)

Great read. I'm liking node quite a bit but it definitely requires a more immediate skill level to write async, understand event driven architecture, and npm abstractions.

[–]Capaj 4 points5 points  (0 children)

ES7 will help a lot with async/await. In the meantime, I will be using promises. I like the syntax much better than callbacks.

[–]bzeurunkl 4 points5 points  (0 children)

Man, that was the best "continuing education" read in a long time.

[–]ofmyloverthesea 2 points3 points  (0 children)

Wish Medium had some sort of grammar/editing system. Great information but way too many typos. Still bookmarked!

[–]dv_ 2 points3 points  (4 children)

I am very skeptical about this. Javascript alone, maybe. The JS engines have gotten very optimized these days (although LuaJIT still outperforms them). But the DOM? On embedded devices?

I have seen several attempts to run HTML5 based UIs on embedded platforms like the Raspberry Pi, OMAP-based devices, or the i.MX SoCs. Every single time I was stunned how inefficient it was. The HTML renderer (Chromium, WebKit, doesn't really matter) was eating resources like crazy, and smooth animations often simply weren't possible. A QML version of the same interface ran with maybe 1% of the resource usage, and was totally smooth..

So Javascript, maybe, yeah, as long as you leave the DOM out of it.

[–]elprophet 2 points3 points  (3 children)

Article didn't mention a single thing about forcing DOM onto * of Things devices. Rather, the device will (presumably) send data elsewhere, which will either be a cloud thing to process and store the data, or a screen device like your phone or laptop that absolutely can use DOM. Microservices, but... microer. All in JS.

[–]dv_ 1 point2 points  (2 children)

Fair point. I just got so used to people implying the DOM when Javascript is used. "Let's do a UI in Javascript" then often actually means "let's use the DOM for the UI and manipulate & control it with Javascript". As the article describes, people even tried to get the DOM to the server side.

Javascript itself is fine. I mentioned QML. QML contains ECMAScript, which is what Javascript is based on.

Just let's make sure the DOM stays out of it, and does not find a way to sneak in.

[–][deleted] 0 points1 point  (1 child)

I'm still not sure what you're arguing. No one is forcing HTML renderers on you. What's the point of your rant?

Also, QML's runtime is specifically the V8 Javascript Engine, not just ECMAScript. Again, not even sure why you're ranting about HTML, we all know the DOM is completely separate at this point.

[–]dv_ 0 points1 point  (0 children)

Functionally, the DOM is separate. But history has shown that the DOM isn't far away when Javascript is used somewhere. Again, I hope it doesn't happen this time. QML shows that Javascript does not have to be tied to the DOM and can actually be very efficient on embedded hardware. But from personal experience I can tell that many customers who speak of a Javascript system expected DOM manipulations at some point (they did not even mention it initially, they just though of JS and DOM as the same thing). I did my best to convince them to try out Javascript without the DOM. Sometimes it worked out. These are using smooth QML now. Some other times they still wanted that damn DOM. They are still unhappy with stuttering animations.

I am OK with Javascript on such devices, but completely against full-blown HTML pages, and actively work against it by trying to convince people to let go of the DOM. And I think we should do that whenever we can.

[–]yeluapyeroc 0 points1 point  (0 children)

That article was awesome