4 ms·

I don't understand this craze to use JS everywhere. It's not the best language for every job. The main argument seems to be 'if you know JS you can use it in pr

I don't understand this craze to use JS everywhere. It's not the best language for every job. The main argument seems to be 'if you know JS you can use it in product X'. If you're not competent enough to learn another language then are you competent to write good enough JS?

jffry 13y ago
I think it's fine for rapid prototyping. It has WiFi and is positioned for internet-connected stuff. There are lots of people who use node.js and packages from npm to interface with internet services, so this gives them an easy way into working with an embedded device without a large learning curve.
- waterlion 13y ago
  There are lots of Python libraries too, and PIP. This wasn't necessarily a dig at just this platform but the general principle of re-inventing multiple wheels, except this time with JS.
  - MatthewPhillips 13y ago
    Python can run on a microcontroller too[1], do you think that's a bad as well? I can't figure out what your criticism is: that they choose not-C or that they specifically choose JavaScript? [1]https://wiki.python.org/moin/PyMite https://wiki.python.org/moin/PyMite
egeozcan 13y ago
I think in this case there are a few reasons: 1) Node.js has a huge ecosystem and it's easy to use 2) JavaScript is known by many 3) JavaScript may not even come close to being a proper language for hardware programming but it is good enough for these kind of devices
- drdaeman 13y ago
  > Node.js has a huge ecosystem So do many other platforms. > JavaScript is known by many So are many other languages. > JavaScript [...] is good enough for these kind of devices So are many other languages. The question, as I got it, was "why JavaScript is chosen among many possibly alternatives?". Your comment does not answer it, I believe.
  - egeozcan 13y ago
    Even if you used the same argument for all my points, the intersection of the result sets seems to be empty. To be more clear, AFAIK, no other platform accomplishes those three goals as good as JavaScript. Maybe Python? GitHub language stats used to say otherwise (until they removed them). I also have the impression that as far as dynamically typed languages go, JavaScript is one of the most optimized ones. Well, Lua and some others beat it on speed but they are not as popular and/or provide what node.js provides.
- reustle 13y ago
  Also, the event loop seems work well with these fun hardware projects
  - drdaeman 13y ago
    You can have event loop in any language that has enough access to underlying OS facilities (select/poll/epoll/kqueue) out there. Can't name a non-esoteric language where you can't off the top of my head.
    - cliffbean 13y ago
      It's not just a theoretical question about whether a particular language is capable of supporting an efficient event loop. It's also a significantly practical question about whether there are a large number of libraries and community experience built up around programs organized this way. This is also one of the big reasons why the people who wrote node.js picked JavaScript in the first place [0]. [0] http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf
bryanlarsen 13y ago
Many embedded projects these days do command and control via a small web server. So you've likely got a fair amount of JavaScript in your project anyways. The rest is often written in a combination of c and Lua. Lua might be a better language than JavaScript in isolation, but it might be better to avoid the cost of context switching your brain several times a day.
- jffry 13y ago
  Tessel actually transpiles JavaScript into Lua, which is what is actually running on the device.
  - legutierr 13y ago
    That's cool. Do you know what library they use to do the translation?
    - jffry 13y ago
      I don't, but their FAQ says that they will be open-sourcing their code and hardware.
  - jnbiche 13y ago
    Oh, way cool. Did you build the transpiler in-house?
    - jffry 13y ago
      I don't work for them, I just read the FAQ at the bottom of TFA: | What's running JavaScript under the hood? | We're currently running a custom-built, real time operating | system on top of a Lua Runtime. Your JavaScript is compiled | to Lua bytecode when you push your code, and that bytecode | is run on the runtime. It's this runtime that allows us to | have such low memory overhead. We may switch over to an | implementation of Libuv or a microLinux flavor in the future, | but that shouldn't change anything about the user experience | with Tessel (except it will be faster!)
  - 13y ago
