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

91–100 of 129 posts

Re: Small Assets without the Headache in Elm 0.19

#91

Post by protomikron »

rtfeldman wrote: post #89
protomikron wrote: post #86

Earlier quoted context omitted.

Thank you for the quick response. Just out of interest are the examples working for you? E.g. Leaflet's Hello World is just ridiculously simple and short (if you check out the source): https://leafletjs.com/examples/quick-start/example.html I am searching for something similar in Elm. I'll head over to other channels for more questions, thanks.

I honestly have never used LeafletJS, so I'd be the wrong person to ask - I'm just familiar with the technique to embed things like that in Elm applications. :)

No problem. :) I just wondered if you also have problems with my (Elm) example link, i.e. the scroll (zoom) events seem to get missed. However I followed your advice and headed over to the Slack channel.

Re: Small Assets without the Headache in Elm 0.19

#92

Post by tomtheelder »

eksemplar wrote: post #71
spuz wrote: post #32

Earlier quoted context omitted.

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?

https://web.archive.org/web/20151029152324/http://ericleads.... 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 disadvan…

Many people (myself included) have never meaningfully used the OOP elements of JS you are referring to. The approaches listed above are common JS patterns and ones that I and I think most JS devs have used extensively.

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.

Re: Small Assets without the Headache in Elm 0.19

#93

Post by dhruvio »

Congrats to the core team! I'm super happy to see 0.19. We recently went live with a website that was fully written in Elm 0.18 (www.project6.com). I'm excited to upgrade to 0.19 and take advantage of the new browser package. If anyone is interested in learning more about the decision-making process behind choosing Elm for that project, I discussed it during an Elm Town podcast episode (https://elmtown.audio/the-risk-of-elm-dhruv-dang).

Re: Small Assets without the Headache in Elm 0.19

#94

Post by tonyhb »

This sounds really cool, and it's exciting to see Elm come along!

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.

Re: Small Assets without the Headache in Elm 0.19

#95

Post by comex »

rtfeldman wrote: post #76
comex wrote: post #66

Earlier quoted context omitted.

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

Elm handles those things the way Standard ML does, not the way Haskell does. 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.

> Elm handles those things the way Standard ML does, not the way Haskell does.

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.

Re: Small Assets without the Headache in Elm 0.19

#97

Post by hazza1 »

tonyhb wrote: post #94

This sounds really cool, and it's exciting to see Elm come along! 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 ha…

I've found the opposite, all the momentum seems to be with Reason - I don't hear of many new people picking up Elm.

A release with smaller bundle is an amazing technical achievement but doesn't really address the underlying language and ecosystem issues.

Re: Small Assets without the Headache in Elm 0.19

#98

Post by always_good »

hellofunk wrote: post #58
Skinney wrote: post #40

Earlier quoted context omitted.

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

Your whole reason for replying to the submission seems to be "heh, ClojureScript already had this, but better ;)" but I'll chime in to say that the differences between Clojure and Elm, having used both extensively, especially become apparent when it comes time to refactor.

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.

Re: Small Assets without the Headache in Elm 0.19

#99

Post by rtfeldman »

comex wrote: post #95
rtfeldman wrote: post #76

Earlier quoted context omitted.

Elm handles those things the way Standard ML does, not the way Haskell does. 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.

> Elm handles those things the way Standard ML does, not the way Haskell does. 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 use…

> use of dictionary passing as a substitute for typeclasses

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

Re: Small Assets without the Headache in Elm 0.19

#100

Post by tonyhb »

hazza1 wrote: post #97
tonyhb wrote: post #94

This sounds really cool, and it's exciting to see Elm come along! 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 ha…

I've found the opposite, all the momentum seems to be with Reason - I don't hear of many new people picking up Elm. A release with smaller bundle is an amazing technical achievement but doesn't really address the underlying language and ecosystem issues.

That's reaffirming to hear. I love reason! Work has been BUSY and unfortunately haven't been able to keep up with the changes. Thanks for the heads up :)
Post reply on HN