8 ms·

Why do people make terminal-based programs like this in NodeJS? I'm not trying to be snarky - it's a legitimate question. This program is relatively resource-in

Why do people make terminal-based programs like this in NodeJS? I'm not trying to be snarky - it's a legitimate question. This program is relatively resource-intensive, and you're using NodeJS of all things to try to render things in the terminal. It seems like the most counter-intuitive tool for the job.

neoeldex 9y ago
It's easier than bash ;) It shouldn't really matter, Node is quite performant nowadays, but compared to a compiled language it might be slower, but easier to write up. This project is a toy project, so why spend the time on optimizing ;)
- gwbas1c 9y ago
  Isn't node JIT? It might have a slower startup time, but it should be about as fast as a compiled language once running.
  - udp 9y ago
    Not as fast as a compiled language, because JavaScript is too dynamic to apply the same kind of aggressive JITing that things like the JVM or CLR can. It is, however, "fast enough"(tm).
    - gnode 9y ago
      You say that, but in some ways it has the potential to be faster. JIT compilers can recompile code at runtime making use of a profiler, optimising specifically to both the host and the use case. Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken.
      - sedachv 9y ago
        Benchmarks or GTFO. Tracing JITs are hard to implement, use up a lot of memory, and cannot efficiently implement many kinds of control flow[1]. AFAIK TraceMonkey was the only JavaScript tracing JIT and it was not that great.[2] [1] https://news.ycombinator.com/item?id=13774326 https://news.ycombinator.com/item?id=13774326 [2] https://en.wikipedia.org/wiki/SpiderMonkey https://en.wikipedia.org/wiki/SpiderMonkey
      - monocasa 9y ago
        > Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken. And that logic that's needed to test invariants is exactly the overhead we're talking about.
rastapasta 9y ago
Good question indeed, main reason for me was the incredible well toolset in the node.js world around Vector Tile based map data and GIS processing. Check out the list of used libraries in the repo and you might understand ;)
udp 9y ago
> It seems like the most counter-intuitive tool for the job. How so? What exactly do you think is more difficult about this in node than in other languages or frameworks? Is there something you would recommend as a better alternative? As much as I like developing in C for fun, it's not a good pragmatic choice (unsafe, verbose, you don't need direct memory access to build an application like this one). Nor is bash, unless you think archaic syntax, primitive control flow, and a lack of modern language features are good things. If you'd suggest something like Python, it's basically exactly the same as node in terms of how high level it is, but (anecdotally) the package ecosystem is much richer in node and npm is easier to use than pip. It's almost like people think because JavaScript started in browsers it should stay there and any other use case is somehow wrong or a hack. But ECMAScript is an open scripting language standard and has absolutely nothing to do with the DOM, or alert()s, or onclicks. I write a lot of Java and C++ for pragmatic, work-related reasons, but if I need to write a command line application quickly I'll always come back to node. It's just so damn fast to develop with, and nearly everything I need is one npm install away.
- tomc1985 9y ago
  But perl, python, ruby, and even bash have filled that role for years. I'm also chiming in with a small amount of disgust at seeing nodejs in play, though at least this isn't an electron project.
  - udp 9y ago
    > disgust at seeing nodejs in play Do you know much about Hacker News? Justify your opinion or don't bring it here.
  - deleted 9y ago
    [deleted]
ashark 9y ago
You can smack together something that grabs JSON over HTTP and does something with it really, really fast in Node. Fast to write, that is, not necessarily to execute. Reading command line arguments and config files is also much faster/easier/saner/just-works than other, otherwise-better-for-the-task languages (to pick on a favorite: Go, at least the last time I looked at it, which was way too long ago)
lucideer 9y ago
I'm wondering if you're confusing nodejs with HTML/CSS web renderers like Electron, which have received a lot of criticisms for being slow, and also use a nodejs runtime internally. Electron uses nodejs/v8 as a backend, with Blink/HTML/CSS rendering the UI - the latter introduces some of the well documented performance challenges. This appears to use nodejs/v8 as a backend with your terminal (of choice) rendering the UI. Perhaps I'm completely misreading your question though.

