De-facto closed source: the case for understandable software

However developing robust software is possible in JS, the same way it was possible in PHP. You just need to take some time to vet dependencies a bit better and not use every fad when it surfaces. Common sense and experience help a lot. But it's incredible what can be built with modern toolchains and how maintainable it can be. Don't let the anti-JS feeling scare you from trying React / Vue /..., just don't forget that state management, separation of concerns and similar concepts are still valid.

Or they should do what they appear to be incapable of which is to provide certification and verification of certain packages. If people really need a lib for inarray then npm should maintain and certify it.

It should not be difficult for npm to raise the funds needed to do that.

the issue is NPM. NPM is a bad package manager. A package manager that allows duplicates version of the same dependency is broken to begin with. People complain that fetching react-native results in hundreds of packages installed on their computers. How many freaking dupes? off course nobody is going to audit all that crap. Conflicts should be resolved upstream, which would lead to more stable packages to begin with.

NPM was developed by people who were clueless about package management and now are profiting directly from that shit-show, and even Node.js creator went on recording saying tying it to NPM was a mistake.

Whereas with Javascript if you find a bug or something you want added to the core library then you need to pay millions of dollars to join ECMA. How can you find competent developers to work in an ecosystem with that kind of governance? You can't, which is why we are where we are now.

Even if with respect to the implementations, if you file a bug with any of the major browser vendors then you'll probably die of old age before the ticket is even triaged, let alone fixed.

To me this illustrates a fundamental problem that JS has to deal with that is virtually unique in the programming language space: multiple browsers across multiple browser versions. It is incredibly difficult to get all browsers to adopt a "standard library" and even then it takes years for all users to adopt those browsers that support the standard library. Even on top of that, not all browsers implement the standard library properly. It really is a nightmare grown out of competing browsers with users that do not update them enough.

> Maybe because js projects have an order of magnitude more dependencies than a Python/Java/Go, etc project.

This is because JS file sizes matter a lot. We have huge libraries like `lodash` which are like a standard library, but nobody wants to use them because they dramatically increase the filesize of the JS bundle. I would rarely want to bring in lodash for a couple utilities, even with treeshaking and the like because it still dramatically increases bundle size. We have pretty excellent datetime libraries that most people hesitate to use -- like moment.js -- because they are huge. So what's the result? A ton of dependencies with very limited scopes because developers do not want to bring in massive libraries that do everything.

Let's flip to Python. Let's say magically you can run python inside a browser starting tomorrow. The second you bring in a library like `numpy` you're looking at a bundle size of 40 MB, and that's just one dependency. In the JS world that is utterly unacceptable. All the languages you mentioned take advantage of the fact that they can download those libraries to the filesystem and forget about it. JS has to download libraries over the wire, it's a completely different game.

What I'm trying to say is that the JS ecosystem didn't invent a bunch of problems to solve or that the people running the ecosystem are script kiddies. There are very unique problems that need to be solved in this ecosystem that make it different, especially when referencing the three languages you mentioned in your post.

With all of these "JS sucks" arguments I see a severe lack in empathy or even remotely trying to understand why JS has the problems it does.

Yes. Huge package ecosystems are hurtful. For the basics, language communities should come with a nice, batteries improved, standard library.

For the rest, people should only trust community projects with big following, processes, etc (like Apache stuff, Django, moment.js, postgres, etc), or open source projects supported by companies (e.g. nginx, mongo, React, etc).

The rest, sorry, but you got to write them yourself.

Downloading and using 1-person libs for trivial stuff like lefpad and such is madness.

Let's safely call it immature. The principle objectives here:

    * obtain employment immediately
    * prevent unemployment forever

What ends up happening is that people want to do their previous job in the context of their current job, such as write something that looks like Java in JavaScript. When that becomes the failure you would expect they blame the technology for not being their previous thing.

Compounding that training failure is that JavaScript has a low barrier of entry. Some of the people writing in this language are less than brilliant. The end result is a cluster fuck as evidenced by frequently used terms like imposter syndrome, snowflake, Dunning Kruger, and so forth. The insecurity, fear, and delusion clearly evident to me as a corporate JavaScript developer.

How do you solve for the obvious emotional failure that comes from the described lack of preparation? You hide under layers and layers of abstractions. You make life easier to the point of hoping code exists that does your job for you. Unfortunately that easiness is the opposite of slim or simple. It's great until it isn't if you aren't in a hurry.

"This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation."

Everything is backdoored, absolutely everything: your hardware, your firmware, the compiler used to build your software, your software, libraries used by your software, your network infrastructure, your crypto, your sources of entropy, the machines you communicate with, everything.

Pay Redhat enough and they will do that. Although you will be limited in what you can use.

So, you are saying that we should prefer code where it is impossible to have a look at the source because that solves the problem of having to trust the developers of that code?

WITH NO WARRANTY.

Do you not understand what this part of the licensed mean?

Mainter doesn't have to do shit. That is the point.

You want to start putting arbitrary ethics and morals on these developers? The "Fuck you. Pay me." talk comes to mind.

FOSS works fine like this and has been for a long time.

We're seeing issues now because of nodes lack of a standard library. Not trust and certainly not instead issues with free and open source software.

I kind of agree, but remember you are getting free software. Not a little, but a ton of free software and you feel like somebody should guarantee all works fine.

