Cool. I wouldn't take the critics too harshly. As someone who has configured a lot of webpack configs across multiple version of webpack and various versions of the plugins necessary to enable these features, I know <i>exactly</i> what you had in mind when you put this together. This is a very saturated technology stack, so people can't help but react to it as noise.<p>To the critics, in front-end land there are some programmers who believe that building an SPA is always a mistake. I am of the opinion that there are some types of applications that live in the browser that benefit from the UX enhancements that scripting can provide. We all know some examples.<p>Everyone knows that front-end land is a crazy wild-west with a lot of moving and a lot of breaking along with a lot of hype, trends, wheel-reinventing and cavalier attitudes towards security. The criticisms are mostly fair.<p>However, if you're building an SPA, there is a combination of tools out there that can provide a very conceptually clean (from an architectural perspective), performant, reusable, and highly productive and fun development experience. Of course, this doesn't mean these tools make building an SPA the appropriate engineering decision, they are just tools, only the requirements can dictate whether or not an SPA should be built.<p>This project attempts to preconfigure via webpack, what is IMO, the best selection of tools available for working on an SPA today. For me, these tools include:<p><pre><code> - react
- react SSR
- bundle code-splitting
- es6 (or ts/es6+flow)
- es6 modules
- hot code and css reloading
- module aliasing
- css modules
- postcss
- reusing business and validation logic modules on the front and back end
</code></pre>
All of these tools solve very specific (former) problems that one encounters while working on an SPA. Anyway, nice work!