
Asset minification with Elm (2018) - lelf
https://elm-lang.org/news/small-assets-without-the-headache
======
pictur
Has anyone started a project with elm and continued it for a long time?

~~~
Chadtech_Real
I have been writing Elm for 5 years now. I work at Humio, where our front end
is 100k lines of Elm code.

What would you like to know? I love Elm. I'm absolutely hooked. I don't want
to go back to doing Frontend work in JS, and I hope one day there can be an
Elm-like experience for backend development as well.

Just off the top of my head a few bits of what I like about Elm: \- You can
actually write code, have no errors, and then move on, and never return to the
project again. When I was doing JS, everyone I knew just took it for granted
that you would be maintaining everything you ever wrote for the rest of your
career. Not with Elm! You can actually finish projects and never return to
them. \- Its a simple and small language that is designed to interact with
human beings. The compiler really talks to you instead of spitting out error
codes or spaghetti. Apis and variables have human readable names instead of
mathy terms of symbols. \- For everything theres one way of doing things and
the one way is usually really good. This strong consensus orientation of the
Elm community means everyone is speaking the same language about every
problem.

Gotta go, bye.

~~~
no_wizard
I'm curious if you tried out ReasonML[0] at all, for any length of time,
before Elm, or even after.

[https://reasonml.github.io/docs/en/what-and-
why](https://reasonml.github.io/docs/en/what-and-why)

I've really been digging slowly into ReasonML and the biggest gain I can see
is that valid reason === valid ocaml (and there's some good server libraries
out there for ocaml)

I also like that JSX is the templating language, not that it matters.

Also, have you had any success with manipulating Elm to output static HTML/CSS
as well as JS? I know it can do it, but I've never been able to manipulate how
it does it (most recent version I tried with: 0.18)

~~~
Chadtech_Real
I havent actually written any ReasonML, but I once had to review some my
former coworker wrote. Thats the extent of my ReasonML experience, so I dont
have much of an opinion. However, I was surprised that the ReasonML code I
looked at relied on impure functions. I like pure functions so that scares me
off a bit from the OCaml as a whole.

Regarding static html/css, I havent done that either, so I dont know about it.

~~~
yawaramin
> the ReasonML code I looked at relied on impure functions. I like pure
> functions so that scares me off a bit from the OCaml as a whole.

ReasonML (OCaml) allows impure functions but the best practice is to stay pure
whenever possible. It's a very pragmatic language so despite providing all the
functional and immutable programming features, it allows you to cut through
the bureaucracy if you need to.

------
bastawhiz
I don't want to downplay Elm's accomplishments here, but I really disagree
with the "RealWorld" example here. Does a 29kb asset make a meaningful
difference compared to a 100kb asset? Especially if the framework is a fixed
chunk of that, the space savings as the project grows in size is not
incredibly meaningful in the grand scheme of things. 50kb of excess code on my
page due to missed optimizations isn't going to keep me up at night.

A more meaningful comparison would be "we ported these actual production apps
to Elm and here's the difference." Finding comparisons between languages like
Elm and JS often feels like an exercise in microoptimization: I don't care if
it can update the DOM 20% faster if React or Angular already does it within
16ms, or if the download time for my bundle is reduced by 50% if it already
loads in 200ms for my 95th percentile. What's going to get me interested in
tools like Elm are solutions for actual issues that I'm toiling over, like
providing better tools for mocking in tests, ways to build custom lint rules
that don't involve me becoming a metaprogramming expert, isomorphic rendering
without heartache, etc.

~~~
weavie
Microoptimizations performed by someone else is only really a problem if they
sacrifice something else to acheive them. So if it meant that writing Elm code
was a horrendous buggy experience in order to achieve that extra 50kb, then
sure that's a problem.

But when its added on top of a really pleasant development experience then you
don't really need to to think about it too much. All it really is saying is
that you aren't paying for it with extra code bloat.. Which is a great thing!

~~~
bastawhiz
I don't disagree that it's a net positive. My point is that aside from being a
post about the technical accomplishments of Elm, it does little to sell me on
changing my tools and language. I don't doubt that Elm is pleasant to work
with, but I find React really pleasant to work with.

If the goal is to convince me to learn a new language for the weekend and play
with it, telling me how I can save 50kb isn't huge motivation. Seeing actual
examples of real world benefits are compelling for me, not artificial samples.

------
galfarragem
Elm is not consensual but is definitely influential specially considering the
small investment involved. From the top of my mind:

\- TEA (the elm architecture) -> Redux

\- Elm compiler error messages -> Rust error messages

Elm's BDFL, according to his talks or his twitter account, seems to be a
thinker, not a politician. Every new release brings something new. I wonder
what 0.20 will be.

~~~
azangru
> Every new release brings something new.

Elm giveth, and Elm taketh away. I remember seeing stories about how new Elm
versions removed some bits of functionality available in the previous
versions...

~~~
jweir
It is true. Elm has taken some syntax away and native packages, and made the
language better by being simpler and error free (I have never had a runtime
error).

Upgrades since 0.17 have been pretty easy too - there is automated tooling
that does the heavy lifting.

~~~
pyrale
Migration ease really depends on your use case. I am currently doing the
upgrade on a production application, and some changes (dates,
navigation/fullscreen) have been a pain.

The more automatic stuff that can be caught by the compiler is usually a
breeze, though.

------
Semiapies
Describing this as just "minification" downplays the compiler improvements,
here.

~~~
MichaelGlass
Agreed.

But ... minification is totally relatable and "better error messages" is less-
so. The problem with benchmarks is they over-emphasize things that are
measurable. Honestly, I don't care as much about binary size as I do about,
e.g. maintainability. But the latter is harder to quantify.

It's not Elm's fault they have to play that game. People search for, "fastest
javascript framework" when maybe that's not what they actually want. Maybe all
they want is a good friend.

~~~
pyrale
I don't really care about errors. That is important for newcomers but after
sometime people eventually learn idiosyncratic stuff in languages. The
motivating part of .19 is the improved compile times.

