Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node v4.0.0

nodejs.org

Post reply on HN
Print view View original

261–270 of 277 posts

Re: Node v4.0.0

#261

Post by AdieuToLogic »

pluma wrote: post #215
AdieuToLogic wrote: post #203

Earlier quoted context omitted.

> ... Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment... Actually, no, it didn't. JavaScript was first introduced "on the server side" about 20 years ago in the Netscape web server[1]. We learn from history that we learn nothing from history…

The JS of 2009 was an entirely different language from the JS Netscape originally created. Plus Netscape's web server was an evolutionary dead end and a proprietary closed-source product. Node was in part influenced by CommonJS, which tried to unify the various competing but relatively obscure (mostly non-browser) JS environments. To say that it learned nothing from the history of SSJS (or JS environments in general)…

With utmost respect, I respond to each point you mention below.

  The JS of 2009 was an entirely different language
  from the JS Netscape originally created. Plus
  Netscape's web server was an evolutionary dead end
  and a proprietary closed-source product.
The reason I cited Netscape's server was to unequivocally show that NodeJS did not introduce JavaScript to "a new environment" as the GP stated. Why previous efforts failed to gain traction or if it is even a good idea to use JavaScript to define server-side logic is left as an exercise to the reader.

  Node was in part influenced by CommonJS, which
  tried to unify the various competing but
  relatively obscure (mostly non-browser) JS
  environments. To say that it learned nothing
  from the history of SSJS (or JS environments
  in general) is, frankly, wrong.
It would seem we have differing perspectives of history. CommonJS was started in 2009[1], the same year as NodeJS[2]. The lessons of history I implied regarded attempts to use JavaScript as a server-side solution over the past 20-ish years. While you make the distinction:

  Node lets you write application servers,
  Netscape's SSJS effectively was more like
  Rhino-meets-JSP or maybe GWT (i.e. the heavy
  lifting was apparently implemented in Java,
  not JS).
I suggest that this is irrelevant, as the details of how the JavaScript logic is executed is orthogonal from the fact that systems such as these use JavaScript to define behaviour itself. The fact remains that there have been more than one previous project/offering/effort which had JavaScript as a key component. IMHO, it behooves interested parties to do whatever postmortem examinations possible before committing to the same or significantly similar path.

1 - https://en.wikipedia.org/wiki/CommonJS

2 - https://en.wikipedia.org/wiki/Node.js

Re: Node v4.0.0

#262

Post by AdieuToLogic »

stdbrouw wrote: post #227
AdieuToLogic wrote: post #203

Earlier quoted context omitted.

> ... Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment... Actually, no, it didn't. JavaScript was first introduced "on the server side" about 20 years ago in the Netscape web server[1]. We learn from history that we learn nothing from history…

Sure, and after that we had Rhino and Adobe has been using JavaScript for a very long time as a scripting language (ExtendScript) and there are probably many other examples of JavaScript outside of a browser. But I don't see what that has to do with untog's main point.

I saw "untog"'s post as having two points, to which I responded to the former. You identify the latter point as being the main one and that's perfectly fine.

Just different importance discerned from the same post IMHO.

Re: Node v4.0.0

#263

Post by scottohara_ »

actualprogram wrote: post #77
saghul wrote: post #42

Earlier quoted context omitted.

No software is bug free, but AFAIK Node v4 was very thoroughly tested in a vast array of platforms and configurations, which provides certain degree of certainty, when talking about stability. At any rate, if you ran into issues with 0.12, the best you can do is give 4.0 a go and report issues!

If you're concerned with stability, the best thing you can do is wait for the LTS release to come off the 4 branch. A quick glance at outstanding issues will show a number of integration bugs are still outstanding, and the new v8 was landed only a few days previously - incompatibilities with new versions of v8 can take a while to surface in node. It's important to remember that semver makes no promises about stabilit…

Just curious..where are you tracking these outstanding issues?

In GitHub issues (for nodejs/node), I can see the 5.0.0 milestone has 5 open/1 closed issue; but my understanding is that the LTS release will be cut from 4.x; and 5.x is for rapid iteration post-LTS (i.e. changes that would have previously gone to io.js).

I recall reading that the 4.x LTS release is planned for a couple of weeks after 4.0.0 (which should be around the end of September, or early October).

I'm interested in tracking progress in the lead up to LTS, as this is when the node Homebrew formula is expected to bump from 0.12.x -> 4.x.

Re: Node v4.0.0

#264

Post by hexchain »

grandalf wrote: post #102
blowski wrote: post #28

Earlier quoted context omitted.

It promises a stable future, so let's say I'm being cautiously optimistic.

> It promises a stable future, so let's say I'm being cautiously optimistic. This doesn't make sense in light of your initial comment. One of the big goals of IO was to move to semver and address unpredictability/instability that you describe. If anything, the merging of Node and IO should give you confidence that project governance will be on the right track moving forward. Also, when you consider the advancements i…

