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.
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!
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.
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 :)
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!