I'm not sure how null == false is a security fail in this case... if false were passed, the same effect would have happened. If false were the default for null, etc. In any case, it could have thrown an error, but this would have broken behavior.
This is an instance where the wrong default were passed, it has nothing to do with truthy/falsy in JS. In enterprise environments where you are mitm'd through your corporate transparent proxy, that's the behavior you want/need much of the time.
One thing that really irked me in ng2 was that an <input> uses [id] for a computed id property... however, a <label> needs [attr.for] for the attribute on the element's for instead of [for]. I don't know why unknown values for generic html elements aren't translated to [attr.*] in rendering. *sigh*
I really just don't care for Angular since I've started using React+Redux more. It just makes less sense. React+Redux+Axios(or fetch) get you pretty much everything angular offers in a much more reasonable interface, even with the setup costs for webpack+babel+*...
Definitely good news... I'm also glad that Array.from is now part of the spec, I've shimmed it similarly for years (Array.fromAny in my case).
Although it may be a while before this actually works well, I still look forward to it.
I've been a Bluebird user since very early on, and used Q a bit before the Promise/A spec was complete, the syntax changed a bit, but that said, I've had a preference to Bluebird.
It's worth noting, that depending on what other systems you are using in your packages, you should replace Promise with Bluebird as soon as possible.
If you're using webpack, you can use the ProvidePlugin
new webpack.ProvidePlugin({
Promise: 'bluebird',
...
});
This also helps with defining jQuery ($, jQuery, window.jQuery) for your modules (if they need jQuery)
you should also have an entry that establishes window/global overrides, so that it is truly global in the browser, will help with console statements as well.
I usually setup jQuery, Bluebird and/or Axios as globals... Though you can always use the shim that Babel and others provide, bluebird does more.
Not really sure why it needs to be a sprite at that point if you're loading SVG into JS variables... would probably just have each glyph/graphic element be it's on JS variable in a module, then expose that.
If you're using webpack, you can require these in as text. If you're also doing react, you can probably create a webpack extension (if there isn't one already) that brings these in as static react components... since React 15 added much better support for svg constructs.
repost from my comment:
Regarding immutable data structure in blog article's comments, immutable data structures won’t stop race conditions when you want/need shared data, what will be needed is an immutable data structure and a primitive locking mechanism… tbh, I think this will lead to a misuse of this system… I think I, and most people would be relatively happy with a server-side webworker interface, and the communication channel to go with it… Where webworker in the node-style server takes a path/module similar to require(), only it loads that module as a separate isolated thread.
It’s a cool idea, but I think it probably creates more problems than it solves.
These examples are fairly trivial, and don't really illustrate what DI/IoC frameworks tend to do, which imho is just as well... I much prefer the simple require/import statements that CJS/ES6 offer... as for testing, there's proxyquire.
For the most part IoC frameworks only offer indirection and difficulty in tracking down issues, when handling enhancements on a project that is new to you, or when it's fairly large with a lot of developers, and nobody understands the whole anymore.
I used to argue with the graybeard types when I was started with regards to enterprise patterns... now that I've kind of reached graybeard status, I'm far more inclined to use the simplest solution possible for as long as possible.
Okay, now add in authentication, client-side routing, menus with security profiles, remote api calls, and a host of other features.
The hoops that you have to learn to get started with react+redux, webpack, babel, node, etc. is still easier than starting a Java application, for example... harder than C#. Yes, there are tools needed...
I've had to support some pretty big applications with straight JS, and will tell you it's horrible, and doesn't work well at all. You wind up with a lot of troubles, more spaghetti, and even more dead ends, or repeated non-modular code. The last one took me several hours to fix a bug that would have taken 5 minutes in a more modern JS project structure.
Some people support angular, I prefer react only because there are fewer surprises, and the JSX model is cleaner imho than angular's template dsl.
I've been a Bluebird user since very early on, and used Q a bit before the Promise/A spec was complete, the syntax changed a bit, but that said, I've had a preference to Bluebird. It's worth noting, that depending on what other systems you are using in your packages, you should replace Promise with Bluebird as soon as possible. If you're using webpack, you can use the ProvidePlugin new webpack.ProvidePlugin({ Promise: 'bluebird', ... }); This also helps with defining jQuery ($, jQuery, window.jQuery) for your modules (if they need jQuery) you should also have an entry that establishes window/global overrides, so that it is truly global in the browser, will help with console statements as well. I usually setup jQuery, Bluebird and/or Axios as globals... Though you can always use the shim that Babel and others provide, bluebird does more.