Slashdot Mirror

you could reference a package that does real integers if you need them. obviously it's not ideal - no native operators, at least without implicitly converting to "number" - but having a decent type system like typescript does make it easier to reason about which you're actually dealing with and what the available methods are

I wish I was.

1.2.0 is the latest of 14 releases

https://www.npmjs.com/package/...

These are people who need libraries to left pad a string and to check if something is an array. Technical prowess is not their forte.

You better not be giving up the goods if there's anything remotely resembling an output function in his code.

There's an npm library for that. If he didn't use it, then he's a lost cause, kick him to the curb.

As someone who uses gedit as his primary text editor, this is fairly disastrous news. And as someone who believes in the "the browser, the browser, and nothing but the browser" future, I've been dabbling with browser based editors, mainly CodeMirror.

I'm generally very impressed with CodeMirror (website https://codemirror.net/) used in conjunction with with a Node package at https://www.npmjs.com/package/...

But it's not quite as convenient as gedit (especially if you don't do all your development on a remote server). Does anyone else use CodeMirror, or have suggestions for a better modern editor in the web world?

It's not just the modules themselves; npm is also horrible.

For starters, npm is non-deterministic. Yep, you've read it right: you can install the same packages on two different machines, but if you do it in different order, you can end up with different dependency trees. And yes, despite what the npm maintainers say, it can result in different versions of packages being installed for the same set of version constraints.

Then there are major bugs that have been open for over a year, and can be blocking (as in, no way to install a package) if you happen to be the unlucky one who is affected... but there's no fix. The bug still says "needs repro", despite 80+ comments and 24 upvotes on it, and one of npm developers saying that he "ran into this a few times".

It's not out yet but you can grab the beta with NPM using npm install angular2: https://www.npmjs.com/package/...

Well npm does seem to have caught up on module availability. Though I just checked and the excel parser is actually just a wrapper around the Python library. Also these APIs are pretty skeletal and the documentation is almost non-existent.

Compare: (just picking the modules with high star ratings)
    http://search.cpan.org/~dougw/...
    https://www.npmjs.com/package/...

    http://search.cpan.org/~phred/...
    https://www.npmjs.com/package/...

Well npm does seem to have caught up on module availability. Though I just checked and the excel parser is actually just a wrapper around the Python library. Also these APIs are pretty skeletal and the documentation is almost non-existent.

Compare: (just picking the modules with high star ratings)
    http://search.cpan.org/~dougw/...
    https://www.npmjs.com/package/...

    http://search.cpan.org/~phred/...
    https://www.npmjs.com/package/...

Sure, I know CPAN, but you can get all that plus vastly superior performance with node js. And there's 10x more packages on npm than CPAN (according to modulecounts.com) and it's clearly the most active.

Look at the packages:
https://www.npmjs.com/

It's not more difficult to install a package (npm install ModuleName) and you get all kinds of fancy tools to make development easier. You can use frameworks like express js to quickly build apps, but with just node alone it's trivial to create pretty much anything. It's javascript so there are things that suck (like dates) but overall it's pretty good, and much easier to learn than perl.

I'm not saying you should ditch perl, but there's no compelling reason to use it unless one has invested time already in becoming a perl expert.

With Javascript and node.js, you declare the name of some external package you'll use and it constantly fetches the newest version, with the newest bugs, directly onto production.

Why would you even consider doing it. When you declare your dependencies in your package.json, you can lock the major or minor version or all. If you don't, you will get the latest applicable version when you fetch your dependencies. If you want to lock your versions before deploying (which any sane developer would do), you'd use npm's shrinkwrap feature https://docs.npmjs.com/cli/shr...

You never see, never mind test, the code before it runs on your production systems.

What does testing have anything to do with Javascript/node? There's plenty of test frameworks out there for it, and the vast majority of dependencies include a bunch of tests, which are run before being able to publish them.

We saw a similar problem last week - somebody removed their package from the repository and that broke everyone's production systems.

I don't understand why this would break a production system. If you remove a package from maven's repo, you won't be able to fetch it either, same thing here. If you fetch your dependencies from a third party on a production system, you're an idiot, and that's applicable to any language or frameworks.

The problem with camp #1 is they, in many cases, utterly fail to provide the tools necessary for people to do their jobs efficiently, which is why people want to bring their own.

Mind you, it's not necessarily the boots on the ground (but rather the generals) for camp #1 causing the problem, but is is camp #1's problem.

(by the way, I have been in both camps in various parts of my career)

A perfect example, as a software developer I occasionally need to read documentation on how the libraries I use work.

Occasionally, an open source software offering provides video demos of the use cases instead of static HTML. Often when this happens, they host their videos on YouTube and embed them in their local website. npm is an example.

This combination means that I can't watch the documentation for npm, as our corporate firewall policy forbids it; however, I can

• Watch the same video on my personal cell phone (uncompensated by the company of course)
• Ssh to any VPS, download it there, and scp it back into the company.
• Work from home and watch it on my personal computers.
• Set up a encrypted personal hotspot with my phone and connect my personal laptop to view it at work.
• Log into company provided AWS systems and watch it from there, enabling remote desktop to watch it in office.
• Log into company provided AWS systems, download it, and the ssh it back to my desktop.

Of course, I can't admit to doing any of the above; but, that is a small concern when I must report to management that I've learned npm. They even suggest workarounds, as the company's IT department has eventually become so independent of the development department that they are not concerned if developers can work effectively. The IT department's motto is "we give you resources, it's up to you to figure out how to be effective with them." If we don't make deadlines, they don't care. They're not winners when we hit the deadlines, they are winners when they prove policy enforcement by denying requests.

I've even seen sites blocked by their web proxy for the reason "IT / Technology" as if developers shouldn't be concerned with such things.

The BYOD crowd is really not about the toys, it's about a last ditch effort to get resources by alternative means. The BYOD crowd plays with a different set of values, valuing being effective over paying an inordinate amount of overhead attempting to have check marks in everyone's checklists.

I've worked on systems where the latest version of available build tools (apache maven) were two years old, because someone was worried a trojan might be included in the tool, so you couldn't internally distribute until after it was approved, which required an analysis of the code, which would never be performed more than three times since they can't afford to hire people to just sit around and read the source code of all the corporate mandated software products.

Node is fast supposedly because it uses low-overhead single-threaded asynchronous calls, instead of threading. So if that is such a fast paradigm, why don't we build a low-overhead single-threaded asynchronous Java or Python or C# engine? Eg: Node.java, Node.cs, and Node.py?

There is no reason not to build a single-threaded, asynchronous web server in the language of your choice. I'd be surprised if there aren't a bunch of them out there by now.

Node has the advantage of using the same language for both client and server side code. Since JavaScript is the de facto standard for in-browser code, any other language pretty much requires a translation step.

Node also has a robust community and a lot of framework and library packages.