12 ms·

How JavaScript engines achieve great performance

145 points by EntICOnc 5y ago

oblak 5y ago
Missing "How" from title Pretty cool article. I've been dealing with JS for years without ever thinking too hard about how it all works
ithrow 5y ago
Javascript being fast as Java and coupled with Typescript the future of Java doesn't look very bright.
- jetsetgo 5y ago
  Please stop. These kind of remarks just brings the worst of out community. JAVA is and will be fine. It's doing better than ever.
- ragnese 5y ago
  TypeScript is awful. Like, I shit on Java all the time, and I WAY rather work in Java than TypeScript. TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. Record<> is broken/unsound: https://github.com/microsoft/TypeScript/issues/45335 https://github.com/microsoft/TypeScript/issues/45335 Generics are wonky and sometimes wrong: https://github.com/microsoft/TypeScript/issues/31006 https://github.com/microsoft/TypeScript/issues/31006 The `readonly` keyword does absolutely nothing: https://github.com/microsoft/TypeScript/issues/13347 https://github.com/microsoft/TypeScript/issues/13347 Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. TypeScript is actually so bad that it might have honestly made JavaScript worse, if that's even possible.
  - deleted 5y ago
    [deleted]
  - Scarbutt 5y ago
    It's a shame that something like Typescript is and will dominate the static typing JS ecosystem/industry instead of something simpler and sane like Rescript.
    - ronenlh 5y ago
      Rescript is sane but I wouldn’t all it simpler. It can be really hard to do trivial stuff with it. I felt I had to study OCaml to understand it.
      - quaunaut 5y ago
        I think it gets pretty close, but admittedly its handling of unknown objects is just downright bad. Also, somehow, the tooling for it has one of the best features around(compiling to readable JS), but all other tooling is completely absent, and frankly, bad.
  - quaunaut 5y ago
    I generally agree with everything you're saying, after extensive use of Typescript. Its safety guarantees usually only help within extremely tight bounds, and there's surprisingly little that it catches that couldn't be inferred directly. However, a question: > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. --- Separately however, I think it's worth noting that I've been playing with the idea of doing a project in plain Javascript again, to see if I feel any serious productivity losses. - [1]: https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeKBvAUFKpIC4oDk8wBANJlAK4DOE1AMgJbDAQBOARgPYAe+3XADYQ4AO3QBfdOhzQAIlwDmyNBVn4CCxWQoALLjQgc2XANYRR+YG0oRJ02VACCoxgFs4glVqgAfWAjSAPQAVCGYIVAAKrqM1FBcotBsEMCUbKLxYlAABi7ungDaALo52OAQAHQRQegAxonUiHAAJi3UxACSogBm7CktKgAUYgWC1Pj5HoIlAJTIAHyqWKPT1JVgNLpDqOqExGRUtAzMrJy8VjYQErMUKWkZUKue1Pah4VCRMXEJSVD36UyUAA7roEBAAG7scqQKAgAxQRRwKFQZikJ7xQSJZRweLMKAQHisUTtXJTTw5SrOeLwyhQOrZWgQdH4-pcNjxYBgxD41qkhmIDgQBmGVGICGMITgzm6aANTLWOCMUSILg9J5QaiUDiyaqfWryppPNodBAAUSJFlJKAAPFECZaSfFyYIFiNXGt8FE5otlk8PS8NlsdnsiAhDoYTix2Nw+Ngrjc7qlAf6xq8pPVGogWkoJlAtCUVIVdhUNFpDvpDMYzBZLrYJMVMwqoD0uFwVHzTcBun02AMhjnFNRbobBXA2B2TcQLcT2gPc7cgA https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeK...
    - ragnese 5y ago
      > I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. You are correct that using a generic does fix the issue. But you called that "correct". But why, as a code author, should it be my responsibility to understand type theory better than my compiler? Because, according to basic type theory (to the extend that I understand it), TypeScript is allowing an operation that is literally incorrect in the first example. (mutable) Array types must be invariant in the type parameter. It should bitch at us for both examples. And this won't happen with just arrays. It'll happen if you do the same thing with an object with a field. E.g., instead of `Animal[]`, we could have the function take a `{ pet: Animal }`, and pass it a `{ pet: Dog }`, and replace the Dog with a Cat, causing a runtime error for the poor schmoe who thought he still had a Dog.
  - phailhaus 5y ago
    Wild how people can have such different experiences. Typescript is hands-down one of my favorite languages, and I would choose its structural type system over Java's any day. I also use Python at work, and it's like night and day in terms of quality. Every day I have to deal with fundamentally unresolvable issues due to Python's half-baked type hints, when I could be writing much more stable, functional, and maintainable Typescript. Calling it "broken" is complete hyperbole, and no, it's not "worse than Javascript". There's a reason why the entire ecosystem is switching to Typescript, and that's because it is extremely effective at helping teams manage complex stateful applications.
    - FpUser 5y ago
      >"Calling it "broken" is complete hyperbole" Well, when comparing it with strongly typed languages it does look broken for sure.
      - masak 5y ago
        This reply is a good example of how "strongly typed" ends up meaning practically nothing -- except possibly "the kind of type system I prefer". I once attended a talk where the speaker had identified half a dozen axes that papers or projects were calling "strong"/"weak" with relation to type systems. Some were not even consistent with themselves, switching definitions halfway. Type systems are tools, whose formal properties can be described and analyzed in precise detail. Unfortunately, that kind of precision is hard, so semantically empty words like "strong" get used a lot instead. This message is intended to raise awareness about that fact.
        FpUser 5y ago
        Well one can analyze that type systems are till the hell freezes over. I personally do not care as this precise knowledge (assuming it is formalized and exists) is of zero value to me. When I want to walk I just do. I do not dwell on the details of the walking process. Anyways most likely you do know well what I meant. JS vs C++ for example.
  - brundolf 5y ago
    It has holes, mainly because it has to be able to cover existing JavaScript codebases, which for many reasons can be an order of magnitude harder to type than code that's written from the beginning to be statically typed. The biggest holes can be filled via compiler options, and most of the rest can be papered over with the right coding practices (use Maps instead of Records, lint against `any` and type-casting, etc). I haven't encountered the situation you described, but you could probably solve it by making the function generic over TArray extends Animal[]. The rest of what you've said doesn't line up with my experience. TypeScript is an imperfect tool that requires some elbow-grease to fully benefit from. I would prefer a typed language that didn't have to work under its real-world constraints (but not Java, because of null-checking at the very least), but over the years it's caught more bugs for me than I could possibly hope to count.
    - ragnese 5y ago
      Many of the worst holes are indeed because of JavaScript compat. But, not all of them. See some of my other comments in this thread. There's no earthly reason that a `type` should automatically implement Record<string, unknown> and an `interface` shouldn't. That's just dumb and annoying- not necessarily "wrong". However, it's definitely wrong to allow me to pass `const o = {}` into a function that wants `Record<string, string>`. How in the world does TypeScript (with the strict flag set!) think that an empty object is able to return a string value for any arbitrary string key? That's absurd. The issue I raised about arrays isn't just arrays, actually. It happens with object fields as well. See https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... And, the `readonly` keyword has nothing at all to do with JavaScript. Yet, they added this keyword that is completely and utterly useless. To the point that I actually introduced a bug in my own code because I put `readonly` and `Readonly<>` everywhere and expected it to actually help me. It did help me... most of the time. And then it didn't. Because it turns out that you can always take a Readonly value, assign it to a non-Readonly variable and then just mutate the hell out of it, and the compiler won't even bat an eye: https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgJIFt0FcxwEYA2EAYgPanIDeAsAFDIPJQRwAmpIBAnsjOQFzIQWdHmh0AvnTqhIsRCgCyOfETIUa9Rn1KDho8bSm06MLCARhgHZAAs4IVmvIAKHYIzZchEuQCUggBupMCsVHSMyAgcAM5gyKRgttDqgsrezhQAvLzkEYyJyVDqAHQ6yDkAtACMktK00SBxubpomCo+6hXhWgzuyLVG9Y0xpEQlBKQA5m7kZf509o6Zs6R+dCNjEBPTq-NrQA https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgA... That's just... so bad. I don't even know what else to say. Sure, it caught some of my mistakes, but if it won't even catch all of the class of errors that it's supposed to, then I have to basically be just as careful as if I didn't use the feature at all. So, it's not reducing my mental burden at all. If anything, it's just giving us/me a false sense of security and tricking me into thinking that I DON'T need to be as careful.
  - skitter 5y ago
    > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. The same is true for Java arrays. I thought the Liskov substitution principle was tautological when I first heard about it, but it seems like the original designers of Java disagree. Another example (albeit from the standart library, not the typesystem itself) is that if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` because it's immutable - instead of having a superinterface with only non-mutating methods and only implementing that.
    - qsort 5y ago
      > The same is true for Java arrays. This is an unfortunate relic of pre-1.5 Java. The rest of the Collection API types correctly. A type-safe generic alternative is Arrays::setAll. > if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` Again, an historical artifact. `List` is from Java 1.2, you would effectively have to deprecate List<T> for that to work.
      - bobthebuilders 5y ago
        Most of these things in TS are due to historical artifacts too. Namely code patterns that would not work well without them.
    - ragnese 5y ago
      Ugh. You're going to make me defend Java? I'm going to need a drink... First point: Yes, Java's arrays are broken and it offends me greatly. However, in practice, it's much more common to use Lists, which are not broken. In JavaScript/TypeScript "Array" is the equivalent of Java's List, so if you want a dynamically sized, contiguous, collection, you are stuck with the broken thing. Then, the other issue is that, despite my comment's wording, this problem isn't ONLY present in Arrays. It's also a problem with objects, and (I assume) every other non-primitive type. See here: https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... So even a basic object field is broken in TypeScript's type system. What the hell are we supposed to do with this? I do have thoughts and opinions about Java's Collection interfaces, the immutable implementations, etc, but that feels like a whole other topic.
  - Zababa 5y ago
    > TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great.
    - ragnese 5y ago
      I only gave three examples because it was a single Hacker News comment and I didn't think I should keep a running catalog of every single hole/issue/inconsistency that I've encountered in the last year of working on a TypeScript project. I gave a few more examples in other comments in this thread. I can go look at the code comments I wrote in my project and come up with a longer list for you if you like. > You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great. This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? Isn't that... kind of weak? It's like the joke about going to the doctor: "Doctor, my elbow hurts when I do this." "Well, don't do that!" -- If TypeScript advertises a feature, shouldn't that feature, like, actually work?
      - Zababa 5y ago
        > This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? TypeScript is way easier to write, and allows to anotate more stuff. We do have some JS that will stays as JS that's anotated with JSDoc, and it's a worse experience than TS. > Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? I'm defending the usefulness of the tool, but not its marketing. I think the approach of trying to cover every single usage of JS is not the best, and leads to some complex features and weird edge cases like the ones you mentionned. But for typing plain JS, it works very well. I guess we get a lot of value from TS because static typing is easy when your code wasn't that dynamic in the first place. > If TypeScript advertises a feature, shouldn't that feature, like, actually work? Fair point. I honestly don't know what a codebase that doesn't really benefits from TS looks like, but from your description I can see that their claims are a bit too much. I consider TS as part of a campaign from Microsoft trying to regain mindshare and/or control of developers, and thus always took their claims with a grain of salt.
  - Spivak 5y ago
    This seems like such an odd complaint because TS is very loudly purposely unsound. So much of TS is purposely unsound. Like unless you turn on an option disabling it function parameters are contravariant! If you write a function that takes a Dog you can pass an Animal and it will type check!
    - ragnese 5y ago
      It can be as loud and purposely unsound as it wants. That won't stop me from thinking it's a bad tool. The problem is that function parameter variance is still wrong, even with all the strict flags. You just have to wrap the Dog/Animal in an Array or object. Pass in an { pet: Dog } to a function that accepts a { pet: Animal }, and the function can replace your Dog with a Cat, and TypeScript is perfectly happy to let you call `o.pet.bark()` afterwards.
      - Spivak 5y ago
        Like I get you but I genuinely can not thing of a single time I’ve ever hit this problem organically. I can’t even think of a time I’ve ever even though to modify a parameter when writing JS. I think if the language made every type immutable when passed to a function I wouldn’t even notice. It’s not an excuse because where possible I think TS should be stricter but I don’t think stuff like this really gets in the way of it providing me value when writing code.
  - nawgz 5y ago
    Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude > TypeScript is actually so bad that it might have honestly made JavaScript worse I couldn't disagree more. The quality of the programming, the ability to share the mental model more easily with others, the developer experience of autocomplete and declaration files; each of these things is an order of magnitude improved, and the emergent efficiency of individuals and teams follows suit.
    - ragnese 5y ago
      > Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? Well, I literally said that I shit on Java all the time, so yeah... I hate most of Java, and my blood pressure goes up just thinking about the shitty null handling, lack of any concept of immutability, weak as hell type system, and the nightmarish combination of commonplace runtime reflection paired with type-erased generics. > To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude It's not outside my day-to-day. I'm complaining because I'm being bitten by TypeScript's brokenness all the time. If you try to use the advanced TypeScript features, you'll hit all manner of inconsistencies and brokenness, too. I'm sure of it. And if you're only using the very simple typing, are you really doing anything that JSDoc wouldn't do for you? I'm fairly convinced (and I don't mean this in a condescending way) that the main group of devs that really likes TypeScript must have done mostly JavaScript and/or Python before. Because I can't imagine that someone who has spent a couple of years doing C# or C++ or Rust or Swift or even Go would be comfortable with all of the holes in TypeScript's type system.
  - cdelsolar 5y ago
    um, no. TypeScript is fantastic.
  - AlabasterAxe 5y ago
    What's an example of a language that you like?
    - ragnese 5y ago
      I don't know how to say this politely, but I'm afraid to answer this question because I suspect that it will just turn into either a language war or an argument along the lines of "Touché! I can point out a flaw in your favorite language, so obviously TypeScript and LanguageX are exactly equal and you're not allowed to criticize TypeScript!"
  - jeswin 5y ago
    Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. If you've used TypeScript over the years, you'll also see that many major releases catch a set of new bugs in "strict" mode (which used to successfully compile earlier). That's the team fixing some of the issues you mentioned.
    - ragnese 5y ago
      > Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. I understand the point. I just don't think it's a good point. If you tell me that I have a type system, then I'd expect that I could actually lean on it to catch type errors, and I'd expect it's own language features (like `readonly`) to actually do what they claim they do. I would NOT expect someone to add `readonly` to their language, but have it not actually make something a `readonly` type. > The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. I don't buy the argument that something being popular means it's actually good. There's a lot of group-think that goes into things being adopted. Not to mention that it's a Microsoft product and they have zillions of dollars to make sure the editor tools are good, lots of popular JS libraries get TypeScript types added on top, and just plain old PR advertising. And yes, the ability to gradually switch from JS to TS makes TS an easier choice for people who are already working with JS or who are used to JS. But, that doesn't mean that Flow, Elm, ReasonML, ReScript, ClojureScript, PureScript, etc, aren't actually better tools with bigger benefits. It just means that TS got the critical mass mindshare amongst JS devs, and now has the advantage of "everyone else is writing libraries for TS, so if I pick Flow for my project, I won't have as big an ecosystem to pull from."
  - zentropia 5y ago
    I have worked with java in the past and I work with Typescript now. My experience is in reverse. Typescript system it's limited because it has to be compatible with javacript, but working with Algebraic data types is a joy. Instead java is verbose and cumbersome.
