
Small Assets without the Headache in Elm 0.19 - liquid_x
https://elm-lang.org/blog/small-assets-without-the-headache
======
antew
I'm so glad to see this, congrats to Evan and everyone who helped get 0.19 out
the door!

I've been working in Elm for about a year now and it is a joy to work with,
moving from vanilla JS/Angular/React to Elm has been a boon to productivity
and I actually have confidence that when I refactor something and have fixed
any compiler errors that it is going to work.

~~~
eksemplar
We had a lot of trouble doing things without typesafety and declarations, so
we tried a few things. Elm was one of the better ones, and we migrated a few
minor systems to it. A few others to typescript and we even made a few pocs
with Xamarin and Wasm.

Then one of my older employees randomly watched “JavaScript the better parts”,
and recommended it to me and we’ve been doing classless JavaScript ever since.

Elm is great, certainly one of the better alternatives, but now it really
feels like a step backwards.

~~~
spuz
What is classless JavaScript? I don't understand how you had trouble doing
things without typesafety but found that going from JavaScript to Elm is a
step backwards? Maybe I'm missing something here?

~~~
eksemplar
[https://web.archive.org/web/20151029152324/http://ericleads....](https://web.archive.org/web/20151029152324/http://ericleads.com/2013/01/javascript-
constructor-functions-vs-factory-functions)

[https://weblogs.asp.net/bleroy/crockford’s-2014-object-
creat...](https://weblogs.asp.net/bleroy/crockford’s-2014-object-creation-
pattern)

Once you start doing this, most other languages become obsolete. Because you
avoid most of the problems of JS that things like elm try to fix, while
maintaining the freedom and also writing a lot less code because you don’t
have to write a “recipe” for half the things you write.

The disadvantage of JS is that it’s actually going in the wrong direction.
Class is an attempt to copy C-style languages, and that really what you don’t
want to do, because as soon as you use inheritance, the “this” keyword or
“new” you’re basically doing JAVA/C#/whatever with all the downfalls of JS.

~~~
leshow
Your comparison doesn't make any sense. You would use a language like
Elm/Purescript/Reason etc for the type safety, that's completely orthogonal to
whether something has classes or not.

~~~
eksemplar
Except you don’t need typesafety when you do this because you’re never
expecting a specific type, and at the same time, you don’t have to waste time
writing the recipe for what you’re going to do.

~~~
boubiyeah
You're always expecting a specific type, whether the type or schema is made
explicit by the language or not.

------
doctor_stopsign
Congrats on the release! I have very high hopes for Elm in the future, and I
think it truly shifts the paradigm of frontend development.

On an attempt to use Elm in production I ended up switching back to
Javascript. The biggest issue I faced was lack of type-classes, which made
certain parts of the code feel like I was pulling teeth to get Elm's type
system to be happy. Perhaps this is more of an issue of expecting Elm to be
more like Haskell than it is.

I hope Elm is able to get more adoption, and with it more examples of
idiomatic approaches to problems in Elm's style. However this somewhat feels
like a chicken-and-egg problem.

Regardless, this release looks great for people using it in production
already!

~~~
pdamoc
> Perhaps this is more of an issue of expecting Elm to be more like Haskell
> than it is.

Some people have a hard time in Elm because they expect Elm to behave like a
language that they are already familiar with. The most frequent impedance
mismatch issues I've seen are reaching for `type-classes` or attempting to
implement various polymorphic behaviors and people who are too hungover on
imperative constructs (Elm is declarative).

Once people start using Elm the way it was designed to be used, things become
simple and start to flow.

~~~
undreren
> Once people start using Elm the way it was designed to be used, things
> become simple and start to flow.

But how will anyone ever get anything done, when they can't make everything in
their code exceptionally clear by wrapping it all up in a 15 monad thick
monad-combinator? /s

But yes, I totally agree. Elm is a simpler, safer and easier Haskell for the
front-end. I just love it :)

~~~
comex
The idea that wanting to use typeclasses in Elm is an impedance mismatch would
be more convincing if Elm and its standard library truly did everything
without them, using alternate approaches like explicit dictionary passing. But
as you probably know, they don’t. Instead, the language has special syntax for
three builtin “typeclasses”: comparable, appendable, and number. And the
standard library uses them: its Dict, for example, requires the key type to be
comparable. These classes are automatically implemented for various builtin
types, but there’s no way to implement them for custom types, so you can’t
have Dicts with custom types as keys (unless that changed very recently). And
if you want to, say, implement a hash map data structure, which requires the
keys to be hashable, you have to use a completely different design, since
“hashable” is not one of the three magic typeclasses.