joeblau 13y ago
The community is one of the best development communities out there. Node + NPM have created an ecosystem with lots of contemporary tools that fall in line very well with the UNIX Philosophy. The few people that I've shown Node to have been surprised about how easy it is to use NPM and tackle dependency management. > If you're not competent enough to learn another language then are you competent to write good enough JS? I used to say that about Java Developers that didn't know C/C++. As I've grown, the thing I've realized is that the end user/customer/client doesn't care what you write your application in (Unless you're on a Government contract). They care if it works.
thedufer 13y ago
JavaScript is built around events and the event loop in a way that few languages are, which makes it well-suited to a hardware environment like this.
- vertex-four 13y ago
  Not really? Javascript interpreters, and the DOM tend to be (and Javascript interpreters only are because they're geared towards being embedded in browsers, primarily). The language isn't any better for it than any other language that supports closures, though.
  - thedufer 13y ago
    > The language isn't any better for it than any other language that supports closures Which puts it pretty high up to begin with. Factor in the number of libraries that assume an event loop (all of them that care either way) and that are asynchronous by default because of this (most of them) and it becomes pretty hard to beat.
- cliffbean 13y ago
  Also, this is not just a property of the language itself, it's a property of the ecosystem built around the language.

jffry 13y ago

I think it's fine for rapid prototyping. It has WiFi and is positioned for internet-connected stuff. There are lots of people who use node.js and packages from npm to interface with internet services, so this gives them an easy way into working with an embedded device without a large learning curve.

waterlion 13y ago
There are lots of Python libraries too, and PIP. This wasn't necessarily a dig at just this platform but the general principle of re-inventing multiple wheels, except this time with JS.
- MatthewPhillips 13y ago
  Python can run on a microcontroller too[1], do you think that's a bad as well? I can't figure out what your criticism is: that they choose not-C or that they specifically choose JavaScript? [1]https://wiki.python.org/moin/PyMite https://wiki.python.org/moin/PyMite

egeozcan 13y ago

I think in this case there are a few reasons: 1) Node.js has a huge ecosystem and it's easy to use 2) JavaScript is known by many 3) JavaScript may not even come close to being a proper language for hardware programming but it is good enough for these kind of devices

drdaeman 13y ago
> Node.js has a huge ecosystem So do many other platforms. > JavaScript is known by many So are many other languages. > JavaScript [...] is good enough for these kind of devices So are many other languages. The question, as I got it, was "why JavaScript is chosen among many possibly alternatives?". Your comment does not answer it, I believe.
- egeozcan 13y ago
  Even if you used the same argument for all my points, the intersection of the result sets seems to be empty. To be more clear, AFAIK, no other platform accomplishes those three goals as good as JavaScript. Maybe Python? GitHub language stats used to say otherwise (until they removed them). I also have the impression that as far as dynamically typed languages go, JavaScript is one of the most optimized ones. Well, Lua and some others beat it on speed but they are not as popular and/or provide what node.js provides.
reustle 13y ago
Also, the event loop seems work well with these fun hardware projects
- drdaeman 13y ago
  You can have event loop in any language that has enough access to underlying OS facilities (select/poll/epoll/kqueue) out there. Can't name a non-esoteric language where you can't off the top of my head.
  - cliffbean 13y ago
    It's not just a theoretical question about whether a particular language is capable of supporting an efficient event loop. It's also a significantly practical question about whether there are a large number of libraries and community experience built up around programs organized this way. This is also one of the big reasons why the people who wrote node.js picked JavaScript in the first place [0]. [0] http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf

bryanlarsen 13y ago

Many embedded projects these days do command and control via a small web server. So you've likely got a fair amount of JavaScript in your project anyways. The rest is often written in a combination of c and Lua. Lua might be a better language than JavaScript in isolation, but it might be better to avoid the cost of context switching your brain several times a day.

jffry 13y ago
Tessel actually transpiles JavaScript into Lua, which is what is actually running on the device.
- legutierr 13y ago
  That's cool. Do you know what library they use to do the translation?
  - jffry 13y ago
    I don't, but their FAQ says that they will be open-sourcing their code and hardware.
- jnbiche 13y ago
  Oh, way cool. Did you build the transpiler in-house?
  - jffry 13y ago
    I don't work for them, I just read the FAQ at the bottom of TFA: | What's running JavaScript under the hood? | We're currently running a custom-built, real time operating | system on top of a Lua Runtime. Your JavaScript is compiled | to Lua bytecode when you push your code, and that bytecode | is run on the runtime. It's this runtime that allows us to | have such low memory overhead. We may switch over to an | implementation of Libuv or a microLinux flavor in the future, | but that shouldn't change anything about the user experience | with Tessel (except it will be faster!)
- 13y ago

joeblau 13y ago

The community is one of the best development communities out there. Node + NPM have created an ecosystem with lots of contemporary tools that fall in line very well with the UNIX Philosophy. The few people that I've shown Node to have been surprised about how easy it is to use NPM and tackle dependency management. > If you're not competent enough to learn another language then are you competent to write good enough JS? I used to say that about Java Developers that didn't know C/C++. As I've grown, the thing I've realized is that the end user/customer/client doesn't care what you write your application in (Unless you're on a Government contract). They care if it works.

thedufer 13y ago

JavaScript is built around events and the event loop in a way that few languages are, which makes it well-suited to a hardware environment like this.

vertex-four 13y ago
Not really? Javascript interpreters, and the DOM tend to be (and Javascript interpreters only are because they're geared towards being embedded in browsers, primarily). The language isn't any better for it than any other language that supports closures, though.
- thedufer 13y ago
  > The language isn't any better for it than any other language that supports closures Which puts it pretty high up to begin with. Factor in the number of libraries that assume an event loop (all of them that care either way) and that are asynchronous by default because of this (most of them) and it becomes pretty hard to beat.
cliffbean 13y ago
Also, this is not just a property of the language itself, it's a property of the ecosystem built around the language.