At first I thought the comment was actually serious and couldn't believe it before I read the whole article. Thanks for pointing this out
Node.js: Some quick optimization advice
21–30 of 75 posts
Re: Node.js: Some quick optimization advice
#22If you're wondering why comments are a factor at all, and aren't just discarded by the lexer, remember that comments in JS are preserved and available to things like `Function.prototype.toString()`. I've seen this used to do evil multiline string support a few times. Slap the multiline string or template into a comment inside a function and then have another function that toStrings it and strips the boilerplate. This…
> I've seen this used to do evil multiline string support a few times.
Love me some FOAM: https://github.com/foam-framework/foam/blob/master/apps/todo....
Re: Node.js: Some quick optimization advice
#23Posted that yesterday, didn't get much traction. Whenever I begin to convince myself that JS and Node are actually fine languages / environments to code on, some weird edge case like this pops up. Not entirely sure if it's just its popularity, which is bound to expose its rough corners, or if it's fundamentally bad designed (written in 10 days in the late 90's, etc)
I've had the same experience with node, but normally there aren't that many problems with V8 or the language itself. Most of the rough corners seem to be in node's core libraries.
IMO this is what we need:
* a better designed standard library. Maybe more like Dart's[1] - we already have Bluebird as the de-facto replacement for callbacks - all we need now are something like Dart's streams to fix the built in quirky streams.
* built from the ground up with optional types i.e. TypeScript or Flow (eliminates most of JS's type-related quirks while preserving most of the dynamism and duck typing and being very helpful when the time comes to refactor)
Now that typescript has support for type definitions inside node_modules[2] there are no barriers remaining to do this. node + V8 + typescript can provide a development experience that matches Dart (exceeds it in some cases, e.g. REPL) without throwing away the entire existing JS ecosystem in the process.
[1]: https://api.dartlang.org/1.12.1/dart-async/dart-async-librar...
[2]: https://github.com/DefinitelyTyped/tsd/issues/208
p.s. [2] can actually detect some situations in which there would be problems when multiple library versions coexist together (e.g. when you pass instances that come from library v3 to a function of library v2, explained in detail at https://news.ycombinator.com/item?id=8213273). However if the interfaces are structurally satisfied, the compiler will not complain. As a result I'm pretty sure that its possible to write a tool that detects semver violation based on .d.ts files (similar to what Elm does) or suggest the exact amount of version number increment by comparing the definition files
Re: Node.js: Some quick optimization advice
#24Posted that yesterday, didn't get much traction. Whenever I begin to convince myself that JS and Node are actually fine languages / environments to code on, some weird edge case like this pops up. Not entirely sure if it's just its popularity, which is bound to expose its rough corners, or if it's fundamentally bad designed (written in 10 days in the late 90's, etc)
[deleted]
Re: Node.js: Some quick optimization advice
#25So, is this is a point in favor of not commenting your Javascript code or using inline docs? Historically, I preferred to use inline JsDoc style comments as the source of documentation for my public APIs. Recently though, I decided that I didn't like them and that I wanted something better. I was hoping to find some tool that parses my JS to AST, figures out what was being exported (e.g. what was public) and writes a…
no, just minimize your code prior to production, and that'll rip out the comments. That's been best practice for years.
No one minifies NodeJS code. The reduced file-size of minified JS is irrelevant on the server.
Re: Node.js: Some quick optimization advice
#26So, is this is a point in favor of not commenting your Javascript code or using inline docs? Historically, I preferred to use inline JsDoc style comments as the source of documentation for my public APIs. Recently though, I decided that I didn't like them and that I wanted something better. I was hoping to find some tool that parses my JS to AST, figures out what was being exported (e.g. what was public) and writes a…
no, just minimize your code prior to production, and that'll rip out the comments. That's been best practice for years.
> just minimize your code prior to production
In frontend JS code sure, but minifying backend node.js code is certainly not "best practice".
Re: Node.js: Some quick optimization advice
#27This is a microbenchmark. It's a tight loop that calls the function 500 million times. The function itself just adds two numbers. It's pretty close to the best possible improvement for inlining a function. If that's what your program does, and it's a big part of what your program does, then inlining it may be a big performance win. Even then, addressing this may not be a worthwhile tradeoff. Even then, as others have…
I think the oddity here is that the function length takes the comments into account.
Re: Node.js: Some quick optimization advice
#28If you're wondering why comments are a factor at all, and aren't just discarded by the lexer, remember that comments in JS are preserved and available to things like `Function.prototype.toString()`. I've seen this used to do evil multiline string support a few times. Slap the multiline string or template into a comment inside a function and then have another function that toStrings it and strips the boilerplate. This…
> I've seen this used to do evil multiline string support a few times. Love me some FOAM: https://github.com/foam-framework/foam/blob/master/apps/todo... .
That might be one of the scariest things I've looked at all day.
Re: Node.js: Some quick optimization advice
#29Earlier quoted context omitted.
> I've seen this used to do evil multiline string support a few times. Love me some FOAM: https://github.com/foam-framework/foam/blob/master/apps/todo... .
That might be one of the scariest things I've looked at all day.
It only gets better. https://github.com/foam-framework/foam/blob/master/apps/todo...
Re: Node.js: Some quick optimization advice
#30This is a good thing to raise awareness of, but the solution is poor advice.
Asking developers to remember the "gotcha" of 600 characters is not really viable. Instead, if this is important to you, consider the addition of minification or comment stripping to your production deployment process. Minification will also make the variable names and syntax use shorter, saving you further precious characters.
Learn the problem, but automate the solution.