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

61–70 of 129 posts

Re: Small Assets without the Headache in Elm 0.19

#61

Post by kylecordes »

chosenbreed wrote: post #42
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…

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

Although many people have seared-in memories about the transition from AngularJS 1.x to Angular 2.0, since 2.0 the improvements and Angular have a lot in common with today's Elm release. The same code still compiles, to smaller and faster output. The few breaking changes or deprecations happen slowly, with plenty of warning, and very little effort to keep up.

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.

Re: Small Assets without the Headache in Elm 0.19

#62

Post by aarpmcgee »

chosenbreed wrote: post #42
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…

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

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

Re: Small Assets without the Headache in Elm 0.19

#63

Post by masklinn »

bobbby wrote: post #59
masklinn wrote: post #47

Earlier quoted context omitted.

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

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.

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…

Re: Small Assets without the Headache in Elm 0.19

#64

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

Re: Small Assets without the Headache in Elm 0.19

#65

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

Re: Small Assets without the Headache in Elm 0.19

#66

Post by comex »

undreren wrote: post #20
pdamoc wrote: post #14

Earlier quoted context omitted.

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

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.

Re: Small Assets without the Headache in Elm 0.19

#67

Post by innocentoldguy »

aczerepinski wrote: post #65

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?

I liked the Elm-related courses at Pragmatic Studio: https://pragmaticstudio.com/courses/elm

Re: Small Assets without the Headache in Elm 0.19

#69

Post by wheatBread »

aczerepinski wrote: post #65

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?

I updated the official guide (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!

Re: Small Assets without the Headache in Elm 0.19

#70

Post by skybrian »

digitaLandscape wrote: post #56
kylecordes wrote: post #26

Earlier quoted context omitted.

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.

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…

This is false. It's not abandoned. There are many commits per day and that wouldn't happen without a dedicated team [1]. There are frequent releases with impressive-looking changes [2].

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

Post reply on HN