nilliams

The react ecosystem is massive, and includes impressive projects like the various backends/renderers: react-native, react-sketch.app, react-vr, react-pdf, ink, that have no equivalent in other frameworks (or at least to nowhere near the same level of maturity), so yeah people ditching it may well regret it.

> The only event that license terminated

Patent grant terminated, not license

Looks like they're working on moving away from bower: https://github.com/Polymer/polymer/issues/326#issuecomment-3...

A quick CDN get-started would be convenient I agree. There is Polymer-CDN for demos/code-pens: https://github.com/download/polymer-cdn

The 'native' stuff in your comment I don't agree with. You want browsers to start implementing native Android ListViews/Buttons etc? Browsers have a hard enough time implementing web standards.

And also this (cross-plat React Native for Windows/iOS/Android): https://github.com/Microsoft/reactxp

Yeah I don't have a stake/opinion, just posted that particular article because it's a recent, thorough take, by a lawyer.

They're referring to the 'patent retaliation clause', see: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...

Another premii fan here. Has some nice touches like the night mode mentioned and 'Appearance' settings (font/font-size/colour).

> Bootstrap is so 2015.

BS 3 is still very valuable for responsive-site conventions within a team, especially if you use it 'properly' from Sass or LESS source. The main part looking dated at this point is the JS that still relies on jQuery. There're projects like boostrap.native [1] and e.g. ReactBootstrap to deal with that tho.

I'm in no hurry for BS 4 until IE (< Edge) completely dies.

[1] https://github.com/thednp/bootstrap.native

> The plugin interface is a public interface too, right?

It didn't say 'plugin interface'. It said 'internal changes' that could affect some plugins. The way I read that is some plugins could be relying on internals (that they technically shouldn't, they may have good reason ofc).

> From the list of JS libraries they're using alone, I'm guessing it's going to get even fatter and laggier than it already was :(

Why? Only 3 of the 'JS libraries' listed are actual run-time code (React, Redux, Immutable). And React + Immutable are typically paired together specifically for speed optimisation reasons.

> I just want a listview of requests that appears in under a second

I think calling it a listview is a little unfair, and clearly there has to be tool/library cohesion with the rest of the Firefox devtools too, which are also much more than the odd listview.

Soon with the new webpack-cli, you'll just be able to 'webpack init':

https://medium.com/webpack/announcing-the-new-webpack-cli-75...

Hell no :)

The Amazon downloads seem to all be 44.1 khz mp3 (just downloaded an album of mine to check).

Webpack's HMR (hot reloading) of JS does work with create-react-app, but only if you use an external state store (like Redux), see [1].

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

Worth knowing most new vinyl records come with a copy of the digital download too.

Amazon will also automatically add (most?) vinyl purchases to your Amazon Music Library, and allow download.

Here's Divvy doing this in 2010 [1], the question is if Divvy is related to the patent or if they too received a letter.

[1] http://lifehacker.com/5715221/divvy-window-organizer-lands-o...

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.

[1] https://www.npmjs.com/package/shelljs

Awfully vague/FUDdy criticisms there:

- 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.

[1] https://nodejs.org/api/debugger.html#debugger_v8_inspector_i...

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.

Ah I missed that, sorry.

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.

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.

I think the developer behind Sublime Text is widely recognised as an outlier.

>> "Sublime Text 2 is mostly coded in C++ and uses a custom UI toolkit." ... [0]

How many other devs/teams are going to reasonably take that on.

(And how do you think the debugging story of his custom framework compares to Chrome Devtools).

[0] http://stackoverflow.com/a/9201645

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.

Thanks!

Which Chromebook model are you using? That does sound good for $250

It's unfortunate if you've encountered that because there's really no good reason for it. Thankfully now however most/all major JS frameworks & libs are moving to/have moved to 'zero configuration' cli tools (ember-cli, create-react-app, angular-cli, ...).

Yeah I checked out eacharg in your codebase, looks tight. I learnt quite a lot from your code about how jQuery could be structured, nice job!

Heh, props, I'm not disappointed, and yes that's a much better callback! But that is not implemented in the 5 lines of code you linked to is it? :)

jQuery's addClass 'does more', it can also take a callback:

    $el.addClass((i, existingClass) => (i % 2 == 0) ? 'odd' : '')