Choices:

- See what is going on in all your deps and waste a lot of time - Risk it and use the software without knowing what is doing - Pay somebody to guarantee that the software is not malicious

This may sound strange, but once tech companies actually had to either write or buy all of their software, and if they didn't have a contract in place that made someone else responsible for its quality, they were. So, basically, the world was absurd.

The way FOSS works is if users agree that a common good is important enough to invest in, and then they all benefit more than they would if they invested alone; it's anti-competitive. Free (and Open Source) software should be thought of as "free as in beer" i.e., the next round is on you. If you can't audit every line, audit some of them, or pay someone else to do it. Coordinate to get code coverage. If you use a project that is inadequately covered, you're responsible for everything that goes wrong.

If you don't even know what libraries your project depends on, how could that ever be thought of as anyone's fault but your own?

I'm reading that you'd pay a third party so you can trust open source code and think that FOSS somehow exposes commercial code to more risk in some kind of cyber warfare? How is that not complete FUD? You already have the option to pay vendors like redhat for many open source software components if liability is your only concern, the same is true for many of the more complex libraries out there.

Closed source on the other hand would mean buying every single piece of code or paying in house devs to write that code. I get the quality concerns raised here up to a point but just because a company paid somebody to write something doesn't mean it's not effectively written by a solo dev under heavy time constraints. Except with FOSS you at least have the chance to go in and inspect/fix the thing yourself if needs be.

Big business absolutely do that. Code quality review, security review, legal review. Every line of every 3rd party dependency.

Of course, for the most part big business doesn't take 3rd party dependencies. If you have a big enough software org, you write everything above the std library in-house. Why do you think so many of the big open-source frameworks are vended by big 10 tech firms?

You've always had "the right to refuse to run, on my machines, code that I do not have the option to understand". Nobody is forcing you to run any random piece of code you found on-line. You do that of your own accord. And if you screw this up, and that screwup affects other people, it's your fault. Simple as that.

Discussion on HN (2016) : https://news.ycombinator.com/item?id=11686325

I think Brett Victor is one of the people driving the effort beyond that project: http://worrydream.com/

> lets roll for a bit with the assumption that a small amount of extra care on Tarr’s part could have avoided this mess.

Are you kidding? The bare minimum of not just handing a repository under your name to a random stranger is apparently a hard to fathom concept for this author.

I agree tree shaking could help a lot. But every time I have tried to implement tree shaking properly in a JS codebase, it is not trivial to solve. If one configuration is not properly setup then the entire library gets inlined during compilation.

Furthermore, libraries like lodash use a lot of inter dependencies so using something like `get` could bring in a ton of stuff that is technically used but totally unnecessary.

Have been using nanovg instead: somewhat lower level, but at least it builds, and also it’s quite simple to use. The main downside it doesn’t support ClearType for text rendering, even when using it with FreeType.

This is why languages have standard libraries. It prevents the dependency hell we have with node.

I don't think that throwing wide-ranging functionality into the standard library is the answer, but I think with a bit of tooling it might be feasible to provide a "trusted" tier of packages that have been signed off on by code reviewers. Instead of every vendor needing to vet every dependency in their product, the work could be spread around. When a vendor finds they absolutely must have the functionality provided by a package in the untrusted "playground" (or whatever), they might be motivated to sponsor a review to upgrade it.

Ruby uses https://rubygems.org as central repository for the gems (something like node's modules). You can however host your own having only inspected software. However you know where the code is comming from and you can download it and inspect before installing.

Idea (benefit) behind this is two-fold: easy way to have same library in multiple versions (you often need that) and having per-application isolated bundles of gems (again, it's easier to clean everything afterwards this way).

Could all this be handled via system package manager? Sure, however it would be much more work for the developers (since gems generally work even on windows and other platforms; what package manager would you use on windows without `gem` command?).

PS: I don't argue that there is room for improvement in some aspects, but the general idea isn't bad imo.

The problem tends to be that users don't like the lag introduced by the packaging process.

It's definitely a valid strategy to get "more trusted" libraries to restrict yourself to ones that are available the the OS package manager.

Of course you should understand the limits of that trust ( for example AFAIK there is no security code review involved in the debian package process)

There is a law of the transition from quantity to quality by Hegel (http://www.pnas.org/content/97/23/12926).

As soon as number (e.g. of modules in NPM base) reaches some point the overall quality changes dramatically. It is a step function - from good to bad. From enthusiastic acceptance to full rejection of NPM and similar code sharing mechanisms.

Many people license their code under a "public domain license". What's interesting is that such a license has no requirements of placing a copyright notice anywhere, and allows someone to freely relicense without modification. This is precisely as it would be if you had written the software yourself.

Your license recognizes the value of freeware as a marketing tool - the more people with their hands on the software, the more likely some of them will stand up and pay for it. But I think the personal ownership aspect is more foundational.

In advancing that, the license I would write would be one that places the software under a free license after some fixed date. You might state, for software released in 2019, that starting in 2024 it will be licensed under the GNU GPL. Until then, it would be licensed under some proprietary license, perhaps the one you propose.

This forces people who use the software to pay for it's development, under whichever terms the proprietary license requires. Simultaneously, it ensures that those paying for it ultimately own the software, and therefore any improvements they make to it.