Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Microsoft Google

Microsoft Asks Node.js To Allow ChakraCore (Edge) Alongside Google's V8 Engine (softpedia.com) 146

Posted by samzenpus from the add-please dept.
campuscodi writes: Microsoft has submitted an official pull request to the Node.js project, through which it's asking the project's maintainers to enable support for ChakraCore, the JavaScript engine packed inside Microsoft's Edge browser, as an alternative to Node's built-in V8 engine, developed by Google. Earlier in December 2015, Microsoft open-sourced ChakraCore. Microsoft has also been one of the biggest companies to adopt Node.js early on, and is also part of the Node.js Foundation's Board o Directors. The main reason to add ChakraCore support in Node.js will help the IoT version of Windows 10 to run JS apps on IoT devices, just like Samsung is also thinking about.
This discussion has been archived. No new comments can be posted.

Microsoft Asks Node.js To Allow ChakraCore (Edge) Alongside Google's V8 Engine More

Microsoft Asks Node.js To Allow ChakraCore (Edge) Alongside Google's V8 Engine

Comments Filter:
  • Who sits on the board, and whose thumbs are they gonna twist?

  • Why not... (Score:2, Insightful)

    by Anonymous Coward

    Edge is a lot faster than Chrome in a lot of areas and handily spanks Firefox. Nothing wrong with competition.

    • Re:Why not... (Score:4, Insightful)

      by Z00L00K ( 682162 ) on Friday January 22, 2016 @12:58AM (#51348725) Homepage Journal

      Do you have any documentation available on that?

      Not only benchmarks but also perceived performance by the user.

      • Re:Why not... (Score:5, Funny)

        by Anonymous Coward on Friday January 22, 2016 @01:09AM (#51348743)

        If only there was a queryable index of websites you could search by keyword this would be a lot easier. Guess we'll never know.

      • Re: (Score:1)

        by Anonymous Coward

        Benchmark: http://blogs.unity3d.com/2015/12/15/updated-webgl-benchmark-results/ [unity3d.com]

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          That's nice, but that's

          1. A benchmark of WebGL and not the JavaScript engines
          2. A benchmark of asm.js which is a Firefox thing

          All it proves is that a benchmark optimized for Firefox is fastest in (gasp) Firefox.

          Any benchmark designed around testing real-world browser performance shows Chrome and even Edge handily spanking Firefox. Firefox is only "fast" in the benchmarks that either are designed to test Firefox technology (asm.js) or benchmarks Firefox has optimized itself for. But never in the real world.

          • Somebody modded you insightful? Well, lets see the benchmarks that Microsoft has. But don't worry, everyone with an once of common sense will understand if Microsoft doesn't "come out."; and while we're on the subject, lets throw Apple in there also.

            • Not done by Microsoft, but here is a benchmark that was done in July between IE, Edge, Chrome, and Firefox by Anandtech:

              Benchmark IE 11 Edge 20 Chrome 43 Firefox 39
              Sunspider 149.7ms 133.4ms 247.5ms 234.6ms
              Octane 2.0 9861 22278 19407 19012

              These are the relevant tests that stress the javascript engines. I've omitted the ones that test chrome's proprietary HTML extensions, or graphic rendering. There are plenty of other benchmarks testing the entire browser for page l

          • Note that one of the purposes of these benchmarks was to test the 64-bit version of Firefox vs. the dominant browsers.
      • It's not what Microsoft does that's the problem, it's what it doesn't do that is.

    • Re: (Score:3, Insightful)

      by mwvdlee ( 775178 )

      Does it matter? If ChakraCore's language support for JavaScript covers 100% of V8's language support, no more no less, they can integrate it in Node.js just let the user decide which is better in which situation.

      The main issue is this language compatibility. Node.js would need to define the language syntax they officially support, possibly defined by just taking most of V8's language support, and would have to get a binding commitment that the other one will stay in line within a reasonable time and not ena

      • Re: (Score:2)

        by jopsen ( 885607 )
        main issue is binary modules...

        • Re: (Score:3)

          by Melkman ( 82959 )

          So basically you say this is the embrace step with an extend step to follow by using binary extensions ?

        • main issue is binary modules...

          main issue is wtf are we putting javascript into more and more things connected to the Internet for? We already have tons of examples of "what could go wrong."

          • Re: (Score:1)

            by KGIII ( 973947 )

            I know it's not JavaScript but, damn it, I'm waiting for a resurgence in Java applets in the browser. I shit you not, I seriously expect to see this happen in the not-to-distant-future. Why? Someone will think it's a grand idea, all over again.

            • Better to just have Java applications on the desktop, etc. At least get rid of the web browser portion and the risks of XSS, etc. HTML was supposed to be for rendering and cross-linking texts, not an "application platform."

      • Re: (Score:1)

        by Anonymous Coward

        Why would MS have to restrict themselves to the subset implemented by V8? Who's to say that node won't change their mind and use Chakra and replace V8?

        In fact, who's to say that V8 won't change their language implementation in ways incompatable with node.js anyway?

          There clearly is a push inside node.js to target ES6 instead of V8's particular variant.

        • Re:Why not... (Score:4, Insightful)

          by mwvdlee ( 775178 ) on Friday January 22, 2016 @03:23AM (#51348989) Homepage

          There's nothing stopping V8 from doing the same dick-move.
          But right now, Node.JS's language effectively IS whatever V8 is.
          If Node.js can set their own language standards and block syntax outside that standard, it would make swapping engines a total non-issue.

        • Re: (Score:1)

          by Anonymous Coward

          Because when V8 does it, it will be called progress and be hailed as innovative.

        • All the browsers did and still do this. If all browsers strictly used the WWW standards all our website would still look like geocities pages ca 1995.
          It is called innovation.

      • "The main issue is this language compatibility," my ass. When Microsoft shows up, no good comes of it, unless you're Microsoft; a review of the public record on lawsuits is ample evidence.

        • I think the review of public record on lawsuits against google would be a much larger pile about now.

    • I have a web app that uses javascript heavily to render a complicated table

      In my experience edge is much faster with HTML rendering of a large table but the js is slower

    • Re: (Score:1, Informative)

      by Anonymous Coward

      Nothing wrong with competition.

      Very true. But this is Microsoft. A corporation that will wiggle into protocols and standards, then use their market share to gain instant market penetration, and then add proprietary extensions or redefine existing functionality with the sole purpose of breaking compatibility to ensure their implementation is the only one people can use.

      That's the biggest issue, and why people are deeply concerned. They never want to help, they want to embrace, extend then extinguish. It's their modus operandi since the 19

    • Re: (Score:1)

      by Anonymous Coward

      I believe it has a more complete ES6 implementation as well.

    • You're an idiot. Remember JavaScript. Microsoft did fuck all to JavaScript by supporting proper JavaScript and introducing it's own version such that developers had to check to make sure the code they wrote worked and even write separate code for Microsoft browers and everyone else.

  • Embrace and Extend (Score:4, Insightful)

    by mr.dreadful ( 758768 ) on Friday January 22, 2016 @12:49AM (#51348693)
    Why would this be beneficial to anyone but microsoft?

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      That is a good question.

      Another interesting question is the risk of bugs in that engine that might infect other applications as well. If the same engine is used in multiple platforms this may mean that malware may be more successful than expected.

      • Re: (Score:1)

        by Dog-Cow ( 21281 )

        An actually interesting question is who allowed you on the Internet? Your question makes absolutely no sense at all, considering that V8 is currently multi-platform and backs every Node.js implementation in existence (outside labs).

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Yeah, choices are silly.

    • Re: (Score:2)

      by sosume ( 680416 )

      Why would this be harmful to anyone but Google?

    • Because ChakraCore is faster and more standards compliant than V8 (not to mention the version of v8 that node is using).
  • Is ChakraCore measurably faster? Is it more portable? Is it more adherent to standards?

    Perhaps it is or perhaps it isn't. If it's only marginally better, or not better at all, then why would Node.js want the maintenance headache of two backends with no meaningful differentiation?

  • The main reason to add ChakraCore support in Node.js will help the IoT version of Windows 10 to run JS apps on IoT devices

    V8 doesn't support Windows?

    • Re:V8 doesn't support Windows? (Score:4, Insightful)

      by DrXym ( 126579 ) on Friday January 22, 2016 @03:37AM (#51349015)
      Yes but maybe it doesn't compile under UWP which is Microsoft's universal API across IoT, mobile, desktop. UWP only supports of a subset Win32 so code that compiles to Win32 may not compile to UWP without lots of patching.

      I've been lead on this merry dance of bullshit before with Windows Embedded where the toolchain only supports a subset of Win32, a subset of STL classes and C headers and suddenly code that used to be portable no longer is.

      I wouldn't see that as an excuse to replace the entire backend though. Microsoft should supply patches to fix V8.

      • Comment removed based on user account deletion

        • Re: (Score:3)

          by DrXym ( 126579 )
          I haven't used Windows 10 IoT but previous Windows Embedded versions had a thing called platform builder where you got to pick and choose what components you wanted and then you built it. e.g. if you didn't need IE, you didn't choose it. So I wouldn't be so sure that a standalone JS engine is already there.

          More likely V8 drags in a bunch of open source libs and tools like gyp and porting them to work on UWP is a bother. But its a problem of Microsoft's own making and I don't see that sidestepping the issu

        • Re: (Score:1)

          by StonyUK ( 173886 )

          Presumably chakracore will already be there, whereas V8 won't. Size is important in IoT.

          The engine used by node is embedded inside node, so currently it has an embedded version of v8 and if you were to install a chakra based version of node, it will have it's own copy of ChakraCore embedded in it.

    • Possibly not, for the specified architecture. Windows 10 IoT targets the raspberry pi 2.

      Google Chrome on Windows is amd64 and i386 only.

  • Argh, matey (Score:5, Funny)

    by wonkey_monkey ( 2592601 ) on Friday January 22, 2016 @03:32AM (#51349007) Homepage

    the Node.js Foundation's Board o Directors

    Yargh, and it be a fine board too.

  • don't support engines, OS's and devices (Score:5, Insightful)

    by Anonymous Coward on Friday January 22, 2016 @03:40AM (#51349023)

    support standards instead.

    • Re: (Score:2)

      by MobyDisk ( 75490 )

      There is no standard Javascript engine implementation, and no standard for linking to JavaScript engines. So that isn't really an option here. I suppose someone could create a standard interface for linking to JavaScript engines, and make node.js support that. Then someone would have to either update V8 and ChakraCore to support that, or make an adapter.

      Hmm... now that you fooled me into proposing a way to make it possible to do as you suggest, I actually like that approach

  • Embrace and extend (Score:1)

    by Anonymous Coward

    Microsoft will quickly add non standard extensions to their engine and suddenly you'll have node.js applications which will only work if engine == ChakraCore.
    That's how Microsoft plays. This is not a "good competition", the only winner is MS.

    They're pretending to be very nice those days, like a bully that's been ousted from the playground. Because they've been ousted from the playground.
    But it's OK, we have new friends now and we don't need you any more Microsoft.

    Now, let the MS PR guys down vote my comme

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      It's not very different from the Nigerian Prince mail scams we see now and then. It's a bait that can be used to reel in Node.js under the cover of Microsoft.

    • gcc has things that are not standard C++, Linux has API calls not in Windows, Firefox, Chrome, Opera all have things that IE and the other browsers can't do.

      It is called "innovation"

      Javascript is horrifying enough as it is, it could use some of that "innovation" thing.

  • SpiderMonkey, ChakraCore, JavaScriptCore, Duktape (Score:5, Informative)

    by SirJorgelOfBorgel ( 897488 ) on Friday January 22, 2016 @06:16AM (#51349273)

    I know a bunch of you think V8 is cross-platform enough, but really it isn't. It uses way too much memory for many platforms, there's no non-JIT mode (so can't run on iOS), oh and it is a female dog to compile.

    Node.js' use cases are not limited to running a Node.js server. Embedding the core inside a bigger application and using it for some types of cross-platform logic, scripting, etc is a real thing. Maximizing compatibility is a must in that case.

    Aside from just having options, various engines offer different features you may want to use, and better compatibility with your target platform.

    JXCore has done a great job extending Node.js to support mobile, and they support SpiderMonkey and ChakraCore alongside V8. Compatibility wise they're king of the hill already, though they could still add JavaScriptCore and maybe even Duktape for good measure.

    • Exactly. Language platforms are not just about the syntax and libraries. It is also about the implementation underneath. And there different implementations have different pros and cons.

    • Re: (Score:2)

      by MobyDisk ( 75490 )

      Node.js' use cases are not limited to running a Node.js server. Embedding the core inside a bigger application

      Ding ding ding!!!

      I am working on a project that needed an internal scripting engine. We first looked at nodeJS, but then realized exactly the limitation you point out: we can't "embed" node inside of an app. So I can't make in-process calls to/from JavaScript. There are various other wrappers that allow you to embed V8 into apps, and we went with one of those. But if Node supported that mode of operation, we would have used it. Most other scripting languages work this way: They are in-process libraries

  • "We are the Borg. Lower your shields and surrender your ships. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile."

  • In embedded v8, it is a headache and a half to create custom types that vitally need to perform some task such as releasing used memory held by a native implementation upon cleanup. In v8, if you simply want to have some cleanup code get called, you have to allocate a Persistent along with your data, explicitly invoke SetWeak on that Persistent to specify the finalize callback, and then make sure that you keep the allocated persistent around for the lifetime of your custom object (which means that your fi

  • This request is pointless. It's clear how it's advantageous to Microsoft to have their engine used instead of Google's.

    But it has NO advantageous to either the node.js project OR the people who make use of node.js. Please don't even consider it.

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close