The container can be <body>, but you can just as well attach to some <div> in the footer and the rest is rendered independent of Elm.

Regarding dead code elimination: yeah, elm doesn't do it yet. But the code generated by elm-make is very predictable and therefore easy to process. I just tried uglifyjs:

raw elm-make output; 196kb

uglifyjs -m -c: 68kb

tar czf: 20k

The inventor of elm is very deliberate in the project's development. I believe his argument is that including dead code elimination now is premature, because it adds a lot of maintenance work, especially at a time where the language is still evolving. Once the raw js is no longer a moving target it shouldn't be too difficult, and until then uglify and similar do a good job.

This is what bothers me about Elm. In the next few months, I'll be starting on a site project, and I've been fiddling with Elm and I don't see how I can create progressive web apps with it. It doesn't seem to play well with service workers for an offline mode, and there's no fallback if Javascript is disabled. Either it loads or it doesn't.

I want to use Elm, I don't want to use JavaScript, but I also want a progressive web app that will offer some functionality offline. I guess there's a way to do some server-side stuff with Phoenix, but then the front-end / back-end division isn't so clear and I'd end up using JavaScript for the service workers anyway.

I've not looked super deep into this, so I'd be happy to be corrected if I've got the wrong end of the stick here.

Of course it would be nicer to be able to write everything in Elm, but I find having the majority of your app in Elm with a bit of JS is significantly nicer than having the whole app in JS.

You can make it nicer still by using Typescript instead of Javascript, and defining interfaces for the data going through the ports, giving you type safety across the whole stack.

I'm using this approach right now in a mobile Elm/Typescript app with great success.

Yet I worry about adding Elm to new projects, mostly because it raises the level of developer I need to hire to maintain it. I'm not in SV or in a tech hotspot at all, so maybe I have to think about this more than the average HN reader.

Personally, I'm actually not the biggest fan of the design philosophy behind Elm, but I do have to admit it's easy to learn with some great introductory learning materials. Getting somebody motivated up to speed on maintaining Elm is not an issue.

For what it's worth, I think the same is true of Haskell-style languages in general: with a bit of guidance, it's not hard to make new programmers productive. That's the experience IMVU[1] had when switching several internal projects to Haskell from PHP, if you want a case study. I met the lead engineer who wrote that post once and he explained that it actually took about as long to train an incoming developer (with no FP experience) in Haskell as it did to train incoming PHP developers on IMVU's in-house PHP "flavor" (frameworks, code organization... etc).

Picking up Haskell or Elm is a bit difficult by yourself for a few reasons: there's no clear path on what to learn, the learning materials are a bit hit-or-miss and there's a lot of incidental complexity. However, if you provide a bit of guidance (ie curate libraries) and help overcome some of the incidental complexity (ie install the compiler and tools) it's surprisingly accessible.

[1]: https://engineering.imvu.com/2014/03/24/what-its-like-to-use... (see "Training" section especially)

I love Clojurescript as a language, but using it alongside existing js libraries is awkward and error-prone, and getting the build process to work smoothly takes way more time than it should. Cljs gets a lot right too, but it shouldn't be held up as an example in this regard.

There was a DCE branch at one point but it never got finished.

When it comes to dead code elimination, it is true that the compiler currently does not have that. Luckily, the compiled js is just a series of functions (namespaces is a part of the function name, like namespace$functionname) and so a tool like uglify has no problem removing dead code. A minified Elm app is smaller than a minified React app.

http://tech.noredink.com/post/126978281075/walkthrough-intro...

I'm sorry to be so negative but I really hope your comment doesn't remain the top comment as it's not very well-informed at all.

Hardly. Server rendering remains at best a novelty, and "progressive web apps" are not coming back anytime soon.