And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.
That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
Search google for webpack incompatible
I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way.
We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions.
That being said, dealing with legacy code always always suck.
For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.
I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.
If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.
Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.
If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.
I agree though that the vibe is different. Newcomers feel less welcome. I think by the end of this year, we will see a layer of abstraction over a stack similar to the one described in this article, and that it will be the new jQuery, in terms of letting a novice developer make something surprisingly powerful. At least I hope so.
the whole function composition has a clean feeling and LS removes a lot of cruft
Then a friend of mine told me about Clojure/ClojureScript. I never understood hoisting.
That said, Elm can be difficult to use today. The foreign function interface is not all that great of an experience. There is a lot of friction in just defining, serializing and deserializing JSON objects. You wind up writing a lot of code you wish you didn't have too. Their great time traveling, hot reloading debugger doesn't actually hot reload anymore. And there is no real back end language synergy to speak of at the moment. Many are looking toward Elixir and Phoenix for support instead of more language-similar Haskell options like Yesod and Snap.
The competing PureScript, GHCJS, Websharper and FunScript alternatives also complicate the landscape that Elm plays in greatly.
So for me it's a kata for learning how to be a better functional programmer. Once I feel I 'get' the FRP model used I may just go and do the same stuff in another language, see how it plays out in Haskell or Purescript.
I feel FP will remain a hobby though and the best I can hope for is to convince .NET colleagues to make immutable classes, use code contracts to avoid null problems, and generally try to minimize state and maybe use Rx. Even F# would be too much of a push for most .NET shops. I have a mortgage and fixing bugs caused by ridiculous state and null references in .NET code pays it and then some :-)
While it doesn't have the gradual typing and fantastic compiler messages, it is also functional and immutable. But to my view it has all around better tooling, very simple FFI (either reference JS already on the page transparently or pull in JS formally via extern definition files similar to TypeScript typings), optional typing via core.typed, sourcemaps with a native debugger, and a node-like full stack synergy through Clojure but with all the power of the JVM.
You definitely lose some confidence at run time due to the dynamic typing, but on the whole I think the gains far exceed that. At least for me it's a package that is very hard to beat.
Is this what it means to look for a job in the startup scene in 2016? It seems overwhelmingly likely that you'll be dropped into some unholy, frankenstein-esque work of "art"
While JS has a few pain points that should be addressed by tooling, I'd draw the line at React and jQuery and a bespoke, well-kept utility library
You kind of need to settle on some kind of design pattern on how your data exists, flows, etc. You'll want to be reasonably DRY doing it. Whatever you code will probably be around the same scope. May as well use something that's already documented and done. Same some time.
Then if you want to roll up your own bundler, minifier, manage your script tags on your own, spend more time testing, etc...well, that's up to you :)