7 ms·

As someone nearly irrationally annoyed by the collective inefficiency of all the Javascript being run in the world, I kind of wish the computational "free lunch

As someone nearly irrationally annoyed by the collective inefficiency of all the Javascript being run in the world, I kind of wish the computational "free lunch" ends sooner than later so the frontend world has to move towards the zero-cost abstractions and techniques being adopted server side. Too bad these hardware engineers are really good at their jobs!

asdkl234890 12y ago
On the other hand John Carmack isn't exactly known for his inefficient code, and yet he's still pushing the limits of hardware.
ajuc 12y ago
Last I've checked java and .net were the most popular server-side languages, and they are all about costly abstractions. Dependency injection, reflection, AbstractFactoryBuilderManagerBean etc. In fact I've yet to see java server-side stacktrace that's less than 100 lines long. Usually it's more like 1000 lines, with a few RMIs inside. On the other hand, the js stacktraces I've seen (mostly hobby projects, so I may be biased) are usually less than 50 lines, often just 10 or so. Not good, but much better.
- lmm 12y ago
  If you compare java projects from the same era as the js projects you'll see similarity; modern java frameworks are a lot more lightweight.
  - TeMPOraL 12y ago
    Ironically, modern JS frameworks are getting more and more enterprise-y.
    - lmm 12y ago
      I think every framework starts off lightweight and becomes heavier as time goes by.
      - TeMPOraL 12y ago
        I'm thinking more about the patterns and structure; e.g. Angular gives off those familiar Enterprise Java vibes...
        jackweirdy 12y ago
        That's because it was made by enterprise Java people moving to JS
    - Turbots 12y ago
      Have you seen ReactJS ? 135Kb (http://facebook.github.io/react/ http://facebook.github.io/react/) Have you seen RiotJS ? Only 6Kb (https://muut.com/riotjs/ https://muut.com/riotjs/) It's all about reiterating over your current library, throwing out what's no longer needed, refactor what is inefficient and only retain what is absolutely needed. React has already grown too much and is becoming too big, while Riot has only taken what was good in React and made it better.. If we keep doing this iteratively, we can keep any framework to a more manageable size
- iopq 12y ago
  Yet Java servers often come out on top in benchmarks, even beating C implementations.
  - tormeh 12y ago
    The JVM is an insane thing, and with clever enough programmers a lot can be done on top of that. Were those Java servers written in standard Java, though? Because it's possible to write pretty low-level code in java if you're willing to compromise on standards compliance. Non-GC'ed, direct memory access is possible, I think.
eva1984 12y ago
The computational "free lunch", IMHO, ends way earlier before Moore's Law hits the wall. Far from a well-established point, and please do correct me if I am wrong, but ever since some point around 2008, the performance gain from CPU upgrade becomes kind of stuck, which sticks to around 10%-15% between generation.
- vlasev 12y ago
  However 10-15% percent per generation is still exponential growth if the cycle length is roughly the same. Just slower.
  - higherpurpose 12y ago
    Since IVB it's been more like 0-5 percent. Intel has decided to focus on reducing power consumption and keeping performance the same, since that's much easier to do now.
    - whyever 12y ago
      It is also much more reasonable, as memory is usually the bottleneck anyway.
  - eleitl 12y ago
    Have you looked at (really) random-access memory bandwidth?
  - marcosdumay 12y ago
    It's not really exponential if the number keeps going down on each generation.
TazeTSchnitzel 12y ago
There are no non-leaky zero-cost abstractions - there is no such thing as a free lunch (hah!). Good abstractions come at a cost. You'll need more CPU power, but it becomes easier to write, read and maintain your code. If performance becomes an issue, rewrite the critical sections to make less use of abstractions. If performance is a massive issue and it's not doable in a high-level language, then don't use a high-level language. If CPU power stagnates, it doesn't matter. There is, and always will be, a place for abstractions, no matter what overhead they have. JavaScript is very efficient in some respects: it trades off speed and memory usage for programmer productivity, safety, security and portability.
- dcsommer 12y ago
  > Good abstractions come at a cost. You'll need more CPU power, but it becomes easier to write, read and maintain your code. I don't believe this has to be true in the future (in fact, I'm not sure I believe it today either). This is a meme that we tell ourselves because we haven't invented clever enough programming languages or abstractions yet. This is exactly what I was referring to in my post. We as an industry would have to solve these problems at a fundamental level. Take for instance manual memory management. People used to think that dynamic languages make this so much easier, but it has become much easier to write GC free programs (see C++11 and Rust). I want to see more efforts in this kind of direction. > JavaScript is very efficient in some respects: it trades off speed and memory usage for programmer productivity, safety, security and portability. I take issue with this. JavaScript it is not a productive language at LOC scale. Security is par for the course. Modern systems languages are no worse or better. Portability I'll grant.

asdkl234890 12y ago

On the other hand John Carmack isn't exactly known for his inefficient code, and yet he's still pushing the limits of hardware.

ajuc 12y ago

Last I've checked java and .net were the most popular server-side languages, and they are all about costly abstractions. Dependency injection, reflection, AbstractFactoryBuilderManagerBean etc. In fact I've yet to see java server-side stacktrace that's less than 100 lines long. Usually it's more like 1000 lines, with a few RMIs inside. On the other hand, the js stacktraces I've seen (mostly hobby projects, so I may be biased) are usually less than 50 lines, often just 10 or so. Not good, but much better.

lmm 12y ago
If you compare java projects from the same era as the js projects you'll see similarity; modern java frameworks are a lot more lightweight.
- TeMPOraL 12y ago
  Ironically, modern JS frameworks are getting more and more enterprise-y.
  - lmm 12y ago
    I think every framework starts off lightweight and becomes heavier as time goes by.
    - TeMPOraL 12y ago
      I'm thinking more about the patterns and structure; e.g. Angular gives off those familiar Enterprise Java vibes...
      - jackweirdy 12y ago
        That's because it was made by enterprise Java people moving to JS
  - Turbots 12y ago
    Have you seen ReactJS ? 135Kb (http://facebook.github.io/react/ http://facebook.github.io/react/) Have you seen RiotJS ? Only 6Kb (https://muut.com/riotjs/ https://muut.com/riotjs/) It's all about reiterating over your current library, throwing out what's no longer needed, refactor what is inefficient and only retain what is absolutely needed. React has already grown too much and is becoming too big, while Riot has only taken what was good in React and made it better.. If we keep doing this iteratively, we can keep any framework to a more manageable size
iopq 12y ago
Yet Java servers often come out on top in benchmarks, even beating C implementations.
- tormeh 12y ago
  The JVM is an insane thing, and with clever enough programmers a lot can be done on top of that. Were those Java servers written in standard Java, though? Because it's possible to write pretty low-level code in java if you're willing to compromise on standards compliance. Non-GC'ed, direct memory access is possible, I think.

eva1984 12y ago

The computational "free lunch", IMHO, ends way earlier before Moore's Law hits the wall. Far from a well-established point, and please do correct me if I am wrong, but ever since some point around 2008, the performance gain from CPU upgrade becomes kind of stuck, which sticks to around 10%-15% between generation.

vlasev 12y ago
However 10-15% percent per generation is still exponential growth if the cycle length is roughly the same. Just slower.
- higherpurpose 12y ago
  Since IVB it's been more like 0-5 percent. Intel has decided to focus on reducing power consumption and keeping performance the same, since that's much easier to do now.
  - whyever 12y ago
    It is also much more reasonable, as memory is usually the bottleneck anyway.
- eleitl 12y ago
  Have you looked at (really) random-access memory bandwidth?
- marcosdumay 12y ago
  It's not really exponential if the number keeps going down on each generation.

TazeTSchnitzel 12y ago

There are no non-leaky zero-cost abstractions - there is no such thing as a free lunch (hah!). Good abstractions come at a cost. You'll need more CPU power, but it becomes easier to write, read and maintain your code. If performance becomes an issue, rewrite the critical sections to make less use of abstractions. If performance is a massive issue and it's not doable in a high-level language, then don't use a high-level language. If CPU power stagnates, it doesn't matter. There is, and always will be, a place for abstractions, no matter what overhead they have. JavaScript is very efficient in some respects: it trades off speed and memory usage for programmer productivity, safety, security and portability.

dcsommer 12y ago
> Good abstractions come at a cost. You'll need more CPU power, but it becomes easier to write, read and maintain your code. I don't believe this has to be true in the future (in fact, I'm not sure I believe it today either). This is a meme that we tell ourselves because we haven't invented clever enough programming languages or abstractions yet. This is exactly what I was referring to in my post. We as an industry would have to solve these problems at a fundamental level. Take for instance manual memory management. People used to think that dynamic languages make this so much easier, but it has become much easier to write GC free programs (see C++11 and Rust). I want to see more efforts in this kind of direction. > JavaScript is very efficient in some respects: it trades off speed and memory usage for programmer productivity, safety, security and portability. I take issue with this. JavaScript it is not a productive language at LOC scale. Security is par for the course. Modern systems languages are no worse or better. Portability I'll grant.