Style: snake_case vs camelCase

[johanneslumpe]

What do you think - would you be open to move to camelCase, as it is somewhat the community standard for JS?

[catamphetamine]

Where exactly would you like camel case?

On Thursday, September 10, 2015, Johannes Lumpe notifications@github.com
wrote:

What do you think - would you be open to move to camelCase, as it is
somewhat the community standard for JS?

—
Reply to this email directly or view it on GitHub
#3.

[johanneslumpe]

Basically on every part which is exposed to the public, meaning all public api methods. I know that this would be a breaking change though (or at least one which would require the deprecation of the previous methods - although there could just be aliases for now)

[catamphetamine]

Well, the only public API name that comes to my mind is url_loader_parser which I can alias to urlLoaderParser (while preserving url_loader_parser in the docs).
Will that satisfy you?

[johanneslumpe]

There would be .regular_expression(asset_type) too plus the whole config file, which relies on snake_case :) In general this is not a must though, just a suggestion.

[catamphetamine]

ok, i'll think about it this evening.
but you should be more specific.
what do you mean by "the whole config file"?

[johanneslumpe]

Ah sure. I'm talking about the config options available here: https://github.com/halt-hammerzeit/webpack-isomorphic-tools#configuration

[catamphetamine]

done.

i didn't check it but it should work now.
if it doesn't, then you can reopen this issue.

[isaac-peka]

Hey @halt-hammerzeit, first of all great work on this library - it's such a better solution to this problem than some of the other methods out there.

Are you still open to a PR to create camelCase aliases for the API and to update the docs? If you are, I'll submit a PR when I have a spare moment. Personally, I would just move all of it to camelCase - it's not a major problem but it's a little jarring since it's such a contrast to every other library out there.

[catamphetamine]

Yeah, I'm open to a PR camel casing the public API.
As for the docs, I would prefer to leave the examples as they are because I like it more that way.
A note could be added, say in the API section, stating that all the public API methods and parameters do have their camelCased counterparts.

[catamphetamine]

FYI
I'm posting this in every issue and PR to notify whoever may be interested:
today I've released an alternative helper library called universal-webpack.
It takes a different approach than webpack-ismorphic-tools and instead of hacking Node.js require() calls it just compiles all code with target: 'node' webpack configuration option.
As a result, all Webpack plugins and features are supported.
If you think you might need that here's an example project:
https://github.com/halt-hammerzeit/webpack-react-redux-isomorphic-render-example

[isaac-peka]

@halt-hammerzeit I like the look of your new library since it's more in tune with how webpack recommend doing this, but tbh I'm not totally sold on webpack's approach in general. It feels a bit odd to have to transpile the backend, it seems like it will be hard to debug if something goes wrong and at a base level it seems a little weird to have to go through a build process for a duck-typed/dynamic language since you're not really getting any benefit from it.

Now that you've done both approaches, which do you think you prefer?

[catamphetamine]

@sampeka I don't like the transpiling approach either. Especially for the server, because you absolutely can do it on-the-fly.

Debugging isn't more difficult since source maps are working.

I would prefer the newer library for new projects, still I'm not migrating my own projects because I don't use any Webpack plugins and features since I like pure javascript more and I'm not sold on all this Webpackish stuff: it brings complexity to my favourite Node.js, magic and stuff. Webpack is a neccessary piece of technology but I believe in more simple stuff.