- kvathupo 5y ago
  You can't create lock-free data structures in Javascript (as of this comment), but you can do so in Java.
  - Sinidir 5y ago
    Javascript is singlethreaded. No locks and therefore no lockfree datastructures necessary. Even webworkers are only communicated with via copying messages.
    - 5e92cb50239222b 5y ago
      Javascript is singlethreaded … which is why the root comment looks like pure trolling.
- nayuki 5y ago
  JavaScript is most definitely not as fast as Java. Try doing some CPU- and memory-intensive Project Euler problems in both languages and you'll see a several times difference. Java has a much better standard library - abstract data type interfaces, common and fast data structures, I/O facilities, concurrency, and more.
  - romero-jk 5y ago
    True but for a dynamic lang is very close[0] and if your application lives in the Java collection framework(most do) instead of using arrays the performance is even closer. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- tyingq 5y ago
  >Javascript being fast as Java Perhaps for some specific use cases, but certainly not for others. I also suspect moving from a fairly broad "stdlib" and somewhat curated 3rd party packages to the wild west of npm might be a barrier for many.
- kaba0 5y ago
  Well, let’s just add that TruffleJS, a js implementation in java which is part of the Graal project (which is a java interpreter written in java, running on top of java) can achieve comparable speeds to V8 for long running tasks (java’s JIT compilers “turn on” later than js’s because one has to be quite fast as soon as possible while the other has to be really fast but can warm up a bit more). There is a slight trick here, because this java interpreter uses a few special JIT optimizations, but it is still 100% java code (and the clever reuse of the engineering marvel what the JVM is). (Also, do check out the Graal project, its AOT compilation may be the least interesting part! It can even inline python code into js and optimize them together!) Also, Java will soon get virtual threads that will automagically become non-blocking, even if they are written with blocking code (similarly to go). Currently in incubator mode is the Vector API which let’s people write really low level SIMD code that can cleverly query the processors capabilities and will even safely fallback to for loops on ineligible CPUs. FFI will greatly improve also with project Panama, so libs like tensorflow can get better integration into the JVM. And last but not least, Valhalla is coming with value types. Yeah, it won’t happen for a few years still, but once it does, there will hardly be a platform as performant as the JVM. So, while we have heard it plenty of times how java will soon die, I think it’s future is brighter than ever.
