Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday June 21 2015, @08:17AM   Printer-friendly
from the two-nodes-back-into-one dept.

Node.js is the software that allows you to run Javascript to create powerful server-side applications by using Google's V8 Javascript Engine. As a Node developer myself, I have always felt frustrated by seeing that Joyent, the company behind Node.s, was extremely conservative in terms of upgrading node to use the latest V8 version; the project was also struggling to get developers to actually contribute to code. This is why Fedor Indutny did the unthinkable: forked node and created IO.js. Today, the two projects are uniting possibly offering developers the best of both worlds


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Touché) by Anonymous Coward on Sunday June 21 2015, @08:21AM

    by Anonymous Coward on Sunday June 21 2015, @08:21AM (#198995)

    Interpreter everywhere. Compilers are for dinosaurs and terrorists. We have the technology to put every fucking thing into the browser. If it slow, THROW MORE CLOUD AT IT. That's the Hipster Way!

    Starting Score:    0  points
    Moderation   +1  
       Touché=1, Total=1
    Extra 'Touché' Modifier   0  

    Total Score:   1  
  • (Score: 0) by Anonymous Coward on Sunday June 21 2015, @11:22AM

    by Anonymous Coward on Sunday June 21 2015, @11:22AM (#199026)

    Actually, I'm a nodeJs developer myself. That's rather the point of it, it is not slow and can act very much like a full desktop application inside a web browser.

    There is overhead for a scripted language, but you should probably understand that a computer in 2001 was powerful enough to run this script. It is now 2015 and even cell phones now have the horsepower to run these scripts so your argument about slowness has never actually panned out in operation.

    • (Score: 3, Informative) by JNCF on Sunday June 21 2015, @04:19PM

      by JNCF (4317) on Sunday June 21 2015, @04:19PM (#199109) Journal

      Node is not inside the web browser. You can compile CommonJS (which node uses) into normal ECMAScript that can run in a browser, but the web browser definitely isn't running node. Processing power (and interpreter efficiency) has improved, but there is still a huge gap between ECMAScript in a browser and compiled C. Projects like asm.js and WebAssembly are trying to bridge that gap, but they haven't yet. The fact that they exist shows that there is a need for faster code execution than modern ECMAScript allows. We might as well be honest and up-front about this weakness. There are other reasons to use ECMAScript, and node.

  • (Score: 3, Insightful) by mtrycz on Sunday June 21 2015, @12:11PM

    by mtrycz (60) on Sunday June 21 2015, @12:11PM (#199042)

    We've had interpreted languages for decades. It's faster to develop, and is a good pick if performance is not an issue. For example a rest service or a simple website. You shoudln't probably put in 5x the time to develop a microservice that isn't resource intensive.

    "But it doesn't fit *my* usecase!". Choose something else, then.

    --
    In capitalist America, ads view YOU!
    • (Score: 3, Insightful) by VortexCortex on Sunday June 21 2015, @06:31PM

      by VortexCortex (4067) on Sunday June 21 2015, @06:31PM (#199150)

      We've had interpreted languages for decades. It's faster to develop, and is a good pick if performance is not an issue.

      This is precisely why my compilable meta language can also run as an interpreted. There is really no reason one can't make a scripting language that can also be compiled. Just make the interpretor / VM and (optional) bytecode compiler part of the language's standard library. That is to say: If the scripting language is designed for performance then it's a good choice even if performance is your goal.

      If the compilable language is its own scripting language (as most interpreted languages are) then you can seamlessly call into and out of compiled and scripted code without a separate cumbersome API call (see: embedding Lua or JS in C). Transparent compilation permits any batch of code to be designated as compiled or scripted. The only difference between what is compiled and what is scripted is then which data you chose to compile or leave as a script. Done with rapid prototyping of some feature's code? Mark it for compilation to make it run faster. Want to fiddle with some compiled section of code at runtime? Mark it as a script. Prior to release, compile everything (except user scripts, such as configuration/customization scripts). Don't use eval() on mutable strings or runtime tainted input? Great! The VM/compiler library module doesn't have to be linked with the native program build -- you can produce a statically compiled program.

      In other words: There's this huge false dichotomy that's cropped up between scripted and compiled languages. Granted, some languages are designed to make complete compilation nearly impossible (like Javascript / ECMAScript), but any compiled language can always become its own scripting language by deferring interpretation (lexing / parsing) and compilation to runtime (like some interpreted languages do, see: V8's Just In Time compilation). Language dynamism is a different issue altogether; However, there's nothing preventing a dynamic language from also being compiled. You just apply another level of indirection to data structures (allow all methods and properties to be "pure virtual" in C++ parlance -- an extra dereference per access / call).

      There's really no reason not to have your dynamic interpreted script and compile it too, it's just that very few languages have been designed to facilitate this. Considering the "hybrid" approach gives you the benefits of both I expect to see much future development in this area, especially since many popular interpreted languages do some JIT compilation. So, when GP said, "Never Compile Anything, Ever!", it would have be more accurate to say, "Always Compile Everything, Everywhere!"

      • (Score: 2) by Nerdfest on Sunday June 21 2015, @06:48PM

        by Nerdfest (80) on Sunday June 21 2015, @06:48PM (#199158)

        You could do exactly this with Java at one point. I haven't looked at it lately as Java has actually been 'fast enough' for anything I've worked on.

  • (Score: 2, Funny) by Pino P on Sunday June 21 2015, @02:39PM

    by Pino P (4721) on Sunday June 21 2015, @02:39PM (#199080) Journal

    In other words:

    Compilers are for luddites.
    Modern web app appers app web apps using JavaScript apps! Apps!