Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small Assets without the Headache in Elm 0.19

elm-lang.org

Post reply on HN
Print view View original

11–20 of 129 posts

Re: Small Assets without the Headache in Elm 0.19

#11

Post by eksemplar »

antew wrote: post #3

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.

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.

Re: Small Assets without the Headache in Elm 0.19

#12

Post by rtfeldman »

doctor_stopsign wrote: post #8

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…

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

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.

Re: Small Assets without the Headache in Elm 0.19

#13

Post by 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.

Re: Small Assets without the Headache in Elm 0.19

#14

Post by pdamoc »

doctor_stopsign wrote: post #8

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…

> 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.

Re: Small Assets without the Headache in Elm 0.19

#16

Post by lsjroberts »

subbz wrote: post #7

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

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 - and there's no technical reason I'm aware of that prevents it from being taken as far as Gatsby does.

Re: Small Assets without the Headache in Elm 0.19

#18

Post by lsjroberts »

salimmadjd wrote: post #10

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 i…

The SPA improvements look to have been released as the new `Browser` package, there's some good stuff in the guides on it - https://guide.elm-lang.org/webapps/

Re: Small Assets without the Headache in Elm 0.19

#19

Post by baublet »

doctor_stopsign wrote: post #8

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…

Concur. Elm is an excellent addition to one's development quiver. Its strictness made me a far better, more careful programmer, and the push toward functional, side-effect free programming styles (something also coming from the React community) has been a huge boon to the JS world. Loving the current state of JS!

Re: Small Assets without the Headache in Elm 0.19

#20

Post by undreren »

pdamoc wrote: post #14
doctor_stopsign wrote: post #8

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…

> 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 d…

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

Post reply on HN