- 5e92cb50239222b 5y ago
  In the world of multicore processors, when "Moore's law" has been dead for a decade? Rather, the future of JS outside of browsers doesn't like very bright to me.
btilly 5y ago
I still think that http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st... is one of the best overviews ever of how JavaScript managed to become as fast as traditional compiled languages despite being filled with features to make it slow. What's amazing is that that talk came out several months before V8, the first JavaScript engine that actually used the ideas in that talk. But, of course, that talk was possible because V8 was already under development.
- bestouff 5y ago
  In my experience JS is not as fast as compiled languages.
  - nicoburns 5y ago
    It's not, but it's much closer than other dynamic languages like Python, PHP, Ruby, etc. For numerical code (which avoids allocation) it's often pretty close.
    - hu3 5y ago
      Microbenchmarks I know, but it looks like a magnitude slower than C++ to me: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - nicoburns 5y ago
        I see a factor of 2 in the closest benchmarks. A factor of 4-5 for the middlish ones, and a factor of 10 for the least close. But it's worth noting that a lot of the those C++ examples are making heavy use of SIMD.
        netr0ute 5y ago
        Can you do SIMD with JS? If not, then C++ has the real advantage.
nick_ 5y ago
Every time I read about the insane achievements of a language like JavaScript, I am reminded of how disappointing it was to watch. Maturing JavaScript was a lateral move that cost, what, a billion man-hours? The new cross-plat runtimes and languages we could have had by now if JavaScript didn't have a stranglehold on the available browser-side language space... wow.
- jimbob45 5y ago
  In Eich’s defense, I’ve read before that he originally wanted to make a Scheme dialect instead of JS but was given the finger by higher-ups (and only two weeks to create JS 1.0 to begin with!).
  - hajile 5y ago
    Don't forget that the most complained about feature -- type coercion -- was added later at the explicit request of developers and then left in due to force from Microsoft.
    - dstroot 5y ago
      ..who then created Typescript
  - BrendanEich 5y ago
    https://www.youtube.com/watch?v=krB0enBeSiE https://www.youtube.com/watch?v=krB0enBeSiE ICYMI.