> One of the big goals of IO was to move to semver

And of course they failed right from the start. From semver.org: Version 1.0.0 defines the public API.

So their jumping to 4.0.0 from 0.x.x means they don't care to have a public API!

Re: Node v4.0.0

#265

Post by pluma »

tomphoolery wrote: post #153
mark_l_watson wrote: post #91

ES6 support is nice, especially if there is no performance hits for using ES6 features. I slightly prefer Typescript, but the extra language features in ES6 really make JavaScript development more fun for me. Thanks to the newly re-combined Node team!

Good news for you: ES2016 will support optional type annotations, clearly inspired by TypeScript. The idea is we shouldn't need a damn transpiler just to get the features most people want out of a language...

SoundScript is on track then? I thought it was just proposed (i.e. highly experimental).

Re: Node v4.0.0

#266

Post by pluma »

msoad wrote: post #50
codecurve wrote: post #43

Earlier quoted context omitted.

You'll be able to achieve that behaviour when node also supports destructuring. import { readFile, writeFile } from 'fs'; import { clone } from 'lodash';

oops I forgot the braces! ok then, it's cool. I'm happy it does resolving to node_modules and all that automatically.

It's just syntactic sugar for `require`, mostly. The import mechanism should behave the same.

Re: Node v4.0.0

#267

Post by pluma »

jkrems wrote: post #189
msoad wrote: post #32

When node supports `import` how you'll import node modules? I hope it works like this import {readFile} from 'fs'; import {clone} from 'lodash'; rather than explicitly providing "correct" URL to the modules. EDIT: edited the syntax.

Adding support for `import` will be a huge breaking change unless all existing packages have to opt-into it somehow. I don't think anybody has a good plan for this yet, apart from treating it as syntactic sugar for CommonJS.

The only problem are "default exports", i.e. overriding `module.exports` directly. In Node the exported names are just properties of the `module.exports` object but in ES6 the named exports are entirely separate from the default export. IIRC module.exports was not actually part of CommonJS although nowadays most people just use that word to mean "whatever Node does".

Re: Node v4.0.0

#268

Post by pluma »

antouank wrote: post #103
ihsw wrote: post #8

Node on Docker Hub needs a new tag. https://hub.docker.com/_/node/

Get an alpine based one, it has 10x smaller size. I made one with npm v3 and node v4.0.0 https://hub.docker.com/r/antouank/alp-node/

Thanks to docker's image layering, using a non-Ubuntu image may actually be "bigger" if you already use other Ubuntu images.

Re: Node v4.0.0

#269

Post by pluma »

mark_sz wrote: post #208

I remember when many people were complaining about PHP - lack of progress, inconsistency etc. Now look what's happened to Node just in 6 years. And this is just the beginning.

I have no idea what you're trying to say.

PHP stalled in pre-6.0 land and then jumped straight to 7.0 because the release was just not going to happen. The closest thing in Node I can think of is ES4 (which failed, resulting in a jump to 5 and ActionScript diverging further).

Node stalled in pre-1.0 land with what was effectively a feature freeze before io.js split off and jumped to 1.0. Io then went on a regular release schedule strictly following semver leading to 2.0 and then 3.0. These aren't backwards incompatible in the sense that PHP 5 is to 4 or Python 3 is to 2 -- most code will likely still work; they mostly propagated breaking changes caused by updates to the underlying V8 engine, breaking some native extensions. The "jump" from 0.12 to 4.0 for Node is because instead of merging io.js back into Node, Node 0.12 was merged into io.js and io.js became the new Node 4.

Re: Node v4.0.0

#270

Post by pluma »

haberman wrote: post #207
secoif wrote: post #154

Earlier quoted context omitted.

If you'd used leveldb from the beginning you wouldn't have this problem as it will happily work on the server and in the browser https://www.npmjs.com/package/level-js

Yes I see that. But if IndexedDB were supported on Node I also would not have this problem. So the question is, why can't node just support IndexedDB (which is formally specified in a standards document) instead of inventing an extremely similar but incompatible api?

Because IndexedDB is a W3C spec[0] intended for web browsers and LevelDB is a third-party npm module[1].

Node is just a JS environment. Implementing IndexedDB is as much out of scope as implementing XHR[2] or the File API[3]. In fact it provides the building blocks developers to implement any of these on top of Node should they need to (like node-fetch[4] implementing the Fetch API[5] for isomorphic apps).

[0]: http://www.w3.org/TR/IndexedDB/

[1]: http://leveldb.org/

[2]: https://xhr.spec.whatwg.org/

[3]: http://www.w3.org/TR/FileAPI/

[4]: https://www.npmjs.com/package/node-fetch

[5]: https://fetch.spec.whatwg.org/

Post reply on HN