Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:left-pad (Score 1) 133

Javascript is usable and okay for client side scripting, but the "why it works the way it does" isn't reasonable in many many cases. You get used to it, you can work with it and it's not too hard to remember the WTFs, but they are there. Seems the WtfJS page is down, but there are many interesting things in js, like weird truth tables and so on. Somebody even proved, that you can convert any script in a series of special characters like [](); without any letter a-z to avoid detection when trying xss.

Comment Re:No other option when using JavaScript. (Score 1) 133

Ah, okay.
I mostly avoid server side js and write client side js with as little libraries as possible. And as little script as possible. Let's be honest, devs love javascript, but users hate it. They do not know, they hate it. They just hate bloated websites, not knowing the actual problem.

Comment Re:And that's a bad thing (Score 1) 133

I know, there are like tens of alternative package managers, trying to fix the mess. I guess each of them has its own flaws, which are of course fixed by the shiny new one created yesterday. It's still not convincing and the problem with thousands of tiny packages remains.

And many "amateur" packages may not guarantee their function either. think of a left-pad, which pads with spaces. Now assume the original author may not wanted to pad it with the correct number of spaces, but pad it to reach a visible lineup. Now he might decide to use tab characters instead of matching spaces for his next release. You used it assuming it will always use a matching number of spaces. now your whole project is broken and you need to debug which package of the hundereds in your project did change the behaviour.
A real standard library does not only have all methods matching, such they can be used together without any problems, but further tries to guarantee a well specified behaviour, which will not change between releases. A "that's what i need" package which is incidentlly adopted by many other projects may not intend to give such guarantees. And i do not have the impression, that people select their packages by checking if they give any promises about future compatiblity.

Comment Re:No other option when using JavaScript. (Score 1) 133

There are a lot of "standard libraries". Decide for one. And then use it. From a single team. Reading their homepage, maybe watching the development, occasionally checking the implementations of things. But ONE BIG LIBRARY, not millions of tiny packages from a lot of different programmers you never heard of.

Comment And that's a bad thing (Score 3, Insightful) 133

Ever installed some nodejs stuff?
You do "npm install" and watch an endless packagelist being downloaded. No, not to the central installation, but into the project. And they are like modules with 5 lines. See for example the "left-pad" thing. Yes, people include other programmers code for 5 lines of a function which you can create without even thinking about it. And they include such 5 line functions from hundereds of different people in their project. Not only one missing package can break millions of builds (see the left-pad example), but one malicious programmer can infect millions of production systems by issuing an update, which includes one malicious line, which loads some external script he will be able to change on demand. Because who re-reads the code of the modules, if he even read it the first place, when adding it because the name and short description seemed to match the requirements.
The node.js ecosystem is fucked up. Working, but still a working mess.

Slashdot Top Deals

"To IBM, 'open' means there is a modicum of interoperability among some of their equipment." -- Harv Masterson