- dntrkv 5y ago
  That's one way to look at it. Another way is to appreciate the fact that we have an open-platform with a standards body that actually works (queue the responses about how it actually _doesn't_ work). I can write an app once and access it from any device and it will work today, and it will work 10 years from now. No other platform has achieved what the web browsers have, so I think we might be doing something right.
- deleted 5y ago
  [deleted]
Skinney 5y ago
This article is a part of a larger series that tries to figure out how Elm's runtime performance can be improved: https://blogg.bekk.no/successes-and-failures-in-optimizing-elms-runtime-performance-c8dc88f4e623 https://blogg.bekk.no/successes-and-failures-in-optimizing-e... I'm the author of the articles, btw.
- PragmaticPulp 5y ago
  Huge thanks for writing all of this up. This is great content.
stephc_int13 5y ago
Is Javascript considered to be fast? It might be close to as fast as it could given the inherent constraints of the language, but I would not call it fast in a general way.
- servytor 5y ago
  Javascript is actually quite fast, on par with Java[0], but it is DOM manipulation that makes it seem so slow. [0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- pantsforbirds 5y ago
  I mean there are a number of benchmarks where Node outperforms java if you look at the benchmark comparison: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... The optimization work that goes into JS is actually really impressive and comes from most of the biggest tech companies.
  - billfruit 5y ago
    As per that list Java is still faster for most of the benchmarks. Massive effort has gone into the JVM too, for the last 20+ years.
    - 5e92cb50239222b 5y ago
      Note also that these numbers include startup time, which is noticeably slower for JVM compared to node. If you're not restarting the server on every request (like the "serverless" nonsense does), a second more or less is not that important. I'd like to see sustained throughput comparison between those two.
      - igouy 5y ago
        For those tiny tiny programs 1/10th of a second JVM startup —- “Wtf kind of benchmark counts the jvm startup time?” https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
xg15 5y ago
I wonder if the browser cache could be used to effectively speed up compilation. I'd imagine that most scripts in websites are static assets, i.e. change rarely and have cache headers that support storage. Couldn't you make use of that to save a compiled version of the script together with the cached file? So when the page is loaded again, scripts are already compiled. Is something like this done in practice?
- onion2k 5y ago
  All browsers have JS byte code caching, but in my experience building web apps it doesn't make a huge difference in the real world. A user will hit a site, download and compile the JS bundle, and then that tab will be kept open for a day or two. They might close the tab and reopen it the following day. In any modern app that uses continuous deployment that means they'll certainly be downloading a new client bundle, and a lot of the time they'll also also get a new vendor bundle (client bundle is the app code, vendor bundle is the NPM packages). I have no doubt code could be split to optimize for fewest changes but JS tooling is complicated enough already so I doubt many sites would bother.
- IainIreland 5y ago
  SpiderMonkey caches pre-parsed bytecode for scripts, which can immediately start executing in the interpreter. (I believe roughly the same is true for other engines. See [1], for example.) The tricky part of caching compiled scripts is that they generally refer to various runtime state. For example, a compiled script might include a check to verify the shape / hidden class of an object. If you want to cache that code, you also have to cache the shape tree. Multiply that out by all the runtime state that is referenced from compiled code, and it's a hard problem. We've talked about simpler mechanisms like caching function hotness / the number of iterations before our profiling data stabilizes, to trigger compilation earlier, but we haven't gotten around to implementing it yet. [1]: https://v8.dev/blog/code-caching-for-devs https://v8.dev/blog/code-caching-for-devs
JohnHaugeland 5y ago
It's always surprising reading articles like this. The hard truth is that Javascript does not actually achieve great performance. It's squarely in the back-middle of the pack. It's just that it's vastly improved versus its old self, and the methodology to get there has been wildly complex. Of the languages tested in the alioth benchmark, more than half outperform node. This should not be surprising, given its lack of basic containers and algorithms, and the inability to make the real thing. (No, an array containing an item and another array isn't a linked list. No, Okasaki containers aren't the real thing. Your complexity guarantees undermine your confident statements.) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- Spivak 5y ago
  So yes but comparing to C++ is probably not the choice that will be presented by most development teams. You’re probably looking more at Python, Ruby, Go, and Java as the main alternatives and JS suddenly starts tending toward the front of the pack.
  - rixed 5y ago
    Yet the title says "great performance", not "great performance compared to python".
  - JohnHaugeland 5y ago
    Go and Java have quite good performance.
eointierney 5y ago
If you can think it you are a great programmer. If you can implement it you are a great engineer. If you can share it you are a scientist.

145 points by EntICOnc 5y ago

Missing "How" from title Pretty cool article. I've been dealing with JS for years without ever thinking too hard about how it all works

ithrow 5y ago

Javascript being fast as Java and coupled with Typescript the future of Java doesn't look very bright.

jetsetgo 5y ago
Please stop. These kind of remarks just brings the worst of out community. JAVA is and will be fine. It's doing better than ever.
ragnese 5y ago
TypeScript is awful. Like, I shit on Java all the time, and I WAY rather work in Java than TypeScript. TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. Record<> is broken/unsound: https://github.com/microsoft/TypeScript/issues/45335 https://github.com/microsoft/TypeScript/issues/45335 Generics are wonky and sometimes wrong: https://github.com/microsoft/TypeScript/issues/31006 https://github.com/microsoft/TypeScript/issues/31006 The `readonly` keyword does absolutely nothing: https://github.com/microsoft/TypeScript/issues/13347 https://github.com/microsoft/TypeScript/issues/13347 Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. TypeScript is actually so bad that it might have honestly made JavaScript worse, if that's even possible.
- deleted 5y ago
  [deleted]
- Scarbutt 5y ago
  It's a shame that something like Typescript is and will dominate the static typing JS ecosystem/industry instead of something simpler and sane like Rescript.
  - ronenlh 5y ago
    Rescript is sane but I wouldn’t all it simpler. It can be really hard to do trivial stuff with it. I felt I had to study OCaml to understand it.
    - quaunaut 5y ago
      I think it gets pretty close, but admittedly its handling of unknown objects is just downright bad. Also, somehow, the tooling for it has one of the best features around(compiling to readable JS), but all other tooling is completely absent, and frankly, bad.
- quaunaut 5y ago
  I generally agree with everything you're saying, after extensive use of Typescript. Its safety guarantees usually only help within extremely tight bounds, and there's surprisingly little that it catches that couldn't be inferred directly. However, a question: > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. --- Separately however, I think it's worth noting that I've been playing with the idea of doing a project in plain Javascript again, to see if I feel any serious productivity losses. - [1]: https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeKBvAUFKpIC4oDk8wBANJlAK4DOE1AMgJbDAQBOARgPYAe+3XADYQ4AO3QBfdOhzQAIlwDmyNBVn4CCxWQoALLjQgc2XANYRR+YG0oRJ02VACCoxgFs4glVqgAfWAjSAPQAVCGYIVAAKrqM1FBcotBsEMCUbKLxYlAABi7ungDaALo52OAQAHQRQegAxonUiHAAJi3UxACSogBm7CktKgAUYgWC1Pj5HoIlAJTIAHyqWKPT1JVgNLpDqOqExGRUtAzMrJy8VjYQErMUKWkZUKue1Pah4VCRMXEJSVD36UyUAA7roEBAAG7scqQKAgAxQRRwKFQZikJ7xQSJZRweLMKAQHisUTtXJTTw5SrOeLwyhQOrZWgQdH4-pcNjxYBgxD41qkhmIDgQBmGVGICGMITgzm6aANTLWOCMUSILg9J5QaiUDiyaqfWryppPNodBAAUSJFlJKAAPFECZaSfFyYIFiNXGt8FE5otlk8PS8NlsdnsiAhDoYTix2Nw+Ngrjc7qlAf6xq8pPVGogWkoJlAtCUVIVdhUNFpDvpDMYzBZLrYJMVMwqoD0uFwVHzTcBun02AMhjnFNRbobBXA2B2TcQLcT2gPc7cgA https://www.typescriptlang.org/play?#code/C4TwDgpgBAwghsKBeK...
  - ragnese 5y ago
    > I don't think this one is true anymore, assuming you type it correctly. I've provided an example[1]. You are correct that using a generic does fix the issue. But you called that "correct". But why, as a code author, should it be my responsibility to understand type theory better than my compiler? Because, according to basic type theory (to the extend that I understand it), TypeScript is allowing an operation that is literally incorrect in the first example. (mutable) Array types must be invariant in the type parameter. It should bitch at us for both examples. And this won't happen with just arrays. It'll happen if you do the same thing with an object with a field. E.g., instead of `Animal[]`, we could have the function take a `{ pet: Animal }`, and pass it a `{ pet: Dog }`, and replace the Dog with a Cat, causing a runtime error for the poor schmoe who thought he still had a Dog.
- phailhaus 5y ago
  Wild how people can have such different experiences. Typescript is hands-down one of my favorite languages, and I would choose its structural type system over Java's any day. I also use Python at work, and it's like night and day in terms of quality. Every day I have to deal with fundamentally unresolvable issues due to Python's half-baked type hints, when I could be writing much more stable, functional, and maintainable Typescript. Calling it "broken" is complete hyperbole, and no, it's not "worse than Javascript". There's a reason why the entire ecosystem is switching to Typescript, and that's because it is extremely effective at helping teams manage complex stateful applications.
  - FpUser 5y ago
    >"Calling it "broken" is complete hyperbole" Well, when comparing it with strongly typed languages it does look broken for sure.
    - masak 5y ago
      This reply is a good example of how "strongly typed" ends up meaning practically nothing -- except possibly "the kind of type system I prefer". I once attended a talk where the speaker had identified half a dozen axes that papers or projects were calling "strong"/"weak" with relation to type systems. Some were not even consistent with themselves, switching definitions halfway. Type systems are tools, whose formal properties can be described and analyzed in precise detail. Unfortunately, that kind of precision is hard, so semantically empty words like "strong" get used a lot instead. This message is intended to raise awareness about that fact.
      - FpUser 5y ago
        Well one can analyze that type systems are till the hell freezes over. I personally do not care as this precise knowledge (assuming it is formalized and exists) is of zero value to me. When I want to walk I just do. I do not dwell on the details of the walking process. Anyways most likely you do know well what I meant. JS vs C++ for example.
- brundolf 5y ago
  It has holes, mainly because it has to be able to cover existing JavaScript codebases, which for many reasons can be an order of magnitude harder to type than code that's written from the beginning to be statically typed. The biggest holes can be filled via compiler options, and most of the rest can be papered over with the right coding practices (use Maps instead of Records, lint against `any` and type-casting, etc). I haven't encountered the situation you described, but you could probably solve it by making the function generic over TArray extends Animal[]. The rest of what you've said doesn't line up with my experience. TypeScript is an imperfect tool that requires some elbow-grease to fully benefit from. I would prefer a typed language that didn't have to work under its real-world constraints (but not Java, because of null-checking at the very least), but over the years it's caught more bugs for me than I could possibly hope to count.
  - ragnese 5y ago
    Many of the worst holes are indeed because of JavaScript compat. But, not all of them. See some of my other comments in this thread. There's no earthly reason that a `type` should automatically implement Record<string, unknown> and an `interface` shouldn't. That's just dumb and annoying- not necessarily "wrong". However, it's definitely wrong to allow me to pass `const o = {}` into a function that wants `Record<string, string>`. How in the world does TypeScript (with the strict flag set!) think that an empty object is able to return a string value for any arbitrary string key? That's absurd. The issue I raised about arrays isn't just arrays, actually. It happens with object fields as well. See https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... And, the `readonly` keyword has nothing at all to do with JavaScript. Yet, they added this keyword that is completely and utterly useless. To the point that I actually introduced a bug in my own code because I put `readonly` and `Readonly<>` everywhere and expected it to actually help me. It did help me... most of the time. And then it didn't. Because it turns out that you can always take a Readonly value, assign it to a non-Readonly variable and then just mutate the hell out of it, and the compiler won't even bat an eye: https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgJIFt0FcxwEYA2EAYgPanIDeAsAFDIPJQRwAmpIBAnsjOQFzIQWdHmh0AvnTqhIsRCgCyOfETIUa9Rn1KDho8bSm06MLCARhgHZAAs4IVmvIAKHYIzZchEuQCUggBupMCsVHSMyAgcAM5gyKRgttDqgsrezhQAvLzkEYyJyVDqAHQ6yDkAtACMktK00SBxubpomCo+6hXhWgzuyLVG9Y0xpEQlBKQA5m7kZf509o6Zs6R+dCNjEBPTq-NrQA https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgA... That's just... so bad. I don't even know what else to say. Sure, it caught some of my mistakes, but if it won't even catch all of the class of errors that it's supposed to, then I have to basically be just as careful as if I didn't use the feature at all. So, it's not reducing my mental burden at all. If anything, it's just giving us/me a false sense of security and tricking me into thinking that I DON'T need to be as careful.
- skitter 5y ago
  > Arrays are covariant in their type param, so I can pass a `Dog[]` into a function that accepts `Animal[]`. If that function adds a `Cat` to the passed array, the compiler is perfectly happy, but we'll see a runtime error. The same is true for Java arrays. I thought the Liskov substitution principle was tautological when I first heard about it, but it seems like the original designers of Java disagree. Another example (albeit from the standart library, not the typesystem itself) is that if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` because it's immutable - instead of having a superinterface with only non-mutating methods and only implementing that.
  - qsort 5y ago
    > The same is true for Java arrays. This is an unfortunate relic of pre-1.5 Java. The rest of the Collection API types correctly. A type-safe generic alternative is Arrays::setAll. > if you try to modify a `List` or similar collection, it may throw an `UnsupportedOperationException` Again, an historical artifact. `List` is from Java 1.2, you would effectively have to deprecate List<T> for that to work.
    - bobthebuilders 5y ago
      Most of these things in TS are due to historical artifacts too. Namely code patterns that would not work well without them.
  - ragnese 5y ago
    Ugh. You're going to make me defend Java? I'm going to need a drink... First point: Yes, Java's arrays are broken and it offends me greatly. However, in practice, it's much more common to use Lists, which are not broken. In JavaScript/TypeScript "Array" is the equivalent of Java's List, so if you want a dynamically sized, contiguous, collection, you are stuck with the broken thing. Then, the other issue is that, despite my comment's wording, this problem isn't ONLY present in Arrays. It's also a problem with objects, and (I assume) every other non-primitive type. See here: https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAtmE0DeBfAsAKFEhgGEwAXaAUwA8zL4ATGBFNTfaT6ZSgewHcAFAEoAXNABuvRA3Z4uC6MF7wIvEJQB0IXgHNBAIh4CDwjl1x5LhKNAAieqrXpM4SVOgznOAIzAAnAGsRcSkZOUUuZVV1LR19Az8g029oS0t8RHg6fwAzMGBKaAAJSAAFSgoveS4AB0rxFg98DLwsnPzCksgHXQi6hvs9Fvx8XIBXeGAyRBVuMCRa8fA6CrJBXnFSiDXhfs5eTXqKAF5oeEp+aFJ1sytRghUICk3uiF7oM+qFY-ELq96IhGeHwqEWy3IlDWGzu+EOx00SWCewA9CilLxkLVEBp-NBEDB6nlKNMQABPaAACzAtVqZIAhEA https://www.typescriptlang.org/play?#code/MYGwhgzhAECCB2BLAt... So even a basic object field is broken in TypeScript's type system. What the hell are we supposed to do with this? I do have thoughts and opinions about Java's Collection interfaces, the immutable implementations, etc, but that feels like a whole other topic.
- Zababa 5y ago
  > TypeScript's type system is so utterly broken that I honestly don't know if my code is ANY more robust than if I had written it in JavaScript. You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great.
  - ragnese 5y ago
    I only gave three examples because it was a single Hacker News comment and I didn't think I should keep a running catalog of every single hole/issue/inconsistency that I've encountered in the last year of working on a TypeScript project. I gave a few more examples in other comments in this thread. I can go look at the code comments I wrote in my project and come up with a longer list for you if you like. > You gave three examples that seem relatively rare. At work we use TypeScript to type a codebase that was mostly plain JavaScript, and we write TypeScript as plain JavaScript. It does very well its job of offering use better tooling and compile-time guarantees. If you consider it as a way to statically-type existing JS codebases, it's good. If you consider it as a language on its own, it's not great. This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? Isn't that... kind of weak? It's like the joke about going to the doctor: "Doctor, my elbow hurts when I do this." "Well, don't do that!" -- If TypeScript advertises a feature, shouldn't that feature, like, actually work?
    - Zababa 5y ago
      > This is a legitimately genuine question: if you're treating TypeScript as just type annotations on an otherwise regular-old-JavaScript codebase, then why are you using TypeScript rather than just JavaScript with JSDoc comments? TypeScript is way easier to write, and allows to anotate more stuff. We do have some JS that will stays as JS that's anotated with JSDoc, and it's a worse experience than TS. > Also, I can't quite tell. Are you defending TypeScript's brokenness by suggesting we just don't use all of its advertised features? I'm defending the usefulness of the tool, but not its marketing. I think the approach of trying to cover every single usage of JS is not the best, and leads to some complex features and weird edge cases like the ones you mentionned. But for typing plain JS, it works very well. I guess we get a lot of value from TS because static typing is easy when your code wasn't that dynamic in the first place. > If TypeScript advertises a feature, shouldn't that feature, like, actually work? Fair point. I honestly don't know what a codebase that doesn't really benefits from TS looks like, but from your description I can see that their claims are a bit too much. I consider TS as part of a campaign from Microsoft trying to regain mindshare and/or control of developers, and thus always took their claims with a grain of salt.
- Spivak 5y ago
  This seems like such an odd complaint because TS is very loudly purposely unsound. So much of TS is purposely unsound. Like unless you turn on an option disabling it function parameters are contravariant! If you write a function that takes a Dog you can pass an Animal and it will type check!
  - ragnese 5y ago
    It can be as loud and purposely unsound as it wants. That won't stop me from thinking it's a bad tool. The problem is that function parameter variance is still wrong, even with all the strict flags. You just have to wrap the Dog/Animal in an Array or object. Pass in an { pet: Dog } to a function that accepts a { pet: Animal }, and the function can replace your Dog with a Cat, and TypeScript is perfectly happy to let you call `o.pet.bark()` afterwards.
    - Spivak 5y ago
      Like I get you but I genuinely can not thing of a single time I’ve ever hit this problem organically. I can’t even think of a time I’ve ever even though to modify a parameter when writing JS. I think if the language made every type immutable when passed to a function I wouldn’t even notice. It’s not an excuse because where possible I think TS should be stricter but I don’t think stuff like this really gets in the way of it providing me value when writing code.
- nawgz 5y ago
  Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude > TypeScript is actually so bad that it might have honestly made JavaScript worse I couldn't disagree more. The quality of the programming, the ability to share the mental model more easily with others, the developer experience of autocomplete and declaration files; each of these things is an order of magnitude improved, and the emergent efficiency of individuals and teams follows suit.
  - ragnese 5y ago
    > Your experience couldn't differ more from mine. I wonder, do you think there are bad parts of Java that if you bought into them you would hate Java and your time with it for? Well, I literally said that I shit on Java all the time, so yeah... I hate most of Java, and my blood pressure goes up just thinking about the shitty null handling, lack of any concept of immutability, weak as hell type system, and the nightmarish combination of commonplace runtime reflection paired with type-erased generics. > To me, each of your examples of brokenness is completely outside the day-to-day which I work in (and honestly my comprehension vis a vis why you would use them), so I can't speak too much to them, but as someone who has gone from untyped JS (obviously) to strictly typing each key of each property in my program, I am finding it pretty funny to see you conclude It's not outside my day-to-day. I'm complaining because I'm being bitten by TypeScript's brokenness all the time. If you try to use the advanced TypeScript features, you'll hit all manner of inconsistencies and brokenness, too. I'm sure of it. And if you're only using the very simple typing, are you really doing anything that JSDoc wouldn't do for you? I'm fairly convinced (and I don't mean this in a condescending way) that the main group of devs that really likes TypeScript must have done mostly JavaScript and/or Python before. Because I can't imagine that someone who has spent a couple of years doing C# or C++ or Rust or Swift or even Go would be comfortable with all of the holes in TypeScript's type system.
