Love the last paragraph...
And, no. Do not give me that bullshit about Android
or iOS being easier to develop for because they’re
single platforms. Nothing is stopping you from
sniffing user-agents, developing for a single browser,
and blocking all the rest with a big fat “Your browser
is not supported” notice, as bad as that’d be. How is
that any different from developing for a single mobile
operating system? Well, it’s different in that at least
on the web you don’t have to put up with App Stores, a
proprietary API, breaking changes, or licensing fees.
One comment, one critique... First, it's somewhat obvious English isn't the author's first language, some of the constructs are a bit out of order, which is actually okay, the gist of the message comes across.
What actually bugged me a bit more than the language/grammar, was that some events are just plain out of order, even with the dates it's would be harder to follow without having lived through all those changes.
What's funny is I kind of suppress most of the past in that regard, and simply push forward towards the newer syntax. I'm really glad that pretty much all of ES6/2015 is now in the browsers (IE now needs to die), and that even async functions should be common soon. With all the major browsers pushing frequent and mostly automated updates, it should get a lot better in the next year or so... right now, there's already modern/minimal transform options in babel, to let you use the latest features, without the full es5 transforms from even a year ago that were mostly needed.
I think it will be an interesting couple years. More interesting is some proposals to get a few F# operators into JS, that could be pretty cool. The combinator >> operator (used to combine functions into a new function) is pretty interesting, even if it shares the same operation as shift, it would need some tweaking to the standard. Although, fat-arrow syntax mitigates a lot of the issues, there are still leaner syntax operations that can now start to come in.
Nice, I'm glad he kept the Error serialization, though I did have two issues (pull requests made)
1) shorten to return new Date(obj); will clone the date.
2) don't return early from error object, some frameworks extend the error instance with things like exit codes, etc.
(note, I wrote the tracker1/safe-clone-deep author mentioned)
Pretty wild... and I'm entirely amused that people complain about the churn and boilerplate for React. I'm glad they worked out whatever issues were preventing the mangle option for uglifyjs to work, as that's a pretty significant difference.
Still not a fan of DI in JS, especially with it's easy module system... it's easy enough to export a single instance in a module, and if you only need one instance, then you can create a wrapper that everything else imports that give you the instantiated instance explicitly.
DI systems make it hard to track down where something came from, makes for disconnected code that's often harder to debug and test against, and in general is usually a complexity that is best avoided.
DI makes far more sense in a statically typed environment that requires certain types of inheritance for testing. Although it *may* provide value if you're writing your tests in TypeScript, I would emphatically *not* use this for JS.
Grommet definitely had some nice features... I haven't seen that library before...
One good thing about react is if given component libraries are well isolated, you can usually bring in `lib/component/foo` as a single component without bringing in the whole library. It would allow you to use, for example, the stats from rebass and the form fields from material-ui. Some libraries do use heavy/separate css, and would keep an eye out for that... if it isn't easy enough to only bring in what you need (via source import), then I would probably avoid such libraries.
It's probably best to create a common lib/components that brings in those components in your application individually, but only those you use... this way you can reuse by importing {Foo} from 'components' or SomeIcon from 'components/foo' aliasing components to your lib/components directory.
I think one should also point out react-icons, which collects the most popular icon libraries as svg icons, so you only bring in what is needed as react components... they seem to be normalizzed, so combining fontawesome icons with google's material icons works out okay (trying to use the font versions together has tended to be problematic).
Love the last paragraph... And, no. Do not give me that bullshit about Android or iOS being easier to develop for because they’re single platforms. Nothing is stopping you from sniffing user-agents, developing for a single browser, and blocking all the rest with a big fat “Your browser is not supported” notice, as bad as that’d be. How is that any different from developing for a single mobile operating system? Well, it’s different in that at least on the web you don’t have to put up with App Stores, a proprietary API, breaking changes, or licensing fees.I'd much rather use es2015 syntax for rest/spread with fat-arrow syntax... somethingAsync() .then( (...args) => doSomething('prefix', ...args) );Grommet definitely had some nice features... I haven't seen that library before... One good thing about react is if given component libraries are well isolated, you can usually bring in `lib/component/foo` as a single component without bringing in the whole library. It would allow you to use, for example, the stats from rebass and the form fields from material-ui. Some libraries do use heavy/separate css, and would keep an eye out for that... if it isn't easy enough to only bring in what you need (via source import), then I would probably avoid such libraries. It's probably best to create a common lib/components that brings in those components in your application individually, but only those you use... this way you can reuse by importing {Foo} from 'components' or SomeIcon from 'components/foo' aliasing components to your lib/components directory. I think one should also point out react-icons, which collects the most popular icon libraries as svg icons, so you only bring in what is needed as react components... they seem to be normalizzed, so combining fontawesome icons with google's material icons works out okay (trying to use the font versions together has tended to be problematic).