neoeldex 9y ago

It's easier than bash ;) It shouldn't really matter, Node is quite performant nowadays, but compared to a compiled language it might be slower, but easier to write up. This project is a toy project, so why spend the time on optimizing ;)

gwbas1c 9y ago
Isn't node JIT? It might have a slower startup time, but it should be about as fast as a compiled language once running.
- udp 9y ago
  Not as fast as a compiled language, because JavaScript is too dynamic to apply the same kind of aggressive JITing that things like the JVM or CLR can. It is, however, "fast enough"(tm).
  - gnode 9y ago
    You say that, but in some ways it has the potential to be faster. JIT compilers can recompile code at runtime making use of a profiler, optimising specifically to both the host and the use case. Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken.
    - sedachv 9y ago
      Benchmarks or GTFO. Tracing JITs are hard to implement, use up a lot of memory, and cannot efficiently implement many kinds of control flow[1]. AFAIK TraceMonkey was the only JavaScript tracing JIT and it was not that great.[2] [1] https://news.ycombinator.com/item?id=13774326 https://news.ycombinator.com/item?id=13774326 [2] https://en.wikipedia.org/wiki/SpiderMonkey https://en.wikipedia.org/wiki/SpiderMonkey
    - monocasa 9y ago
      > Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken. And that logic that's needed to test invariants is exactly the overhead we're talking about.

rastapasta 9y ago

Good question indeed, main reason for me was the incredible well toolset in the node.js world around Vector Tile based map data and GIS processing. Check out the list of used libraries in the repo and you might understand ;)

udp 9y ago

> It seems like the most counter-intuitive tool for the job. How so? What exactly do you think is more difficult about this in node than in other languages or frameworks? Is there something you would recommend as a better alternative? As much as I like developing in C for fun, it's not a good pragmatic choice (unsafe, verbose, you don't need direct memory access to build an application like this one). Nor is bash, unless you think archaic syntax, primitive control flow, and a lack of modern language features are good things. If you'd suggest something like Python, it's basically exactly the same as node in terms of how high level it is, but (anecdotally) the package ecosystem is much richer in node and npm is easier to use than pip. It's almost like people think because JavaScript started in browsers it should stay there and any other use case is somehow wrong or a hack. But ECMAScript is an open scripting language standard and has absolutely nothing to do with the DOM, or alert()s, or onclicks. I write a lot of Java and C++ for pragmatic, work-related reasons, but if I need to write a command line application quickly I'll always come back to node. It's just so damn fast to develop with, and nearly everything I need is one npm install away.

tomc1985 9y ago
But perl, python, ruby, and even bash have filled that role for years. I'm also chiming in with a small amount of disgust at seeing nodejs in play, though at least this isn't an electron project.
- udp 9y ago
  > disgust at seeing nodejs in play Do you know much about Hacker News? Justify your opinion or don't bring it here.
- deleted 9y ago
  [deleted]

ashark 9y ago

You can smack together something that grabs JSON over HTTP and does something with it really, really fast in Node. Fast to write, that is, not necessarily to execute. Reading command line arguments and config files is also much faster/easier/saner/just-works than other, otherwise-better-for-the-task languages (to pick on a favorite: Go, at least the last time I looked at it, which was way too long ago)

lucideer 9y ago

I'm wondering if you're confusing nodejs with HTML/CSS web renderers like Electron, which have received a lot of criticisms for being slow, and also use a nodejs runtime internally. Electron uses nodejs/v8 as a backend, with Blink/HTML/CSS rendering the UI - the latter introduces some of the well documented performance challenges. This appears to use nodejs/v8 as a backend with your terminal (of choice) rendering the UI. Perhaps I'm completely misreading your question though.