- cdelsolar 5y ago
  um, no. TypeScript is fantastic.
- AlabasterAxe 5y ago
  What's an example of a language that you like?
  - ragnese 5y ago
    I don't know how to say this politely, but I'm afraid to answer this question because I suspect that it will just turn into either a language war or an argument along the lines of "Touché! I can point out a flaw in your favorite language, so obviously TypeScript and LanguageX are exactly equal and you're not allowed to criticize TypeScript!"
- jeswin 5y ago
  Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. If you've used TypeScript over the years, you'll also see that many major releases catch a set of new bugs in "strict" mode (which used to successfully compile earlier). That's the team fixing some of the issues you mentioned.
  - ragnese 5y ago
    > Then you don't understand the purpose of TypesScript - which is to retain JS syntax while grabbing the lower hanging benefits of a type system. There are many tools to catch errors (for example, unit tests), and the type system is just one of those tools. I understand the point. I just don't think it's a good point. If you tell me that I have a type system, then I'd expect that I could actually lean on it to catch type errors, and I'd expect it's own language features (like `readonly`) to actually do what they claim they do. I would NOT expect someone to add `readonly` to their language, but have it not actually make something a `readonly` type. > The proof is in the pudding. I've been writing JS (and a bunch of statically typed languages) for over twenty years. Large JS codebases have become possible now thanks to TypeScript (an example is VSCode). If you look at any large JS ecosystem project today, chances are that it's written in TypeScript rather than in vanilla JS. People are adopting it because they see benefits. I don't buy the argument that something being popular means it's actually good. There's a lot of group-think that goes into things being adopted. Not to mention that it's a Microsoft product and they have zillions of dollars to make sure the editor tools are good, lots of popular JS libraries get TypeScript types added on top, and just plain old PR advertising. And yes, the ability to gradually switch from JS to TS makes TS an easier choice for people who are already working with JS or who are used to JS. But, that doesn't mean that Flow, Elm, ReasonML, ReScript, ClojureScript, PureScript, etc, aren't actually better tools with bigger benefits. It just means that TS got the critical mass mindshare amongst JS devs, and now has the advantage of "everyone else is writing libraries for TS, so if I pick Flow for my project, I won't have as big an ecosystem to pull from."
