Poll: Keep or Ditch Support for Non-JS Assets?

[dvdzkwsk]

General question since I don't know how much people are even using this starter kit with non-JS assets (i.e. it's currently setup to allow Sass imports). Basically, do we want the focus of this starter kit to be strong support for client-side development, or should it be a more robust universal kit?

Benefit of going JS only

• The server would be able to directly import all application source code, thereby eliminating the build step that's currently required to perform server-side rendering. See: Where does initialState come from? #57 for more on this.
• Server development would be responsible for proxying the webpack assets, so you'd now have a more cohesive development environment.

Downside of going JS only

• Would no longer be able to use folder aliases.
• (Obvious) only JavaScript assets would be able to be imported. You'd have to implement your own build step for compiling styles and whatever else you might need.
• There'd need to be some work to get the server to support hashed asset names.

I probably missed something somewhere, but those are my initial thoughts. Any other perspectives are greatly appreciated.

[nhagen]

I think another options (which requires the most effort...) is to provide support out of the box for non-js assets and provide some documentation on how to remove them. I think a common reason for someone to use a starter kit is because they tried to configure everything independently and didn't get it quite right, so they went to the kit that had everything they needed. If you're unfamiliar with webpack, for example, its probably easier to strip stuff out than to add stuff. This is especially true if the ecosystem is new and you don't even know what you need.

[dvdzkwsk]

@nhagen I agree that would be nice, but the question is more about whether or not the starter kit should focus on a well-rounded development environment for client code or a more cohesive client+server kit. A lot of the features this starter kit uses are Webpack-specific (aliases, non-JS imports, etc.), so if we want to support them at all (whether or not we document how to remove them) that means the server code must either be bundled with Webpack, or use a Webpack'd application bundle (which is what it currently does).

From what you say, I'm leaning more towards keeping the server separated from the application source code, that way the starter kit can provide more options to those who, as you say, may not know how to configure it themselves. If the starter kit stays how it is, I'll definitely work on improving the documentation as you suggested.

[mlusetti]

I totally agree on keeping the server separate and I actually like more the support for client-side development.
An universal kit is something everyone will strive to but to achieve it you've to be more opinionated.
I find perfectly suitable to have a webpack'd application bundle.

[tsemerad]

I vote for keeping it how it is, but adding documentation on trimming out support for non-JS assets as @nhagen suggested. I may be a bit biased though - this starter kit has exactly what I need for my next project. Thank you for your work on it.

[dvdzkwsk]

Thanks @mlusetti and @tsemerad. I was leaning toward removing non-js assets just because a majority of the issues reported relate to server side rendering, but as @mlusetti said improving this aspect means implementing an opinionated build system. From what you guys say it sounds like the current configuration works well for most use cases, so I'll keep it how it is. This being the case, I'll work on improving documentation per suggestions and possibly add support for additional asset types.

Thanks for your help. I'll keep the ticket open just in case somebody else has an opinion, but the decision has essentially been made.

[mlusetti]

You're doing a great job! Thank you so much for your effort, is really appreciated.

[dvdzkwsk]

Closing this since the server is no more.