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.
How is it any different from any other large development community... take C#/.Net if it weren't for the alt.net crowd and all their work creating frameworks of the day the open-sourcing and great work in ASP.Net MVC never would have happened... Same goes for Java, Ruby, Python, etc.
If it weren't for prototype, mootools, and a host of other frameworks, we never would have seen jQuery, or gotten to document.query*
It's representative of a healthy ecosystem. Yes, it makes it harder to get started, but there's always going to be some of that with something new. JS is far bigger than anything else, just because of how widely it's used/distributed.
Nice entry-level tutorial... misses the use of react-redux for higher-level component integration... Another useful module is redux-actions (with the S), as well as redux-thunk and some of the other composition support.
I tend to break up my project in terms of feature... that "feature" can consist of multiple marts of components, reducers, actions, api (portion of data access, used with action-creators + redux-thunk). The features are composed with the type of functionality and grouped hierarchically. Worried more about structure of features, whether it's for display or data... the data may be used for the display in adjacent features.
If you don't mind a minor lag at startup, and more memory usage, you can `npm install -s babel-cli babel-preset-es2015-node5` and use `babel-node` ... setup a small `.babelrc` file and you're off...
I usually do that at the start of prototyping something in node, often it's "enough" ... I find that async/await is worth it by itself.. add in destructuring, fat-arrow function expressions, and it's really worth it... I'll take easier to reason code with a little tooling over trying to do vanilla node/js these days.
I usually bring up proxyquire when I see someone creating a DI library for JS... for the most part DI libraries aren't needed in JS and only serve to complicate code in ways that isn't needed in practice.
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.