- zentropia 5y ago
  I have worked with java in the past and I work with Typescript now. My experience is in reverse. Typescript system it's limited because it has to be compatible with javacript, but working with Algebraic data types is a joy. Instead java is verbose and cumbersome.
kvathupo 5y ago
You can't create lock-free data structures in Javascript (as of this comment), but you can do so in Java.
- Sinidir 5y ago
  Javascript is singlethreaded. No locks and therefore no lockfree datastructures necessary. Even webworkers are only communicated with via copying messages.
  - 5e92cb50239222b 5y ago
    Javascript is singlethreaded … which is why the root comment looks like pure trolling.
nayuki 5y ago
JavaScript is most definitely not as fast as Java. Try doing some CPU- and memory-intensive Project Euler problems in both languages and you'll see a several times difference. Java has a much better standard library - abstract data type interfaces, common and fast data structures, I/O facilities, concurrency, and more.
- romero-jk 5y ago
  True but for a dynamic lang is very close[0] and if your application lives in the Java collection framework(most do) instead of using arrays the performance is even closer. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
tyingq 5y ago
>Javascript being fast as Java Perhaps for some specific use cases, but certainly not for others. I also suspect moving from a fairly broad "stdlib" and somewhat curated 3rd party packages to the wild west of npm might be a barrier for many.
kaba0 5y ago
Well, let’s just add that TruffleJS, a js implementation in java which is part of the Graal project (which is a java interpreter written in java, running on top of java) can achieve comparable speeds to V8 for long running tasks (java’s JIT compilers “turn on” later than js’s because one has to be quite fast as soon as possible while the other has to be really fast but can warm up a bit more). There is a slight trick here, because this java interpreter uses a few special JIT optimizations, but it is still 100% java code (and the clever reuse of the engineering marvel what the JVM is). (Also, do check out the Graal project, its AOT compilation may be the least interesting part! It can even inline python code into js and optimize them together!) Also, Java will soon get virtual threads that will automagically become non-blocking, even if they are written with blocking code (similarly to go). Currently in incubator mode is the Vector API which let’s people write really low level SIMD code that can cleverly query the processors capabilities and will even safely fallback to for loops on ineligible CPUs. FFI will greatly improve also with project Panama, so libs like tensorflow can get better integration into the JVM. And last but not least, Valhalla is coming with value types. Yeah, it won’t happen for a few years still, but once it does, there will hardly be a platform as performant as the JVM. So, while we have heard it plenty of times how java will soon die, I think it’s future is brighter than ever.
5e92cb50239222b 5y ago
In the world of multicore processors, when "Moore's law" has been dead for a decade? Rather, the future of JS outside of browsers doesn't like very bright to me.

