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

51–60 of 129 posts

Re: Small Assets without the Headache in Elm 0.19

#51

Post by jxxcarlson »

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…

Also: much faster compilation times and a parser combinator library (elm/parse) that for me is a game-changer. It makes live-rendering of LaTeX to HTML a reality. See https://medium.com/@jxxcarlson/elm-0-19-its-parser-and-minil...

Re: Small Assets without the Headache in Elm 0.19

#52

Post by digitalzombie »

spuz wrote: post #32
eksemplar wrote: post #11

Earlier quoted context omitted.

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

What is classless JavaScript? I don't understand how you had trouble doing things without typesafety but found that going from JavaScript to Elm is a step backwards? Maybe I'm missing something here?

> What is classless JavaScript?

Sounds like old school javascript. Either just functional programming or prototype inheritance.

Re: Small Assets without the Headache in Elm 0.19

#53

Post by toastal »

bobbby wrote: post #38

Any upgrade guide? My 0.18 elm project doesn't seem to work with the latest version and the links it tells you to go to don't exist. This is pretty much consistent with my elm experience, I've never found it professional enough to consider for a production application.

avh4 has a tool called `elm-upgrade`[0] that gets you 80% of the way there. It worked fine for 0.17 -> 0.18 for me and helped me upgrade some libraries for 0.18 -> 0.19. The dev branches worked during the 0.19 alpha phase, so I'm sure it will be released shortly.

[0]: https://github.com/avh4/elm-upgrade

Re: Small Assets without the Headache in Elm 0.19

#54

Post by jxxcarlson »

roadbeats wrote: post #27

I’m an happy Elm user; but I wonder if it’s a worth investment to start using Elm when we’re heading to a new ecosystem on top of WebAssembly. I use Go on backend, and would feel satisfied when Go and Webassembly works together fine.

At present, Elm compiles to javascript. But when the time is right, it will have other compilation targets as well, e.g Webaassmebly

Re: Small Assets without the Headache in Elm 0.19

#56

Post by digitaLandscape »

kylecordes wrote: post #26
hellofunk wrote: post #13

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

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

Re: Small Assets without the Headache in Elm 0.19

#57

Post by hellofunk »

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…

10 years behind? There might be competitors (perhaps) but the Closure compiler does quite a lot of impressive engineering -- not just the tree shaking and identifier renaming that Elm is trying finally to do, but also automatic function inlining, loop unrolling, numerous other performance tweaks. And it all works fantastically, very reliable. I've been using it for 4 years on a huge codebase and I've not once had a problem that was due to the Closure compiler. It's robust and stable.

Re: Small Assets without the Headache in Elm 0.19

#58

Post by hellofunk »

Skinney wrote: post #40
hellofunk wrote: post #35

Earlier quoted context omitted.

This is almost never a problem since you simply use normal externs file for whatever library you are using. You never take an external library and run it through the closure compilation process, only your clojurescript code is put through those optimizations.

> This is almost never a problem since you simply use normal externs file for whatever library you are using. "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 comp…

I guess it all boils down to how you want to spend your time. Elm typically requires at least 4x the lines of code and at least 10x the time of dealing compilation issues compared to Clojurescript. So ultimately I think this is just a question of a desired workflow in one language vs. another. Any time spent on Closure-related issues (which have never personally bit me on any project -- I just use the library itself as an extern file and everything has always worked with no effort), is made up for with the fast development cycle on Clojure projects. Even including the increased runtime debugging in Clojurescript vs. Elm, Clojurescript has always provided me a significant productivity advantage over every other JS-family toolkit.

Re: Small Assets without the Headache in Elm 0.19

#59

Post by bobbby »

masklinn wrote: post #47
bobbby wrote: post #43

Earlier quoted context omitted.

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

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

Re: Small Assets without the Headache in Elm 0.19

#60

Post by vimslayer »

Skinney wrote: post #34
roadbeats wrote: post #27

I’m an happy Elm user; but I wonder if it’s a worth investment to start using Elm when we’re heading to a new ecosystem on top of WebAssembly. I use Go on backend, and would feel satisfied when Go and Webassembly works together fine.

WebAssembly is still far away from being any sort of default for web development yet (if only because IE11 doesn't support it). I also wouldn't be surprised if Elm compiled to wasm in the future.

Most compilers that target WebAssembly can also target asm.js, which is compatible with IE.

AFAIK it's more about missing stuff like DOM access and GC that stands in the way.

Post reply on HN