codenames-pictures icon indicating copy to clipboard operation
codenames-pictures copied to clipboard

Using a bundler for the JS and CSS?

Open jackwilsdon opened this issue 5 years ago • 5 comments

I thought I'd open an issue here to discuss thoughts on using a bundler such as webpack to bundle up the JS and CSS into a single file, meaning we only need to serve a single file containing both the JS and CSS to run the application.

It looks like we're currently transpiling JSX to JS in the browser, which is a bit of a funky thing to do IMO. We could instead compile it before running the server using webpack and potentially go-webpack.

I guess the main downside of doing this is adding a dependency of Node.js to compile the application, which is less than ideal.

What is the general consensus on this?

jackwilsdon avatar Oct 05 '18 15:10 jackwilsdon

I personally enjoy not having to use node.js, I like how you can get the server running in just a few commands (and even less effort once #22 comes into being).

banool avatar Oct 05 '18 16:10 banool

I can understand that, although I'm not a big fan of how the JS is currently transpiled in the browser at runtime.

What are your thoughts on either maybe moving away from React.js and just using straight up jQuery to manipulate the page (this could be nice if kept simple), or using React.createElement instead of JSX? (removing the need to transpile)

Another alternative could be to create a Docker container which builds a static binary and run it on Travis CI, publishing those as a binary release on the repository and meaning people don't have to go get the application (and can just run the downloaded binary).

jackwilsdon avatar Oct 05 '18 16:10 jackwilsdon

I'd rather keep React and JSX, if not for the sake of using React (this is a learning experience as well after all). How extensive would the shift away from JSX be?

Having something build a static binary in CI seems reasonable to me, and if Docker is the means to that end that's okay, but I don't want Docker to become the canonical way of running this, I feel this application really isn't complex enough to warrant it.

banool avatar Oct 07 '18 17:10 banool

Shifting away from JSX isn't ideal to be honest - I wouldn't actually recommend doing it. You end up with JSX like this;

<div className="container">
  <h1>This is the title</h1>
  <MyComponent />
</div>

Turning into this;

React.createElement(
  "div",
  { className: "container" },
  React.createElement("h1", null, "This is the title"),
  React.createElement(MyComponent, null),
);

Which is less than ideal. You can tidy it up a bit by aliasing React.createElement but it's still not as expressive as JSX itself;

const e = React.createElement;

e(
  "div",
  { className: "container" },
  e("h1", null, "This is the title"),
  e(MyComponent, null),
);

Regarding Docker becoming the canonical way of running it - it would only really be needed to build / run from source if you didn't have Node.js installed locally. By providing pre-built binaries on here most users wouldn't need to build it or use Docker at all.

I guess this isn't ideal, so feel free to close this if you think it's not worth the trouble 👍

jackwilsdon avatar Oct 08 '18 09:10 jackwilsdon

The original repo ended up going this way, using typescript and a bundler and docker and all that. I have added a Dockerfile at least, but I don't have the rest. If some brave soul wanted to try to pull in all the changes from the original repo and reapply the Codenames Pictures stuff on top that would be awesome, but it's quite a lot of work.

I imagine the real solution would be to modify the original to support the changes I make here more easily. As it is now, I had to change the original code a lot.

banool avatar May 17 '20 16:05 banool