btilly 5y ago

I still think that http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st... is one of the best overviews ever of how JavaScript managed to become as fast as traditional compiled languages despite being filled with features to make it slow. What's amazing is that that talk came out several months before V8, the first JavaScript engine that actually used the ideas in that talk. But, of course, that talk was possible because V8 was already under development.

bestouff 5y ago
In my experience JS is not as fast as compiled languages.
- nicoburns 5y ago
  It's not, but it's much closer than other dynamic languages like Python, PHP, Ruby, etc. For numerical code (which avoids allocation) it's often pretty close.
  - hu3 5y ago
    Microbenchmarks I know, but it looks like a magnitude slower than C++ to me: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - nicoburns 5y ago
      I see a factor of 2 in the closest benchmarks. A factor of 4-5 for the middlish ones, and a factor of 10 for the least close. But it's worth noting that a lot of the those C++ examples are making heavy use of SIMD.
      - netr0ute 5y ago
        Can you do SIMD with JS? If not, then C++ has the real advantage.

nick_ 5y ago

Every time I read about the insane achievements of a language like JavaScript, I am reminded of how disappointing it was to watch. Maturing JavaScript was a lateral move that cost, what, a billion man-hours? The new cross-plat runtimes and languages we could have had by now if JavaScript didn't have a stranglehold on the available browser-side language space... wow.

