161–170 of 277 posts
Earlier quoted context omitted.
- language + environment + ecosystem - language + environment + ecosystem - language + environment + ecosystem
In that case "Node" is 20 years old, and "Ruby" (for web development) is 11 years old.
It's fair to say Ruby didn't take off until 1.8 which came out in 2003, but how in any way is Node 20 years old?
Earlier quoted context omitted.
I use Java/Spring, Ruby, and Node.js in production, and Node.js is by far the hardest to stay up to date with without introducing major problems. The only framework I have used that is harder to update is Finagle. It's not just Node itself to blame. There seems to be a culture of breaking things in the Node.js ecosystem. Breaking changes in third-party libraries are common. I have to specify exact dependency versions…
have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong. That's where semantic versioning comes in. Most libraries follow it - if the major version number changes, it's a breaking change. If it doesn't, you're safe to upgrade.
There are some major libraries that are on version 15 or greater... there's nothing good from a user's perspective about having a library they use do a major breaking release every other month.
What's worse is many libraries take advantage of "it's the wild west until 1.0" rule in semver and simple never release a 1.0.
Earlier quoted context omitted.
Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). I'd agree with your first paragraph in that Node is a bit lower-level out of the box and probably takes more effort to get started building a web-app, but I think…
> Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack). One of my main use cases for Node is Zombie, and that required io.js after v3. No mainstream PHP, Ruby or Python application has required a different interpreter…
Earlier quoted context omitted.
Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with th…
*incompatible
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.
You'll be able to achieve that behaviour when node also supports destructuring. import { readFile, writeFile } from 'fs'; import { clone } from 'lodash';
Earlier quoted context omitted.
When you say languages, do you really mean frameworks? It seems like languages are fairly general purpose and don't go out of their way to tell you how to build your application. Node is more in the "language" camp than the "framework" camp, and there are bunch of frameworks on top of it that give you the structure you're looking for.
Anything. I'm a pragmatic developer who just wants solutions that help me pay the bills. It's precisely for that reason that Node has been a problem for me - it's caused much more than its fair share of headaches, when compared to Ruby, Python, PHP, Bash, Go. Perhaps using a framework would make things easier, but I'm reticent to rely on it in the main part of the project when it causes so many problems just in the s…
Having said that the IO split has been a royal PITA. We got pegged to Node 10.x because JSDom only supports IO and Jest (which is what we wanted JSDom for) only supports Node :-P. I've been waiting a year for it to get cleared up.
It sounds like we made the right choice, though, because in this thread the people who are complaining about Node seem to be the ones who tried switching back and forth between IO and Node. There is actually only one bug in Node that has impacted me (related to the way connections are shut down) and it isn't fixed yet in master so not upgrading hasn't really impacted us. We just have to live without some of the ES6 features.
Personally, I'm a big fan of Go (old C++ programmer). We started using it a little over 2 years ago. The language definition has changed in that time, so I wouldn't call it stable ;-) The core libraries are rock solid, though. We barely use any 3rd party libraries (I think we use 2) so it's not really fair to compare that with other languages.
Although we have a fair amount of python in our shop, I don't seem to work on those projects very much (a month here and there). I can't say too much about it other than our Python code breaks due to 3rd party libraries more often than any of our other code. However, I think this is probably due to injudicious choices for our 3rd party libraries ;-)
Overall, I would say that my experiences don't match yours, but I wonder if it's because we never tried moving to IO.
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.
I wonder how that would work asynchronously. Or when the file is used from both the browser and node.
The io.js fork and subsequent merge back into Node.js, including the birth of the Node Foundation, has been one of the best examples of the power of open source I have ever seen in action. The situation went from bad, to worse, to the best possible outcome, and that's remarkable to say the least. Congratulations to everyone involved and thank you for the hard work.
As somebody who uses Node only at the periphery of my role (for things like the Zombie browser, and SASS parsing) the massive instability has put me off from relying on it for anything core. Documentation is quickly out of date, libraries seem to have incompatibilities which only become obvious when they don't work, there's no 'recommended' approach for even basic tasks. I won't pretend I'm speaking for everyone, as…
so now which apt repository to I use for node going forward?
Wget the tarball and tar -C /usr/local --strip-components 1 -xvf
Earlier quoted context omitted.
...all you have to do is re-install it with the GUI installer and you're good to go And fix all the incompatible changes in your own code.
It's backwards compatible and works fine from what I see