Yep Lua is strange. It has the awesome nil value which is great for a loosely typed language, but it will bite you on the posterior if you're used to the usual methods since boolean "false" and nil are the only values that fail an "if..then" test; 0, 1, and any non-nil value of any other type, such as an existing function or table, will satisfy the test like "true."
There is also "typeof" which returns a string describing the type of a variable, so you end up doing stuff like
if typeof(maybeitsafunction) == "function" then maybeitsafunction() end
This prevents the inevitable Lua panic reset if maybe it isn't a function and you try to call it anyway.
Is there anything stupider than not knowing whether the result of 3+3 will be "33" or 6?
This goes back to the original Netscape 2.x implementation of JavaScript and discussions on the newsgroups with Brendan Eich. The trivial example of 3+3 will always result in 6, but MyVar + YourVar is anyone's guess. So is MyVar + 3 or its inverse. There were many back and forth discussions over whether JavaScript should auto-promote the string, and if so, what rules to follow. In any case, nowadays "3" + 3 and 3 + "3" will result in 33. JavaScript favors promotion of the number to a string, rather than the other way around. I'm guessing this rule was adopted because it captures more use cases.
You can always cast a string to a number, though with the usual caveat you'd have with a typed language that you need to make sure it's a valid numeric string.
The story, as far as Douglas Crockford tells it, is that when Netscape took JS to ECMA for standardization they wanted to fix some of the weird type coercions and so on. But by that time Microsoft had already cloned JS very accurately, "bugs" and all. MS refused to agree to any such changes for the standard. So we have had to live with them ever since. Once again we have so much to thank MS for
Lua is great and all but I would say that JS was aslo designed from the ground up as an embedded scripting language; it's intended to sit on a C platform and call C functions for all the stuff the interpreted JS isn't suitable for. That is exactly it's role in the browser and as originally intended by Netscape in the server. That is certainly how it works in node.js, in Qt, in some games and other places.
The Lua interpreter is tiny...
I presume you mean the byte code interpreter. Not the whole REPL, compiler, run-time.
This seems to be a major difference between Lua and JS. A JS run-time always starts from your source not a precompiled bytecode.
This means that if you have something like the Espruino or Jerryscript JS engines on your micro-controller the whole system is self-contained, no need for an external compiler on a PC or whatever.
Those JS run times are tiny too, they fit in STM32 and Nordic Semiconductor MCU's for example.
I guess the Lua list engine is the heart around which it revolves like the JS "object".
Being able to select an integer only build for speed when you need it is probably a God send in some cases. It's not something you would want to do in JS. Changing from float to int only would break so many programs. Essentially you have a different language when you do that.
Ironically the little JS engines like Espruino and JerryScript don't use the FPU's on chips that have them, like the STM32F4. A 32 bit float is not the same as a 64 bit one. I think Gordon Williams tried to do that with Espruino, again the problem is it breaks too much code. For example you can not have 53 bit integers represented exactly in 32 bit float.
V8 and other engines will use integer operations when they can, only switching to float when need be. I'm not sure if Espruino or JerryScript do that.
There are two deal breakers for me:
* As far as I can tell, Lua is not an event driven system. If you want to juggle many jobs at the same time you end up getting into threads and coroutines. Correct me if I'm wrong I have not look too hard into Lua yet. JS on the other hand is all asynchronous and event driven.
* There is no need for an external compiler.
JS is indeed a bit of a mess in some cases. People love to rag on the 3 + "3" and such type coercions. In practice these things cause little trouble. No more so than a silent roll over of integer maths in C for example. You test your code, you find it soon enough.
* As far as I can tell, Lua is not an event driven system. If you want to juggle many jobs at the same time you end up getting into threads and coroutines. Correct me if I'm wrong I have not look too hard into Lua yet. JS on the other hand is all asynchronous and event driven.
* There is no need for an external compiler.
I'm not sure either of these is really true. NodeMCU seems to be an event-driven system and it uses Lua. And, as far as I know, the external Lua compiler is not *required*. It's just available if you want to use it. Lua still supports a normal REPL where you type in code and it gets compiled on the fly.
Two years ago I got drug kicking and screaming into a Node.js project. Unfortunately I did too good a job and ended up getting assigned to the Node.js specialist team. After about six months working on it I went to management and asked to be reassigned. So I changed roles for about a year, but as luck would have it I am back on a Node.js project.
If there's one thing that will drive me out of the software industry it will be JavaScript. I can't say how much I hate it in a family forum.
I'm guessing the mods sunk it which is too bad because now we'll have two JavaScript religious war threads. Much like JavaScript frameworks it replicates uncontrollably.
I'm guessing the mods sunk it which is too bad because now we'll have two JavaScript religious war threads. Much like JavaScript frameworks it replicates uncontrollably.
I wonder how much the constant sinking of threads is contributing to the lack of activity on the forums these days?
I guess I have to get me some ESP whatever devices and check out this NodeMCU thing. Find out what is really going on in there. Sounds fun. Shame they called it NodeMCU when all the world now knows Node as a Javascript engine now a days.
@Martin,
From our previous conversations I gathered that you being dragged into the JS/node world has resulted in you and your team becoming very productive and successful within the company. You are now in an "elite team" of which you are one of the elite. This all sounds very good, for the company, for you, your lively hood and you family.
I'm not sure why you are still having such a bad allergic reaction
Perhaps now with your two years of intensive node experience you could tell us what the main problems with it have been on your project?
I'm kind of interested in seeing if your major JS gripes are the same now as when you first started out.
Or maybe the same gripes are there plus a bunch of new ones
And, as far as I know, the external Lua compiler is not *required*. It's just available if you want to use it. Lua still supports a normal REPL where you type in code and it gets compiled on the fly.
Confirmed. ;-)
NodeMCU does not need help from external machines to get stuff compiled to Lua VM opcodes. An external Lua compiler can be used to crosscompile Lua scripts on the PC.
(yeti@kumari:1)~$ nc nodemcu-0.9-1 23
Welcome to NodeMcu world.
> function fact(n)
>> return n > 0 and n * fact(n-1) or 1
>> end
> =fact(9)
362880
...there is no "ll.lc", only "ll.lua" so "require" used "ll.lua".
> require"cat"("ll.lua")
local module=...
return function()
package.loaded[module]=nil
module=nil
local k,v
for k,v in pairs(file.list()) do
print(string.format("%7d %s",v,k))
end
end
> _
...and "ll.lua" really is readable source code.
"require" would have used "ll.lc" (Lua VM code) if present.
Heater, we weren't any more productive, we were just the first to get something useful out the door. Honestly it was a slog because the technology is so unreliable, so I succeed while hating it. On my list of hates:
The ~ and ^ in the package json are a trap. Someone will ship a new version of a package right before the final build and break everything. I was fighting a year long battle to stomp out their usage.
NodeJS packages don't behave the same on Windows as Linux, while Java performs much more reliably cross platform. Now the fanboys would say just use Ubuntu laptops and Windows users get what they deserve. Well most corporation use Windows desktops and it's not like the developers have a choice. We certainly didn't.
SSL is critical to what we do, but NodeJS doesn't perform that well using SSL. So we had to slap an Nginx proxy in front on the same box and use the loopback address between them. It's a kludge like the rest of the stack.
As I said in the Official JavaScript religious war thread. The JavaScript frameworks and tools churn constantly, and frankly for no good reason. Grunt versus Gulp why?
Certainly there has been a lot of "churn" in the node world. Hardly surprising considering it's all relatively new stuff under development. You might call that "unreliable", I think it's good. One just has to manage it a little bit. For example it's nuts to pull packages of the net with NPM for a production system. For a production system you want to go live with all the same versions of everything you have been using for development and testing. You need traceability, same as you do for any serious software. Surely you would not be upgrading libraries the night before going live in any other language? That is simply taken care of by using your own npm repository that is only updated when you say so. Or use shrinkwrap https://docs.npmjs.com/cli/shrinkwrap
Do you have an example of node packages that don't work the same on Windows and Linux?
Interesting about SSL performance. I have not had a problem with this but then nothing I make gets heavy use. I was just about to evaluate this issue for a data streaming system.
Personally I don't think using nginx or whatever in front of node apps is a "kludge". It's quite likely that your node app is in fact a lot of node little services running on different ports, or different machines, perhaps behind a load balancer or whatever. Rather than one big monolithic server process. This is all good practice.
Heater, we have our own NPM repository of blessed packages, but it's maintained by a central ministry of Node.JS packages. So new versions can appear on it out of synch with the development cycle of any specific group. We do the same thing with Java but Maven doesn't requires exact version match, so there's no ~ and ^ trap.
Now you might say why not use your own repository that you control? Such a repository would require security audits because it would be a target for malicious code injection, so it is not allowed. The same is true for build and deployment machines which are all under lock and key.
It's been a year since Linux versus Windows package hell, so I can't recall the specific package. But I imagine now that I am using Node I will bump into it again.
You're right that you might want a central web server dispatching based upon context root to multiple apps. But that central web server need not be on the same box because Java apps servers can do SSL efficiently. The Nginx layer is a kludge because we require yet another web server on the same box.
I think the lack of heavy usage might be a reason why you think better of Node than I do. The apps I work on get upwards of 700 transactions per second. That means even slight differences in performance characteristics become big problems. We manage this by horizontally scaling our services so we have multiple boxes performing the same role. Duplication of something like a web server has big implications in resources because we might have 50 copies of it.
I wonder how much the constant sinking of threads is contributing to the lack of activity on the forums these days?
It comes off as incredibly passive aggressive because you don't know you are replying to a sunk thread until after you post. Having a visible indicator of sunkeness would save this annoyance.
Seems to me that some years ago people started to create large amounts of code for their, lets call them "Web Apps" rather than just the little bits of JS form validation and useless element animation. This is the rise of AJAX. Think gmail and such. At that point the pain of using the web browsers DOM API becomes too much. The DOM is horrible. Not to mention the pain of getting things straight with CSS and working the same in all browsers. So, the first thing you do is create a library to abstract all that Smile away. Enter Yahoo's YUI, GMX's qooxdoo, and so on. The biggy there was jQuery.
It's analogous to the GUI world in Linux/Windws/Mac applications. Nobody wants to use the X11 API. People want to create cross platform code. So we have Qt, GTK, Java, .Net etc etc to gloss over all that.
Personally...When I first returned to web development, having sworn never to go near PHP, HTML, CSS, MySql soup again last century, I was happy. Happy because I could get my little node server thing running, get a stream to my browsers with websockets, create a live data visualization in webgl, and never have to go near that PHP, HTML, CSS soup. I let the other guys in the company do that. Also I demonstrated that all of that can be done quicker than the FLASH guru they had hired to do it, he missed the siz week deadline
Of course since then things went wrong. Soon I was expected to create web things all on my own. Gak. Then I rediscovered the horrors of the DOM API. And discovered the horrors of "Framework Soup".
Initially I decided to ignore the frameworks and stick with the DOM even if it is horrible. Life is too short to evaluate all the other stuff. Bad idea, soon you find yourself creating shims over the DOM, your own framework, oh no...
Here is where I landed:
1) If my creations work with Chrome, Firefox and the Edge it's good to go. That means one can use a lot of ES6 features in browser side code. That means no need for coffescript, babel, etc. I can get away with this because nobody is demanding we support old browsers.
2) Styling gets delegated to bootstrap. If anyone demands customization of styling then they can pay for a CSS guru to do it.
3) React.js for DOM rendering. Why? Because it's small, it's not a framework, it does not take over you entire development. React just does one thing, render stuff to the DOM. That can be a whole page if you like or just a single widget in a div somewhere. One can embed anything else inside a react widget, like webgl or a D3 graph. React is efficient both in both the effort required to learn to use it and run time performance.
Then there's the build tools. NPM is the one true build tool, no it's Grunt, no it's Gulp.
Again, I'm with you.
To be fair NPM is not a build tool. It's a package manager, it just fetches library code for you. As such it does a brilliant job.
Why do we have build tools in Javascript for God's sake? Node.js does not need any, just write your code and it runs. Historically the browser code does not need building either. How easy can it be?
Seems the motivation for build tools is:
1) Performance. If you have a lot of JS it's more efficient to stuff it all into one big bundle than have the browser fetch a thousand little JS files. Plus you can minimize the file size by removing spaces and blanks. And perhaps gzip it.
2) Language features. If you want to use new ES6 Javascript language features in the browser you need to "transpile" that to ES5 Javascript that all browsers can understand.
3) A module system. node.js has a module system. There is a module system defined in ES6 which no browser supports yet. So if you want "modules" you start using a build system.
After toying with the webpack build system I have decided this is all nonsense, a build system is not required even for browser code. Why?...
1) Performance. With HTTP2 making a ton of requests for JS files is efficient. No bundling required.
2) Language features. Chrome, Firefox and the Edge support all the ES6 features I need. No transpiling required.
3) Modules. Bah, I just get my "main.js" to download all the sub JS files it needs. No script tags. No modules
All of the above makes the development turn around cycle much quicker.
Don't even get me started on all the nearly identical unit test and mocking frameworks.
Got me there Martin. We don't have any automated testing!
Heck, another long essay, sorry folks.
I should point out that neither of Martin's gripes about Javascript are anything to do with Javascript as a language. They are all about the browser, the DOM, the available libraries, the tools, and such. Much of which I agree with.
I think the lack of heavy usage might be a reason why you think better of Node than I do.
Good point. We are not working at that scale, yet. Not in terms of transactions, or code size, or number of developers. So perhaps I have some experience to come if/when things get bigger.
On the other hand, when I hear people from the BBC's web site, which you must admit is huge and gets a lot of use, describe how well things go with node.js I like to think scaling issues are not insurmountable.
I should point out that neither of Martin's gripes about Javascript are anything to do with Javascript as a language. They are all about the browser, the DOM, the available libraries, the tools, and such. Much of which I agree with.
Perhaps, but the pure language is not what hits the real world, it is all that other baggage that colours what people think of a pure language, and your lists above show JS has shiploads of other baggage.
All of which makes me think it is less suited to Embedded Control.
Long term Stability and simplicity still matter in the Embedded space, even on a P2
I should point out that neither of Martin's gripes about Javascript are anything to do with Javascript as a language. They are all about the browser, the DOM, the available libraries, the tools, and such. Much of which I agree with.
Perhaps, but the pure language is not what hits the real world, it is all that other baggage that colours what people think of a pure language, and your lists above show JS has shiploads of other baggage.
All of which makes me think it is less suited to Embedded Control.
Long term Stability and simplicity still matter in the Embedded space, even on a P2
I don't understand this argument. Certainly there are lots of C and C++ libraries and there are even a lot of Spin "objects" in OBEX but those languages are used successfully in embedded applications. There is no requirement to use these libraries. One can either program directly in the base language or create libraries, like Parallax has done with the Learn Simple Libraries, that fit the constraints of the platform.
The canonical language in the embedded world is C. That has tons of baggage as well. Every micro controller form every vendor has its own IDE and build system and libraries. C code is not easily movable form MCU to MCU.
Or you can go it alone and use GCC, if there is a target for your machine.
In terms of stability JS the language itself has been almost the same for decades. It is well standardized like C and C++.
With all the JS tools and libraries we are likely to use being open source once you have a system running it is stable forever.
Imagine if the Propeller were as successful as node.js. There would be tens of thousands of objects in OBEX, the might be a OBEX Package Manager, OPM, to help you sort that out and take care of versions. There would be the same "baggage" as we see in node.js world.
There are plenty of reasons for not wanting to use JS in tiny and/or embedded and/or real-time systems. Speed, size and so on. But I don't think it's popularity and hence "baggage" is one of them.
On the other hand, when I hear people from the BBC's web site, which you must admit is huge and gets a lot of use, describe how well things go with node.js I like to think scaling issues are not insurmountable.
If you go to the BBC and it fails to load just hit refresh. If you submit a transaction with financial consequences you do not want to hit refresh on failure.
Perhaps, but the pure language is not what hits the real world, it is all that other baggage that colours what people think of a pure language, and your lists above show JS has shiploads of other baggage.
All of which makes me think it is less suited to Embedded Control.
Long term Stability and simplicity still matter in the Embedded space, even on a P2
I take the point about transactions and consequences. It's not clear to me how the programming language impacts that. If you wanted a really "safe" language you would would be working in something like Ada. Or Lucol where program correctness is more easily verified. I guess that is not happening.
Bingo, yes, JS the language has been stable for decades. And well standardized.
By the way, how do you stop users hitting refresh when they think things have gone wrong or are taking too long? That's what web users do.
There are strategies for one time use tokens that can detect these sorts of scenarios, but when they happen they annoy users. So it's an issue of not making an annoying problem worse.
There are plenty of reasons for not wanting to use JS is tiny and/or embedded and/or real-time systems. Speed, size and so on. But I don't think it's popularity and hence "baggage" is one of them.
Certainly it fails on Speed and Size, and lack of suitable data types, and 'popularity' is not worth much, if it brings the wrong type of expectation. That's the bad type of baggage.
64b Reals for everyone !!! - Err, sorry, not on embedded MCUs - you WILL need to re-learn what you thought you knew...
There are better choices, for P2.
Pushing a 'bad fit' language could actually harm P2 sales, as someone will show just how terribly slow their JS is on P2, vs a M7 or some other new ARM+FPU offering.
You could almost be quoting the young Heater from the late 1970's:
Certainly BASIC fails on Speed and Size, and lack of suitable data types, and 'popularity' is not worth much, if it brings the wrong type of expectation. That's the bad type of baggage.
Now I do sympathize with your point of view. When we want to we roll our sleeves up and program in assembler or C for small size and efficiency. But that is not what this is about. Back in the day Bill put BASIC on micro-processors. Now a days we can put Lua or JS on devices far smaller and cheaper. It's about letting people program them without the friction of all that low level detail.
It only fails on speed if you need to be fast. It only fails on size if it does not actually fit.
By the way, as far as I can tell none of the little JS engines use the FPU even if there is one on the chip. 32 bits is no good. So I don't see why the P2 should not compete with JS on Espruino or whatever.
The bonus is that whist the JS is lumbering a long there is a bunch of other COGs that can be running highs peed peripherals or whatever code.
The bonus is that whist the JS is lumbering a long there is a bunch of other COGs that can be running highs peed peripherals or whatever code.
Yup, but now you have to switch to another language, for Speed/size.
Simpler therefore, to just use that one, faster language for the whole project.
Don't we already use two languages on the P1 and probably will also on the P2? We write high-level program logic in Spin or maybe C/C++ and then time-critical stuff in PASM. What's the difference if the high-level language is Javascript instead of Spin?
It's kind of missing the point the the casual/beginner programmer does not use two languages. He uses JS and whatever other objects gurus have crafted in PASM or C or whatever. Just like those old BASIC on microprocessor days.
Comments
There is also "typeof" which returns a string describing the type of a variable, so you end up doing stuff like
if typeof(maybeitsafunction) == "function" then maybeitsafunction() end
This prevents the inevitable Lua panic reset if maybe it isn't a function and you try to call it anyway.
This goes back to the original Netscape 2.x implementation of JavaScript and discussions on the newsgroups with Brendan Eich. The trivial example of 3+3 will always result in 6, but MyVar + YourVar is anyone's guess. So is MyVar + 3 or its inverse. There were many back and forth discussions over whether JavaScript should auto-promote the string, and if so, what rules to follow. In any case, nowadays "3" + 3 and 3 + "3" will result in 33. JavaScript favors promotion of the number to a string, rather than the other way around. I'm guessing this rule was adopted because it captures more use cases.
You can always cast a string to a number, though with the usual caveat you'd have with a typed language that you need to make sure it's a valid numeric string.
The story, as far as Douglas Crockford tells it, is that when Netscape took JS to ECMA for standardization they wanted to fix some of the weird type coercions and so on. But by that time Microsoft had already cloned JS very accurately, "bugs" and all. MS refused to agree to any such changes for the standard. So we have had to live with them ever since. Once again we have so much to thank MS for
Lua is great and all but I would say that JS was aslo designed from the ground up as an embedded scripting language; it's intended to sit on a C platform and call C functions for all the stuff the interpreted JS isn't suitable for. That is exactly it's role in the browser and as originally intended by Netscape in the server. That is certainly how it works in node.js, in Qt, in some games and other places. I presume you mean the byte code interpreter. Not the whole REPL, compiler, run-time.
This seems to be a major difference between Lua and JS. A JS run-time always starts from your source not a precompiled bytecode.
This means that if you have something like the Espruino or Jerryscript JS engines on your micro-controller the whole system is self-contained, no need for an external compiler on a PC or whatever.
Those JS run times are tiny too, they fit in STM32 and Nordic Semiconductor MCU's for example.
I guess the Lua list engine is the heart around which it revolves like the JS "object".
Being able to select an integer only build for speed when you need it is probably a God send in some cases. It's not something you would want to do in JS. Changing from float to int only would break so many programs. Essentially you have a different language when you do that.
Ironically the little JS engines like Espruino and JerryScript don't use the FPU's on chips that have them, like the STM32F4. A 32 bit float is not the same as a 64 bit one. I think Gordon Williams tried to do that with Espruino, again the problem is it breaks too much code. For example you can not have 53 bit integers represented exactly in 32 bit float.
V8 and other engines will use integer operations when they can, only switching to float when need be. I'm not sure if Espruino or JerryScript do that.
There are two deal breakers for me:
* As far as I can tell, Lua is not an event driven system. If you want to juggle many jobs at the same time you end up getting into threads and coroutines. Correct me if I'm wrong I have not look too hard into Lua yet. JS on the other hand is all asynchronous and event driven.
* There is no need for an external compiler.
JS is indeed a bit of a mess in some cases. People love to rag on the 3 + "3" and such type coercions. In practice these things cause little trouble. No more so than a silent roll over of integer maths in C for example. You test your code, you find it soon enough.
If there's one thing that will drive me out of the software industry it will be JavaScript. I can't say how much I hate it in a family forum.
http://forums.parallax.com/discussion/152201/the-official-javascript-religious
I'm guessing the mods sunk it which is too bad because now we'll have two JavaScript religious war threads. Much like JavaScript frameworks it replicates uncontrollably.
I guess I have to get me some ESP whatever devices and check out this NodeMCU thing. Find out what is really going on in there. Sounds fun. Shame they called it NodeMCU when all the world now knows Node as a Javascript engine now a days.
@Martin,
From our previous conversations I gathered that you being dragged into the JS/node world has resulted in you and your team becoming very productive and successful within the company. You are now in an "elite team" of which you are one of the elite. This all sounds very good, for the company, for you, your lively hood and you family.
I'm not sure why you are still having such a bad allergic reaction
Perhaps now with your two years of intensive node experience you could tell us what the main problems with it have been on your project?
I'm kind of interested in seeing if your major JS gripes are the same now as when you first started out.
Or maybe the same gripes are there plus a bunch of new ones
Confirmed. ;-)
NodeMCU does not need help from external machines to get stuff compiled to Lua VM opcodes. An external Lua compiler can be used to crosscompile Lua scripts on the PC. ..."fact()" compiled from REPL.
> require"ll"() 61 init.lua 133 cat.lua 592 telnetd.lua 434 thingspeak.lua 176 ll.lua 101 init-sta.lua...there is no "ll.lc", only "ll.lua" so "require" used "ll.lua".> require"cat"("ll.lua") local module=... return function() package.loaded[module]=nil module=nil local k,v for k,v in pairs(file.list()) do print(string.format("%7d %s",v,k)) end end > _...and "ll.lua" really is readable source code."require" would have used "ll.lc" (Lua VM code) if present.
The ~ and ^ in the package json are a trap. Someone will ship a new version of a package right before the final build and break everything. I was fighting a year long battle to stomp out their usage.
NodeJS packages don't behave the same on Windows as Linux, while Java performs much more reliably cross platform. Now the fanboys would say just use Ubuntu laptops and Windows users get what they deserve. Well most corporation use Windows desktops and it's not like the developers have a choice. We certainly didn't.
SSL is critical to what we do, but NodeJS doesn't perform that well using SSL. So we had to slap an Nginx proxy in front on the same box and use the loopback address between them. It's a kludge like the rest of the stack.
As I said in the Official JavaScript religious war thread. The JavaScript frameworks and tools churn constantly, and frankly for no good reason. Grunt versus Gulp why?
I just don't want to use this junk.
Certainly there has been a lot of "churn" in the node world. Hardly surprising considering it's all relatively new stuff under development. You might call that "unreliable", I think it's good. One just has to manage it a little bit. For example it's nuts to pull packages of the net with NPM for a production system. For a production system you want to go live with all the same versions of everything you have been using for development and testing. You need traceability, same as you do for any serious software. Surely you would not be upgrading libraries the night before going live in any other language? That is simply taken care of by using your own npm repository that is only updated when you say so. Or use shrinkwrap https://docs.npmjs.com/cli/shrinkwrap
Do you have an example of node packages that don't work the same on Windows and Linux?
Interesting about SSL performance. I have not had a problem with this but then nothing I make gets heavy use. I was just about to evaluate this issue for a data streaming system.
Personally I don't think using nginx or whatever in front of node apps is a "kludge". It's quite likely that your node app is in fact a lot of node little services running on different ports, or different machines, perhaps behind a load balancer or whatever. Rather than one big monolithic server process. This is all good practice.
Frame works...Oh dear yes, I agree, more later...
Now you might say why not use your own repository that you control? Such a repository would require security audits because it would be a target for malicious code injection, so it is not allowed. The same is true for build and deployment machines which are all under lock and key.
It's been a year since Linux versus Windows package hell, so I can't recall the specific package. But I imagine now that I am using Node I will bump into it again.
You're right that you might want a central web server dispatching based upon context root to multiple apps. But that central web server need not be on the same box because Java apps servers can do SSL efficiently. The Nginx layer is a kludge because we require yet another web server on the same box.
I think the lack of heavy usage might be a reason why you think better of Node than I do. The apps I work on get upwards of 700 transactions per second. That means even slight differences in performance characteristics become big problems. We manage this by horizontally scaling our services so we have multiple boxes performing the same role. Duplication of something like a web server has big implications in resources because we might have 50 copies of it.
It comes off as incredibly passive aggressive because you don't know you are replying to a sunk thread until after you post. Having a visible indicator of sunkeness would save this annoyance.
Thanks for answering, A good question. I'm totally with you. Web "frameworks" have been springing up like weeds. See: https://en.wikipedia.org/wiki/List_of_JavaScript_libraries. It's a mess. Chaos.
Why is it?
Seems to me that some years ago people started to create large amounts of code for their, lets call them "Web Apps" rather than just the little bits of JS form validation and useless element animation. This is the rise of AJAX. Think gmail and such. At that point the pain of using the web browsers DOM API becomes too much. The DOM is horrible. Not to mention the pain of getting things straight with CSS and working the same in all browsers. So, the first thing you do is create a library to abstract all that Smile away. Enter Yahoo's YUI, GMX's qooxdoo, and so on. The biggy there was jQuery.
It's analogous to the GUI world in Linux/Windws/Mac applications. Nobody wants to use the X11 API. People want to create cross platform code. So we have Qt, GTK, Java, .Net etc etc to gloss over all that.
Personally...When I first returned to web development, having sworn never to go near PHP, HTML, CSS, MySql soup again last century, I was happy. Happy because I could get my little node server thing running, get a stream to my browsers with websockets, create a live data visualization in webgl, and never have to go near that PHP, HTML, CSS soup. I let the other guys in the company do that. Also I demonstrated that all of that can be done quicker than the FLASH guru they had hired to do it, he missed the siz week deadline
Of course since then things went wrong. Soon I was expected to create web things all on my own. Gak. Then I rediscovered the horrors of the DOM API. And discovered the horrors of "Framework Soup".
Initially I decided to ignore the frameworks and stick with the DOM even if it is horrible. Life is too short to evaluate all the other stuff. Bad idea, soon you find yourself creating shims over the DOM, your own framework, oh no...
Here is where I landed:
1) If my creations work with Chrome, Firefox and the Edge it's good to go. That means one can use a lot of ES6 features in browser side code. That means no need for coffescript, babel, etc. I can get away with this because nobody is demanding we support old browsers.
2) Styling gets delegated to bootstrap. If anyone demands customization of styling then they can pay for a CSS guru to do it.
3) React.js for DOM rendering. Why? Because it's small, it's not a framework, it does not take over you entire development. React just does one thing, render stuff to the DOM. That can be a whole page if you like or just a single widget in a div somewhere. One can embed anything else inside a react widget, like webgl or a D3 graph. React is efficient both in both the effort required to learn to use it and run time performance. Again, I'm with you.
To be fair NPM is not a build tool. It's a package manager, it just fetches library code for you. As such it does a brilliant job.
Why do we have build tools in Javascript for God's sake? Node.js does not need any, just write your code and it runs. Historically the browser code does not need building either. How easy can it be?
Seems the motivation for build tools is:
1) Performance. If you have a lot of JS it's more efficient to stuff it all into one big bundle than have the browser fetch a thousand little JS files. Plus you can minimize the file size by removing spaces and blanks. And perhaps gzip it.
2) Language features. If you want to use new ES6 Javascript language features in the browser you need to "transpile" that to ES5 Javascript that all browsers can understand.
3) A module system. node.js has a module system. There is a module system defined in ES6 which no browser supports yet. So if you want "modules" you start using a build system.
After toying with the webpack build system I have decided this is all nonsense, a build system is not required even for browser code. Why?...
1) Performance. With HTTP2 making a ton of requests for JS files is efficient. No bundling required.
2) Language features. Chrome, Firefox and the Edge support all the ES6 features I need. No transpiling required.
3) Modules. Bah, I just get my "main.js" to download all the sub JS files it needs. No script tags. No modules
All of the above makes the development turn around cycle much quicker. Got me there Martin. We don't have any automated testing!
Heck, another long essay, sorry folks.
I should point out that neither of Martin's gripes about Javascript are anything to do with Javascript as a language. They are all about the browser, the DOM, the available libraries, the tools, and such. Much of which I agree with.
On the other hand, when I hear people from the BBC's web site, which you must admit is huge and gets a lot of use, describe how well things go with node.js I like to think scaling issues are not insurmountable.
All of which makes me think it is less suited to Embedded Control.
Long term Stability and simplicity still matter in the Embedded space, even on a P2
The canonical language in the embedded world is C. That has tons of baggage as well. Every micro controller form every vendor has its own IDE and build system and libraries. C code is not easily movable form MCU to MCU.
Or you can go it alone and use GCC, if there is a target for your machine.
In terms of stability JS the language itself has been almost the same for decades. It is well standardized like C and C++.
With all the JS tools and libraries we are likely to use being open source once you have a system running it is stable forever.
Imagine if the Propeller were as successful as node.js. There would be tens of thousands of objects in OBEX, the might be a OBEX Package Manager, OPM, to help you sort that out and take care of versions. There would be the same "baggage" as we see in node.js world.
There are plenty of reasons for not wanting to use JS in tiny and/or embedded and/or real-time systems. Speed, size and so on. But I don't think it's popularity and hence "baggage" is one of them.
If you go to the BBC and it fails to load just hit refresh. If you submit a transaction with financial consequences you do not want to hit refresh on failure.
Bingo.
Bingo, yes, JS the language has been stable for decades. And well standardized.
There are strategies for one time use tokens that can detect these sorts of scenarios, but when they happen they annoy users. So it's an issue of not making an annoying problem worse.
Certainly it fails on Speed and Size, and lack of suitable data types, and 'popularity' is not worth much, if it brings the wrong type of expectation. That's the bad type of baggage.
64b Reals for everyone !!! - Err, sorry, not on embedded MCUs - you WILL need to re-learn what you thought you knew...
There are better choices, for P2.
Pushing a 'bad fit' language could actually harm P2 sales, as someone will show just how terribly slow their JS is on P2, vs a M7 or some other new ARM+FPU offering.
https://blog.cesanta.com/why-a-javascript-engine-presentation
https://github.com/cesanta/v7?__hssc=180191483.1.1468960833516&__hstc=180191483.7c19e7f311cdd64189ee446f7693dd00.1468960833516.1468960833516.1468960833516.1&hsCtaTracking=f9ecae1b-171c-4dcf-8a5d-d0cba677009d|5a96799a-57ed-44d6-9a02-4e642380cd3d
Edited to add: it is in this list https://en.wikipedia.org/wiki/List_of_ECMAScript_engines so maybe you've seen it. I ran across it when looking at some IoT stuff.
I have seen that list of ECMAScript engines, started checking them out, starting with Jerryscript, then forgot all about it. Thanks for the reminder.
You could almost be quoting the young Heater from the late 1970's:
Certainly BASIC fails on Speed and Size, and lack of suitable data types, and 'popularity' is not worth much, if it brings the wrong type of expectation. That's the bad type of baggage.
Now I do sympathize with your point of view. When we want to we roll our sleeves up and program in assembler or C for small size and efficiency. But that is not what this is about. Back in the day Bill put BASIC on micro-processors. Now a days we can put Lua or JS on devices far smaller and cheaper. It's about letting people program them without the friction of all that low level detail.
It only fails on speed if you need to be fast. It only fails on size if it does not actually fit.
By the way, as far as I can tell none of the little JS engines use the FPU even if there is one on the chip. 32 bits is no good. So I don't see why the P2 should not compete with JS on Espruino or whatever.
The bonus is that whist the JS is lumbering a long there is a bunch of other COGs that can be running highs peed peripherals or whatever code.
Yup, but now you have to switch to another language, for Speed/size.
Simpler therefore, to just use that one, faster language for the whole project.
If they do not use it now, it is only a matter of time before they do.
I would prefer to see better-matched languages target the P2, well before the fringe of poorly-matched languages are played with.