Small Assets without the Headache in Elm 0.19(elm-lang.org) |
Small Assets without the Headache in Elm 0.19(elm-lang.org) |
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.
See
- Demo: https://jxxcarlson.github.io/app/miniLatexLive/index.html
- Blog post: https://medium.com/@jxxcarlson/elm-0-19-its-parser-and-minil...
Many thanks to Evan for this amazing release. The wait for it was very much worth while. Faster compiling, smaller asset size, and more. Yay!!
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.
type LatexExpression
= LXString String
| Comment String
| Item LatexExpression
| InlineMath String
| DisplayMath String
| SMacro String (List LatexExpression) (List LatexExpression) LatexExpression
| Macro String (List LatexExpression) (List LatexExpression)
| Environment String (List LatexExpression) LatexExpression
| LatexList (List LatexExpression)
| LXError (List DeadEnd)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!
Yep, that's it right there.
I wonder if there's some way we could make it clearer that Elm is not Haskell, and trying to use it like it's Haskell won't likely to lead to a good experience.
At any rate, thank you for the feedback! It's definitely an ongoing communication challenge since the two languages have so much syntax in common.
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.
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....
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.
A release with smaller bundle is an amazing technical achievement but doesn't really address the underlying language and ecosystem issues.
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:
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.
Of course it's more dramatic to find and discuss stark differences between "competing" platforms, but the boring truth here is that Angular and Elm are on the same side of the "should we be careful and methodical about development and change?" question.
Can’t wait for what comes next, especially, hopefully, some interesting things in Elm-Explorations.
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?
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.
There are quite a few books/courses/articles which examine various aspects of building an SPA.
Here's the link:
https://github.com/gothinkster/realworld/blob/master/README....
Have fun!
https://realworld-mithril.netlify.com/
I have minified and gzipped `main.js` and it end up around 26k.
https://github.com/barryels/realworld-mithril/projects/1
It's safe to assume it will be bigger when it's done, but who knows how much?
If I search for it, I find 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
[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?
Check out this talk about how to do it: 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:
Tons of super helpful people there!
I am searching for something similar in Elm. I'll head over to other channels for more questions, thanks.
> [_] Server-side rendering
> [x] Tree shaking
> [_] Code splitting
> [_] Lazy loading
On the other hand, Elm is not 1.0 yet. They are still breaking the ecosystem with new releases.
I also wouldn't be surprised if Elm compiled to wasm in the future.
AFAIK it's more about missing stuff like DOM access and GC that stands in the way.
This is pretty much consistent with my elm experience, I've never found it professional enough to consider for a production application.
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.
There has been some work to generate static html from Elm - 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.
(It uses elm-static-html under the hood.)
>Just the opposite! The new compiler is quite fast!
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!
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.
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 :)
All high-level programming languages are on board with abstractions, pretty much by definition!
The big surprise though, is how few other new library/framework/platform/languages/whatever have followed this path.
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.
Note that Elm has always appeared to work on the surface with advanced optimizations, but the bugs would creep in and show up eventually, and the official advice has always been not to use those optimizations.
Elm also outputs smaller assets than cljs+closure.
That being said, I do love cljs, having used it on numerous projects myself :)
The world is still 99% JS and 1% every compile-to-js language put together.
asm.js is different enough that it's just not about adding a seperate asmjs "compatibility" target. On the top of my head you don't have 64-bit ints or floats and I believe the way you call asm.js fns from/to JS is different from wasm. Adding asm.js support just for IE 11 wouldn't be worth the effort.
0.19 is very much a breaking change.
But this does look like a team that's focused on the needs of Google's internal customers? An external-focused project would have better docs and do more outreach.
[1] https://github.com/google/closure-compiler/commits/master
[2] https://github.com/google/closure-compiler/wiki/Releases
They all provide abstractions, but they're not necessarily on board with letting users build new abstractions. Go is famously absolutely not on board with it for instance. Elm significantly less so — and I think the more restricted use-case also makes the issue significantly less problematic, at least it was in my (admittedly limited) experience — but it's still way downslope from the likes of Haskell or OCaml.
That's not to say that there are not other issues, though.
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!
https://weblogs.asp.net/bleroy/crockford’s-2014-object-creat...
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.
However, they don't really solve any of the problems that Elm sets out to try and tackle. Do you have any examples?
Also these patterns certainly do not make any other languages obsolete, and as far as I'm concerned it doesn't solve _any_ of the problems with JS that people complain about.
Classes is only a tiny part of what's broken in JS.
TS (coupled to "JS, the good parts") saves the day though, but I have no idea how avoiding classes also somehow made you abandon the usage of a type system (whether Elm's or TS's) It all seems so unrelated.
Sounds like old school javascript. Either just functional programming or prototype inheritance.
The document I linked too contains the language and std-lib changes between 0.18 and 0.19, for the rest you use new packages.
If you don't want to upgrade that's fine, but you're literally staring at the information on what to do.
Uh… what? All it says is that elm-upgrade exists but is an alpha, and issues should be reported to the elm-upgrade repository.
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.
"almost never" and "simply use externs file (which you may or may not need to write yourself)" does underpin my point that you have to take care. I'm not saying it is necessarily difficult or takes a long time to get right, but it does require that someone makes sure everything survives the advanced opts compilation.
This has burned me on a past cljs project, it's not even a concern on my Elm projects.
I would say that Elm lets me refactor front-end code fearlessly. I can confidently rewrite abstractions that are so fundamental that I'd be stuck with them forever in a dynamically-typed language because the rewrite would be so much more costly.
It reminds me of when people say that Mongo is better than Postgres for prototyping because it doesn't have a schema. In my experience, the very concept of having explicit schema transformation as the schema changes is why I'd consider Postgres to be better for prototyping: it's precisely the time when your schema is changing the most.
Of course, if we could unanimously agree on these trade-offs, then we would all be using the same stack and there would be no dynamic vs static typing debates.
I still use Clojure as a backend language (I'll never give up Datomic) and while writing code in Clojure is usually faster, I spend much, much more time in debugging, often because of type errors, and especially after re-factoring. In Elm I spend more time up front, but less time overall.
I've been writing Clojure for six years now, Elm for three. There are definitely usecases where I'd pick Clojure(Script) over Elm, but for those usecases where it doesn't matter which of those you pick, I'd choose Elm any day of the week.
This is not to say Clojure(Script) is bad. In my opinion, Clojure and Elm are the best languages around.
To me, rather than principled, that just feels incomplete.
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.
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.
Elm is not going to change, however fortunately there are alternatives. Pick something like PureScript or GHCJS and move on like I did.
I now write Haskell professionally[1] both for frontend and backend, something that you'd be hard-pressed to achieve with the likes of Elm.
edit: I'm not saying Elm should change, the time for that is long gone. Just that the idea someone would want an interface (to do things like bound on generically) isn't that far fetched.
What makes you say that? Elm has yet to reach 1.0, anything can happen. It's not likely it will happen any time soon, however.
Because Evan has shown no interest in implementing a feature like what I'm describing.
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. :)
Standard ML has less need for type classes because it has a much more expressive module system, but it still can be extremely tedious to pass around module definitions all the time, which is why they added equality types when the language was originally designed. This is considered an ugly hack though, even by its own creators [0].
Definitely agree that folks should aim for better than type classes, especially due to complications around global instance coherence. One nice solution is modular implicits/instance arguments [1][2]. Tricky thing is to do it without adding too much complexity to the language.
I do wish that there would just be some acknowledgment that it's a hard, but real problem to solve for Elm's point in the design space, rather than just pretending it isn't there. It's ok just to say that you're not spending design capital on it at the moment due to more pressing issues!
[0]: https://github.com/SMLFamily/Successor-ML/issues/18
[1]: https://arxiv.org/abs/1512.01895
[2]: https://www.researchgate.net/profile/Dominique_Devriese/publ...
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.
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.