271–277 of 277 posts
0.12.7 -> 4.0.0 Best versioning convention ever :)
So it's really 0.11.x -> 1.x -> 2.x -> 3.x -> 4.0.0. Except that 1.x, 2.x and 3.x weren't called "Node" at the time because Joyent owns the trademark and went on to release their own 0.x release(s) until the merge happened.
Earlier quoted context omitted.
Exactly. I don't think Node is a good fit for monolithic CRUD apps. These are already solved problems in various other languages. Instead Node lets you compose small purpose-built modules.
Now out only problem is how to build decoupled/distributed micro services. I'd argue only Erlang and Elixir are going to survive into the multi core multi server future, but that would be little more than a slightly educated opinion unless I take the time to write a very large explanation with cited references. I don't have time for that this week.
I think what's holding Erlang back is mostly its rather obscure syntax. Only a mother could love that.
Earlier quoted context omitted.
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 fa…
Node is for writing small standalone services. Netscape's SSJS was for creating dynamic web pages -- just like CGI scripts or (at the time) PHP.
SSJS may be considered prior art for "JS on the server" but it's barely recognizable. As far as I can tell the execution was entirely synchronous; but Node is defined by its evented -- and therefore asynchronous -- I/O. It's a data point for comparison but it's not a good lesson to learn from, other than what not to do.
A lot of the shortcomings of Node come from the limitations of JS at the time. Callbacks and streams (arguably two of the biggest issues with Node) are a result of Node being asynchronous. At the time, event listeners and callbacks were the best tool JS offered and the best thing the JS community had.
I can only imagine you're trying to say that Node should have taken more inspiration from other languages that solve problems better (like gradual typing, or the Maybe monad or the actor model). But none of this has anything to do with Netscape's SSJS.
You explicitly point out Netscape's SSJS as a part of history Node should have learned from. What specifically do you think Node should have learned from it? Are you just trying to say "SSJS is a bad idea (because Netscape's SSJS was bad) and shouldn't have been attempted again, even in an entirely different way"?
[0]: http://stackoverflow.com/questions/18350910/netscape-enterpr...
Earlier quoted context omitted.
Why out of scope? It's a DB api that has no browser/ui dependencies. I see that the levelDB implementation you pointed to can use a backend that uses IndexedDB. So theoretically this levelDB Api could provide an Api that work across both browser and server. But argh. IndexedDB is a standardized api. It has a usable open source implementation in WebKit. Why not just go with that?? Why create a different API that does…
LevelDB is the db behind IndexedDB.
Earlier quoted context omitted.
> 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!
See https://github.com/nodejs/node/blob/master/CHANGELOG.md and search for 1.0.0
Earlier quoted context omitted.
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:…
Because there is nothing about the problem domains (indexed key/value store, asynchronous web requests, filesystem I/O) that are specific to web browsers.
If a problem domain is common across browsers and pure-JS environments, then it should follow that there can be common APIs. If some part of the API is necessarily specific to one or the other, then ideally these differences should be localized to small parts of the API.
Earlier quoted context omitted.
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:…
This just begs the question. The question is, what about IndexedDB, XHR, the File API, etc. make them unsuitable for pure-JS environments? Because there is nothing about the problem domains (indexed key/value store, asynchronous web requests, filesystem I/O) that are specific to web browsers. If a problem domain is common across browsers and pure-JS environments, then it should follow that there can be common APIs. I…
JS in the browser needs to be sandboxed by default and has to handle concerns like cross-origin policies and interactively seeking user permissions. It also has some fairly browser-specific singletons (e.g. a shared global cookie storage).
The equivalent built-in node APIs are much more low-level, allowing developers to use abstractions that are useful in their problem domain.
Having an IndexedDB implementation in node core would be an incredibly pointless effort (most apps out there won't use it) and bring with it several complications (e.g. pluggable storage backends and concurrency conflicts if you want multiple node processes to share the same database). Plus it would mean the Node Foundation would have to get involved in the standardization process to make its concerns heard and likely introduces concerns that are irrelevant to everyone else (i.e. browser vendors).
Don't forget that Node is not a web framework. It's a JS runtime environment. It is primarily used for things that talk over the web or that generate content for the web, but it's not at all unreasonable to implement other things in it (e.g. mail servers). The web specs carry a lot of overhead that is simply unnecessary for most node applications even if it is perfectly necessary in browsers.
The only spec I can think of that I'd like to see in node is the Fetch API and for that we have node-fetch, which just wraps node's low-level http module.
What I'm trying to say is that node doesn't need these high-level APIs because it can give you the low-level APIs to implement them with. Browsers can't do this, so they need to work at an entirely different layer of abstraction. Plus node allows you to easily include native extensions whereas in the browser you can't have that (except for NaCl).