True for async code, but if you use something like ShellJS [1] (which would be an easy way to rewrite a bash script that was getting out of hand), all commands are synchronous, so error handling is just try/catch.
- dynamic require()'s can't be tree-shaken: same is true of other langs, e.g. Python. Perfectly understandable IMO as Node was designed for the server, in a time tree-shaking (largely desirable for front-end code) wasn't a priority. Also it is a standard (CommonJS).
- long pathnames is a Windows only issue and afaik fixed by npm 3's "flattening".
- npm is worse than Maven because 'npm publish' is too easy?
- you don't need to run dedupe.
- you say npm isn't curated but I'm not aware those other registries are curated either?
- 'left-pad is a perfect example of why npm sucks' ... except the ability to delete packages has been fixed, so should that be 'sucked'?
(Edit: how on earth do you format lists correctly on HN?)
In some cases here, he's talking about fixing bugs in a production. It's not so simple to attach a debugger to a live application serving 100s of requests. Break and you just 500'd all users.
In others granted he's working locally and probably could have found the problems without logging, but that just comes down to preference IMO.
Node does have a debugger though and recently added official (though experimental) support for attaching the Chrome DevTools debugger [1]. Doing so was doable via 3rd party packages previously.
Edit: updated as author wasn't only talking about in-production.
Huh? For an editor in the browser you don't send every keystroke and paint update over the network. The UI is effectively local, you would only need to send regular network updates for 'autosave', and it wouldn't be to keystroke granularity.
Sublime, last time I used it, had a nag window every x saves(?) if unlicensed, which I'm sure encouraged a lot of people to pay. I doubt so many users would convert if it was totally open source and they could easily install a nag-free build.
Just because the code might be opened up doesn't mean the nagware would have to go away. One underlooked option is to keep it and release under GPL. It's not well known, but GPL more or less protects nag screens. No one would be able to patch and distribute modified versions for the express purpose of disabling the nag screen without violating the license. The author would be able to sell his or her own builds without the nag screen, just like today.
Section 1 is the verbatim copies permission, section 2 merely requires your derived version to have an appropriate copyright notice (and the creator of a derivative work is the copyright owner of the derivative), not to preserve the pre-existing copyrigut notice of the original one, much less to include any other information besides a notice of copyright that might appear in a pre-existing a "nag screen".
I'm not sure why you think your slanted summary is a better argument than what the license actually says. If it supports your position, just point to the text of the license itself where that support comes from. Your words are not an adequate substitute.
> Section 1 is the verbatim copies permission, section 2 merely requires [...]
To clarify an important point of fact: Section 2 is additive. It builds upon the terms enumerated in Section 1. You only get to exercise the right to make modifications if you satisfy the extended provisions from Section 2 on top of your obligations from Section 1. To wit, Section 2 allows you to "distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions".
That is, you cannot perform actions under Section 2 without also fulfilling your obligations from Section 1.
> not to preserve the pre-existing copyrigut notice of the original one
This is not true. It would be true if the GPLv2 required that you merely maintain some form of fair attribution. But that's not what it says.
You are obligated under Section 1 to "keep intact all the notices that refer to this License". (And you are not allowed under Section 2 to shirk your obligations from Section 1. See above.) If the original author includes a notice as simple as, "This copy of Sublime Text Community Edition is based upon Sublime Text Pro and made available to you under the GNU General Public License, version 2", then no provision of the license permits you to distribute modifications where you've replaced the notice with one of your own, even if you think it's fair. Anyone getting away with this today is only able to do so in cases where the original author is looking the other way because the downstream modifications are more or less in the spirit of the license, even if they aren't technically following it to the letter.
That GPLv2 allows for this should not even be surprising—it's similar to the philosophy behind including provisions for Invariant Texts in the GFDL. It's only if you view things through the hazy lens of history where licenses like Creative Commons have shown up and maybe distorted one's general understanding that this comes off as unexpected.
Finally: I constantly find that I want to kick myself when I get involved in licensing discussions here that deal in anything other than the most blunted, obvious aspects of FOSS licensing. So this will be my last comment in this thread.
> No one would be able to patch and distribute modified versions for the express purpose of disabling the nag screen without violating the license
This is wrong - the GPL only requires that the source code of the modified versions be made available. The nag text could be put in the license notice text itself (the original license should be preserved in modified versions), but that might change the license from GPL to GPL-based/GPL-compat. IANAL.
Nice in theory but in reality, top Google result for 'no nag sublime' would be a snippet of how to git clone and patch out the nag, widely distributed from day one.
At least with current ST the 'tutorials' for this tend to involve hex editors or scripts that can be quietly subverted by the author.
Sure. And how much of a dent in revenue to the author would this lead to?
Keep in mind the context of this conversation is a conjecture that Sublime's nag screen led to purchases out of convenience for the users making those payments (who could've easily patched the binaries but didn't). Disagree with that premise if you want, but if so, clarify that you're doing that.
Huh, I started that premise and I'm continuing to argue it. You might be thrown off by HN's busted comment nesting.
If my last comment wasn't clear, I think the dent in revenue would be considerable for fully open-sourcing Sublime as it would make it too easy for people to patch out the nag.
Distributing those patches would be against the license. I'm looking for any indication that the set of people willing to a) download a patch; and b) use tools to apply it on their own; and c) build it; and d) be unmoved about the ethical implications of the whole thing; is at all significantly larger than the set of people willing to open a hex editor to poke at some bytes for the same purpose.
> Huh, I started that premise and I'm continuing to argue it. You might be thrown off by HN's busted comment nesting.
I'm asking that your argument is internally consistent—that you're not trying to advance some thought, and the backtrack to a position where you advance another one that's at odds with the original. I don't see how this suggests that there's confusion about how to read threaded comments.
The 'React Hot Loader' [2] module, which maintains local React component state is not included yet.
[1] https://github.com/facebookincubator/create-react-app/issues...
[2] https://github.com/gaearon/react-hot-loader