To me, rather than principled, that just feels incomplete.

~~~
rtfeldman
Elm handles those things the way Standard ML does, not the way Haskell does.

It's cool if you prefer the way Haskell does it, though! You should check out
PureScript, which chose to do it the way Haskell did it.

~~~
comex
> Elm handles those things the way Standard ML does, not the way Haskell does.

That's the thing, though: it doesn't. Sure, Elm is expressive enough to allow
use of dictionary passing as a substitute for typeclasses, and as you noted,
this approach has some resemblance to how ML modules work – albeit with less
sugar. However, Elm's standard library does not seem to think this is the best
approach, since it instead uses the aforementioned special-cased typeclasses.

~~~
rtfeldman
> use of dictionary passing as a substitute for typeclasses

No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No
language needs typeclasses.

Both Elm and Standard ML have additional type constraints for numbers and
comparable types that aren't implemented in terms of a user-definable type
constraint like Haskell's typeclasses.

Another example of their being different is that Haskell offers custom user-
defined operators, whereas Elm intentionally does not allow user-defined
operators. There are a fixed list of them, and that's it. A great many
languages have that policy too, and I would not call them wrong to do it that
way.

Again, there are sound design reasons to make either choice! There are costs
and benefits to making things user-definable. If you prefer the way Haskell
did it, great! That's why we have different programming languages. :)

~~~
Athas
> Both Elm and Standard ML have additional type constraints for numbers and
> comparable types that aren't implemented in terms of a user-definable type
> constraint like Haskell's typeclasses.

That's not really true. Standard ML has _overloaded_ operators for int/real,
but you cannot write a polymorphic function over any kind of number without
using the module system. This is a key distinction. Standard ML does have a
notion of 'equivalence type variables', which is frequently seen as a wart
(since you often get an equality definition you might not be interested in).
Standard ML has nothing for 'comparable' types (except, again, through the
module system).

Offhand, I can't really think of any other language that uses builtin type
classes in the style of Elm.

~~~
Skinney
I guess Go is the only language which comes close, which has map and
array/slice which cannot be implemented in the language itself. Though it's
the lack of generics, not ad-hoc polymorphism which is Go's lack.

Then again, it wouldn't surprise me if of all the languages you've thought
about, Elm is the only one which hasn't reached 1.0 yet.

I think Elm will get some mechanism of ad-hoc polymorphism before it reaches
1.0, but I don't think it will be type classes. Though, I have been wrong
before.

------
hellofunk
> If you have ever tried to use ADVANCED_OPTIMIZATIONS in Google Closure
> Compiler, you know that this is extremely difficult even when you write all
> the code yourself

Perhaps, but it’s quite nice when you use languages that were built to support
Google Closure from the beginning, like Clojurescript. Then it is painless and
built into the build process automatically, and you get to benefit from all
the other great advantages of advanced optimizations in Google Closure that
this article does not mention, and which Elm still cannot support or offer an
alternative for, like automatic loop unrolling and other notable performance
improvements.

~~~
kylecordes
Leveraging what is already in Closure Compiler was (and is) such a brilliant
maneuver by ClojureScript - over the last few years I've seen various current
tools gradually gain optimizations that were already in the box with
ClojureScript when I built some things with it "forever ago".

The big surprise though, is how few other new
library/framework/platform/languages/whatever have followed this path.

~~~
digitaLandscape
Google Closure Compiler doesn't get any use because Google has entirely
neglected it for a decade. They could have been where TypeScript is today, but
instead they entirely ignored external users, hardly staffed the project, and
now have an inconsistent mess with a non-coherent super-buggy type system and
no users. It's a disaster, and if you try to do anything non-trivial it will
fall to dust.

Good riddance to that abandoned pile of rubbish, and fuck Google management
for letting it get so bad. They had a five-year lead on the rest of the
industry in serious JavaScript development, and now they're ten years behind.