jimbob45 5y ago
In Eich’s defense, I’ve read before that he originally wanted to make a Scheme dialect instead of JS but was given the finger by higher-ups (and only two weeks to create JS 1.0 to begin with!).
- hajile 5y ago
  Don't forget that the most complained about feature -- type coercion -- was added later at the explicit request of developers and then left in due to force from Microsoft.
  - dstroot 5y ago
    ..who then created Typescript
- BrendanEich 5y ago
  https://www.youtube.com/watch?v=krB0enBeSiE https://www.youtube.com/watch?v=krB0enBeSiE ICYMI.
dntrkv 5y ago
That's one way to look at it. Another way is to appreciate the fact that we have an open-platform with a standards body that actually works (queue the responses about how it actually _doesn't_ work). I can write an app once and access it from any device and it will work today, and it will work 10 years from now. No other platform has achieved what the web browsers have, so I think we might be doing something right.
deleted 5y ago
[deleted]

Skinney 5y ago

This article is a part of a larger series that tries to figure out how Elm's runtime performance can be improved: https://blogg.bekk.no/successes-and-failures-in-optimizing-elms-runtime-performance-c8dc88f4e623 https://blogg.bekk.no/successes-and-failures-in-optimizing-e... I'm the author of the articles, btw.

PragmaticPulp 5y ago
Huge thanks for writing all of this up. This is great content.

stephc_int13 5y ago

Is Javascript considered to be fast? It might be close to as fast as it could given the inherent constraints of the language, but I would not call it fast in a general way.

servytor 5y ago
Javascript is actually quite fast, on par with Java[0], but it is DOM manipulation that makes it seem so slow. [0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
pantsforbirds 5y ago
I mean there are a number of benchmarks where Node outperforms java if you look at the benchmark comparison: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... The optimization work that goes into JS is actually really impressive and comes from most of the biggest tech companies.
- billfruit 5y ago
  As per that list Java is still faster for most of the benchmarks. Massive effort has gone into the JVM too, for the last 20+ years.
  - 5e92cb50239222b 5y ago
    Note also that these numbers include startup time, which is noticeably slower for JVM compared to node. If you're not restarting the server on every request (like the "serverless" nonsense does), a second more or less is not that important. I'd like to see sustained throughput comparison between those two.
    - igouy 5y ago
      For those tiny tiny programs 1/10th of a second JVM startup —- “Wtf kind of benchmark counts the jvm startup time?” https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

xg15 5y ago

I wonder if the browser cache could be used to effectively speed up compilation. I'd imagine that most scripts in websites are static assets, i.e. change rarely and have cache headers that support storage. Couldn't you make use of that to save a compiled version of the script together with the cached file? So when the page is loaded again, scripts are already compiled. Is something like this done in practice?

onion2k 5y ago
All browsers have JS byte code caching, but in my experience building web apps it doesn't make a huge difference in the real world. A user will hit a site, download and compile the JS bundle, and then that tab will be kept open for a day or two. They might close the tab and reopen it the following day. In any modern app that uses continuous deployment that means they'll certainly be downloading a new client bundle, and a lot of the time they'll also also get a new vendor bundle (client bundle is the app code, vendor bundle is the NPM packages). I have no doubt code could be split to optimize for fewest changes but JS tooling is complicated enough already so I doubt many sites would bother.
IainIreland 5y ago
SpiderMonkey caches pre-parsed bytecode for scripts, which can immediately start executing in the interpreter. (I believe roughly the same is true for other engines. See [1], for example.) The tricky part of caching compiled scripts is that they generally refer to various runtime state. For example, a compiled script might include a check to verify the shape / hidden class of an object. If you want to cache that code, you also have to cache the shape tree. Multiply that out by all the runtime state that is referenced from compiled code, and it's a hard problem. We've talked about simpler mechanisms like caching function hotness / the number of iterations before our profiling data stabilizes, to trigger compilation earlier, but we haven't gotten around to implementing it yet. [1]: https://v8.dev/blog/code-caching-for-devs https://v8.dev/blog/code-caching-for-devs

JohnHaugeland 5y ago

It's always surprising reading articles like this. The hard truth is that Javascript does not actually achieve great performance. It's squarely in the back-middle of the pack. It's just that it's vastly improved versus its old self, and the methodology to get there has been wildly complex. Of the languages tested in the alioth benchmark, more than half outperform node. This should not be surprising, given its lack of basic containers and algorithms, and the inability to make the real thing. (No, an array containing an item and another array isn't a linked list. No, Okasaki containers aren't the real thing. Your complexity guarantees undermine your confident statements.) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Spivak 5y ago
So yes but comparing to C++ is probably not the choice that will be presented by most development teams. You’re probably looking more at Python, Ruby, Go, and Java as the main alternatives and JS suddenly starts tending toward the front of the pack.
- rixed 5y ago
  Yet the title says "great performance", not "great performance compared to python".
- JohnHaugeland 5y ago
  Go and Java have quite good performance.

eointierney 5y ago

If you can think it you are a great programmer. If you can implement it you are a great engineer. If you can share it you are a scientist.