~~~
hellofunk
10 years behind? There might be competitors (perhaps) but the Closure compiler
does quite a lot of impressive engineering -- not just the tree shaking and
identifier renaming that Elm is trying finally to do, but also automatic
function inlining, loop unrolling, numerous other performance tweaks. And it
all works fantastically, very reliable. I've been using it for 4 years on a
huge codebase and I've not once had a problem that was due to the Closure
compiler. It's robust and stable.

------
tonyhb
This sounds really cool, and it's exciting to see Elm come along!

I always feel like Bucklescript and the Ocaml ecosystem doesn't get enough
love when Elm crops up. Bucklescript has been doing aggressive dead code
elimination for some time, and comes with the full type system of ocaml — plus
easy JS interop: [https://github.com/BuckleScript/bucklescript/wiki/Why-
buckle...](https://github.com/BuckleScript/bucklescript/wiki/Why-bucklescript-
matters-for-Javascript-platform).

As Elm develops I'm finding it harder and harder to choose between
bucklescript/ocaml/reason and Elm. It's awesome to have all of these modern
tools to work with on the frontend.

~~~
hazza1
I've found the opposite, all the momentum seems to be with Reason - I don't
hear of many new people picking up Elm.

A release with smaller bundle is an amazing technical achievement but doesn't
really address the underlying language and ecosystem issues.

~~~
rtfeldman
> I don't hear of many new people picking up Elm.

We sure do in the Elm community! I suspect this has more to do with who you
follow than anything else. :)

For example, if you follow a lot of React folks, you're naturally going to
hear a lot more about Reason, because there's a lot of overlap in the people
who work on those projects.

Come check out our #beginners channel on Elm Slack sometime! It's constantly
buzzing with activity:

[http://elmlang.herokuapp.com/](http://elmlang.herokuapp.com/)

~~~
hazza1
True, probably a lot of bias in my environment but I interview a lot of people
for frontend roles - a couple of years ago Elm was the next exciting language
to learn, it's now more often than not Reason.

~~~
rtfeldman
The last time I interviewed someone who applied because they wanted to use Elm
in production was an hour ago.

Elm continues to be our #1 source of applicants, and none of them mention an
interest in Reason...but then again, it would make sense that Reason, being
newer and endorsed by Facebook, would have more interest in the overall JS
community!

~~~
jarcane
Honestly my love of Elm is part of why I'm completely uninterested in Reason
and the direction it's taken.

------
salimmadjd
I love Elm and I recommend it to everyone who wants to get into functional
programming, especially Haskell.

Additionally I'm glad .19 finally came out. But 18 months was really long.

I'm guessing this was a good release point to show some major benefits, and
I'm assuming that past 18 months was spent on more stuff that will come out
later which is not ready yet.

The main change seems to be a smaller codebase. Which is great. This is done
by dead code elimination and not including unused modules in addition of some
incremental size reduction by record field renaming (replacing
someReallyLong.name with s.n) . However some of the other concepts that
supposedly was going to improve SPAs etc. are not released yet.

~~~
chosenbreed
> Additionally I'm glad .19 finally came out. But 18 months was really long.
> On the basis that nothing was actually broken 18 months is not that long. I
> think there are benefits to be derived from working with a
> language/platform/ecosystem that doesn't change every few weeks. Just think
> about how many changes Angular has had in that time...

~~~
aarpmcgee
Not sure if "nothing was actually broken" is true... very few of the
dependencies from my 0.18 project work with 0.19.

~~~
Skinney
I think he was saying that during those 18 months of 0.19 development,
everything was stable.

0.19 is very much a breaking change.

------
thedanabrams
It’s been a long time coming but this is great. Thanks to everyone on the Core
Team, and especially Evan, for their hard work.

Can’t wait for what comes next, especially, hopefully, some interesting things
in Elm-Explorations.

------
dsiegel2275
Congratulations! I don't use Elm in production (yet), but have been following
it's evolution for the past few years, built a few small side projects with
it, and have gotten the chance to attend both Elm conferences. What a great
community and great piece of technology.

------
dhruvio
Congrats to the core team! I'm super happy to see 0.19. We recently went live
with a website that was fully written in Elm 0.18 (www.project6.com). I'm
excited to upgrade to 0.19 and take advantage of the new browser package. If
anyone is interested in learning more about the decision-making process behind
choosing Elm for that project, I discussed it during an Elm Town podcast
episode ([https://elmtown.audio/the-risk-of-elm-dhruv-
dang](https://elmtown.audio/the-risk-of-elm-dhruv-dang)).

------
deltron3030
One of the benefits of React and its components is that components built with
design and prototyping tools (e.g. Figma) translate well to it. You design
prototypes, test them, and translate the design components into react
components.

Elm seems more like a prototyping language itself, where you create your
architecture as you go, easy to refactor (and thus live test I guess). Those
of you who made the jump from React to Elm, did your approach to prototyping
and evaluating what to build change? Do you prototype less before you jump
into code?

------
wereHamster
> Note that the React library itself is 32kb. Just the library without any
> application code. The entire Elm RealWorld App is 29kb, so no amount of code
> splitting can make the React version smaller than the Elm version!

That's plain wrong. Code splitting doesn't work only on package level, it goes
all the way down to individual module exports (ie. constants or functions). So
it really depends on how well React is structured, and how well the minifier
can do static and dynamic analysis.

------
aczerepinski
I've dabbeled in Elm and have some trivial single static pages in Elm on one
of my sites. Is there a book or blog series anybody could recommend that's
less about the language and more about the practical steps of building a full
single page app in Elm? How does routing work, do you need JS to integrate
with your API, how to configure the compilation/build/deploy step, etc?

~~~
wheatBread
I updated the official guide ([https://guide.elm-lang.org/](https://guide.elm-
lang.org/)) to try to do a better job at that. It covers "routing" and JS
interop much more clearly I think. So I recommend starting there and then
asking around in the community if you run into anything!

------
hardwaresofton
They forgot Mithril[0] in the size comparisons -- I haven't seen anything
useful beat it in size/value ratio.

[0]: [https://mithril.js.org/](https://mithril.js.org/)

~~~
rtfeldman
The comparison was of RealWorld apps - you should contribute a Mithril one so
that comparison would be possible next time!

Here's the link:

[https://github.com/gothinkster/realworld/blob/master/README....](https://github.com/gothinkster/realworld/blob/master/README.md)

Have fun!

~~~
brlewis
Somebody started one but needs help finishing:
[https://github.com/barryels/realworld-
mithril/projects/1](https://github.com/barryels/realworld-mithril/projects/1)

------
protomikron
Since there are some Elm users in this thread, I'll ask here: What's currently
the best way to integrate an interactive map (i.e. zoom, pan, draw polygons,
etc.) into an Elm application (something like leafletjs)?

If I search for it, I find [https://package.elm-lang.org/packages/kennib/elm-
maps/latest](https://package.elm-lang.org/packages/kennib/elm-maps/latest) but
the examples are not working for me, it feels like some mouse events get
missed?

E.g. here: [https://kennib.github.io/elm-
maps/examples/Fullscreen](https://kennib.github.io/elm-
maps/examples/Fullscreen)

[edit]

Ok, it's not working for me on Firefox, but does seem to work better on
Chromium (although some tiles are not rendered, but that might also be a
server-side issue). Map support is crucial for me and was the reason I didn't
dive into Elm so far, but maybe the problem is resolved now?

~~~
rtfeldman
Custom Elements!

Check out this talk about how to do it:
[https://www.youtube.com/watch?v=tyFe9Pw6TVE](https://www.youtube.com/watch?v=tyFe9Pw6TVE)

For future reference, the quickest way to get questions like this answered is
in the #beginners channel on Elm Slack:

[http://elmlang.herokuapp.com](http://elmlang.herokuapp.com)

Tons of super helpful people there!

~~~
protomikron
Thank you for the quick response. Just out of interest are the examples
working for you? E.g. Leaflet's Hello World is just ridiculously simple and
short (if you check out the source): [https://leafletjs.com/examples/quick-
start/example.html](https://leafletjs.com/examples/quick-start/example.html)

I am searching for something similar in Elm. I'll head over to other channels
for more questions, thanks.

~~~
rtfeldman
I honestly have never used LeafletJS, so I'd be the wrong person to ask - I'm
just familiar with the technique to embed things like that in Elm
applications. :)

~~~
protomikron
No problem. :) I just wondered if you also have problems with my (Elm) example
link, i.e. the scroll (zoom) events seem to get missed. However I followed
your advice and headed over to the Slack channel.

------
korkota
awesome! what's next?

    
    
      > [_] Server-side rendering
      > [x] Tree shaking
      > [_] Code splitting
      > [_] Lazy loading
    

[https://github.com/elm/projects/blob/master/roadmap.md#how-d...](https://github.com/elm/projects/blob/master/roadmap.md#how-
do-i-make-a-single-page-app)

------
roadbeats
I’m an happy Elm user; but I wonder if it’s a worth investment to start using
Elm when we’re heading to a new ecosystem on top of WebAssembly. I use Go on
backend, and would feel satisfied when Go and Webassembly works together fine.

~~~
Skinney
WebAssembly is still far away from being any sort of default for web
development yet (if only because IE11 doesn't support it).

I also wouldn't be surprised if Elm compiled to wasm in the future.

~~~
dorian-graph
It's openly a desired/considered goal for Elm to compile to wasm.

~~~
Skinney
I know, I'm one of the people looking into it.

~~~
dorian-graph
Oh, haha! Cool.

------
G4BB3R
I've used Elm/Elixir(Phoenix) in production and it's currently the best stack
for web development IMHO

~~~
dogweather
What about SEO? Are there problems with that?

~~~
G4BB3R
Atm yes. But there is a trick. Backend can check the request if it is a
crawler (google, twitter and other bots) and serve a custom page for SEO. And
for normal requests serve the normal SPA

------
bobbby
Any upgrade guide? My 0.18 elm project doesn't seem to work with the latest
version and the links it tells you to go to don't exist.

This is pretty much consistent with my elm experience, I've never found it
professional enough to consider for a production application.

~~~
Skinney
It's in the release notes, as with every other open source project:
[https://github.com/elm/compiler/blob/master/upgrade-
docs/0.1...](https://github.com/elm/compiler/blob/master/upgrade-docs/0.19.md)

~~~
bobbby
Thanks

It explicitly says I'm not allowed to tell you that the auto upgrade doesn't
work for me and there's no details on how to do it manually.

 _Sigh_ I'll try again in a few months.. maybe.

~~~
masklinn
> It explicitly says I'm not allowed to tell you that the auto upgrade doesn't
> work for me and there's no details on how to do it manually.

Uh… what? All it says is that elm-upgrade exists but is an alpha, and issues
should be reported to the elm-upgrade repository.

~~~
bobbby
Error message states

 _Do not post about the alpha /RC version of elm-upgrade on reddit, twitter,
HN , discourse etc_

That's already an issue about alpha.elm-lang.org being broken, changing it to
point at package.elm-lang.org gets me further but the next set of errors are
so unhelpful I'm giving up.

~~~
masklinn
It's just telling you that it's pointless to post about issues on social media
because the tool is in alpha and is obviously going to fail in many cases…

~~~
leshow
Funny how it was recommended at the start of this thread, in light of that.

------
subbz
Seeing that and liking Elm I have to tell that GatsbyJS
([https://www.gatsbyjs.org/](https://www.gatsbyjs.org/)) outputs really fast
end-products. Is that possible with Elm too?

~~~
lsjroberts
Gatsby produces static html sites and then rehydrates them once loaded, which
is what makes it feel so fast. Elm dynamically generates the html.

There has been some work to generate static html from Elm -
[https://github.com/eeue56/elm-static-html](https://github.com/eeue56/elm-
static-html) \- and there's no technical reason I'm aware of that prevents it
from being taken as far as Gatsby does.

~~~
SupremumLimit
I've been doing some work on an Elm-based static site generator:
[https://korban.net/elm/elmstatic/](https://korban.net/elm/elmstatic/)

(It uses elm-static-html under the hood.)

------
mchahn
I love the message, but the messenger is a bit over-the-top (infomercialish).

>Just the opposite! The new compiler is quite fast!

------
revskill
How about server-side rendering ?

~~~
joneil
One possible approach is talked about in the latest Elm-town podcast:
[https://elmtown.audio/the-risk-of-elm-dhruv-dang](https://elmtown.audio/the-
risk-of-elm-dhruv-dang)

------
stesch
Does Elm rely on node.js and npm? Or is it usable without it?

~~~
rtfeldman
You don't need either to use Elm.

The only way Elm uses node is for `elm repl`, since that needs a way to
evaluate the compiled JS on the command line.

The only way Elm uses npm is for `npm install --global elm` - but that's just
as a convenient way to get a cross-platform installer. All it does is download
the `elm` executable and put it on your PATH!

