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

Making Elm faster and friendlier in 0.16

elm-lang.org

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Making Elm faster and friendlier in 0.16

#71

Post by rtfeldman »

ablesearcher wrote: post #68
rtfeldman wrote: post #63

Earlier quoted context omitted.

That's not at all disingenuous; the two are completely unrelated. :) The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not. In this case I didn't think the extra work required to wrap the DOM API for cursor position would be worth the trouble. That's certainly not an endorsement…

> "The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not." > "Local component state is the new two-way data binding. . . If you listen to people who have spent a lot of time with both systems, what you hear are a lot of single state atom converts and not a lot of people saying "y…

Hm...my response was the exact opposite of that. Maybe I need to rephrase?

In bullet points:

1. Yesterday someone presented a case where they needed to interact with a DOM API that used local state.

2. I didn't think it would be worth the trouble to wrap that API.

3. That is not an endorsement of local component state.

Hopefully that clears things up. :)

Re: Making Elm faster and friendlier in 0.16

#72

Post by ablesearcher »

brodo wrote: post #65
ablesearcher wrote: post #49

Earlier quoted context omitted.

That might solve the cursor issue, but it's a bigger issue than cursor state. The real issue is that Elm doesn't treat its programmers like grown-ups. That sounds harsh, so let me explain . . . I've drank enough of the Haskell Kool-Aid to realize that, despite the surface discourse, Haskell is not about religious devotion to purity and lazy-evaluation. It's about managing side-effects, and being honest about them in…

Evan has described a lot of the thinking behind his decisions in this talk: https://www.youtube.com/watch?v=oYk8CKH7OhE The <~ for Signal.map is a good example for a "clever" thing which makes languages hard to read for newbies. It looks like it's part of the syntax and not a function. It's not hard to understand, but it's another thing to learn. I am very happy that things are removed from Elm (or not added in the f…

I've seen Evan's talk. Evan confuses the presentation of features with the value of those features. (I suppose one could solve the difficulties people have in learning Mathematics by throwing out everything after Algebra I; another solution, however, might be to do a better job teaching the more difficult stuff.)

Just because you shouldn't expose new programmers to advanced concepts on the first day doesn't mean they shouldn't be a part of the language. Similarly, the fact (I'm sympathetic to the concern that some code is too "clever" or dense; but Elm swings the pendulum too far.

(Btw, type-classes are not incidental complexity:

https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=hIZxTQP1ifo )

Re: Making Elm faster and friendlier in 0.16

#73

Post by rtfeldman »

boubiyeah wrote: post #35
rtfeldman wrote: post #30

Earlier quoted context omitted.

Here's a long-form answer to both questions. :) https://www.safaribooksonline.com/blog/2015/10/29/react-loca...

Fine article... But all that it tells me from my experience is that it's a good thing to put 80-90% of the app state in a central atom :p A good practice or rule of thumb is just that, it shouldn't always be the only way to do things.

Flexibility is a fine rule of thumb, but opening the door in those 10% of cases costs you things like time travel.

Quite a price tag! :)

Re: Making Elm faster and friendlier in 0.16

#74

Post by beefsack »

rudolf0 wrote: post #55
bribri wrote: post #34

Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though

Can something like JSX be used with this? It looks like a cool language, but I was never able to get behind HTML "DSLs". Their only advantage is ease of implementation and that you get to write in your current language, at the expense of write/read verbosity and comprehensibility. Even Jade/HAML/Slim I'm ok with, since they're a terse iteration on HTML rather than a nested monstrosity of code blocks. But I prefer JSX…

I'm yet to see strong objective reasoning either for or against JSX, it seems to really polarise people. From an Elm perspective, I feel that the HTML API is well designed and doesn't get in the way, so I'm not entirely fussed.

Re: Making Elm faster and friendlier in 0.16

#75

Post by rtfeldman »

boubiyeah wrote: post #31
jmite wrote: post #17

Earlier quoted context omitted.

It seems to work for NoRedInk and CircuitHub...

It is also possible to write the most complex app ever using just vanilla Javascript/JQuery too, but it's not viable or fun to maintain. The elm language brings a lot of value compared to the very unsafe javascript; I'm only questioning the validity (or immaturity) of the component architecture.

My thoughts on this based on experiences using Elm at scale at NoRedInk: https://twitter.com/rtfeldman/status/667419654370033664

Re: Making Elm faster and friendlier in 0.16

#76

Post by galfarragem »

ablesearcher wrote: post #58
purescript wrote: post #40

Earlier quoted context omitted.

> I wish all these alt-JS-haskellish language authors (of PureScript, Elm, Roy, etc.) would just work on making GHCJS better. All three of those have very different goals and trade-offs from GHCJS. I agree that it would be nice to share more work/knowledge though. One of the nice things about AltJS is that several languages can coexist in the same codebase.

> "All three of those have very different goals and trade-offs from GHCJS." And therein lies the problem. In my view, the most important goal is to have at least one really good AltJS-Haskellish language with a fully-featured ecosystem of libraries. (I'm fine if that language is PureScript, btw. PureScript is fantastic.) The problem -- which Clojure and Scala programmers seem to have sorted -- is that our community i…

Normally very smart people have an huge ego and hate politics. It's always a pity to see so much potential wasted.

Re: Making Elm faster and friendlier in 0.16

#77

Post by findjashua »

methehack wrote: post #11

I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?

I used to be a Reflux fan myself, but baobab (Om architecture) has scaled much better for us, in terms of code as well as devs who are new to React/Flux.

Re: Making Elm faster and friendlier in 0.16

#78

Post by nwienert »

christianalfoni wrote: post #57
nwienert wrote: post #36

Earlier quoted context omitted.

Actually, you do see a lot of questions and problems with the single state atom. In fact, I'd argue it's inherently a side step towards a future that has the best of both worlds: encapsulated state within components, but backed by some global state store invisibly. This is exactly what Relay is by the way. You component asks for state, and gets it from a server. The fact that it comes through props is actually just a…

Hi there, I do not quite agree with this. Though I acknowledge your sentiments :-) 1. Global state is easier to reason about. If you have a single state store expressed as a single object you only have to read one file to understand the complete state of your application. If you let local state express the state and the global state is invisible you have to look into all these local state files and compose the comple…

Good points. A response:

1. Global state is easier to see on a high level, but harder to reason about. Local state is inherently easier to reason about: it's right there. Global state requires me now looking at actions/signals, global state structure, and then my component, and resolving the three.

2. They should definitely be synchronized, this problem is only specific to local state implementations today. If they aren't synchronized, thats simply at the lack of the system you're using. I'm not familiar with Om Next, but I'd guess it handles this for you (as could any system properly organized).

3. Not true. You could have state changing functions imported and used by multiple components. This is also easier to understand, in my opinion. I can see where the state is located, and still keep my shared state changing functions somewhere.

I do think local state is skewed negatively now because it's very poorly done. React, angular, all systems today make local state a total pain, opaque, and hard to work with. Om Next seems to be a step forward (I'm working on something somewhat related for JS that should make it better as well).

Re: Making Elm faster and friendlier in 0.16

#79

Post by ac2u »

garyclarke27 wrote: post #29

If Elm had a dedicated library for io with Postgres functions (stored procedures) would then become very attractive to my company, for a very ambitious project we are developing. we store all state and logic inside db safely firewalled by stored procs, so i'm looking for UI focused language/ toolset that is productive, functional and produces atractive ultra reliable, performant html js. I don't feel good about the S…

I don't understand, elm is for your browser based application, which can't communicate with postgres anyway except through a web server sitting in the middle.

Re: Making Elm faster and friendlier in 0.16

#80

Post by nwienert »

rtfeldman wrote: post #71
ablesearcher wrote: post #68

Earlier quoted context omitted.

> "The DOM uses local state extensively, and sometimes you need to interact directly with its API. When you do, you can either do more work to translate it into your preferred architecture, or not." > "Local component state is the new two-way data binding. . . If you listen to people who have spent a lot of time with both systems, what you hear are a lot of single state atom converts and not a lot of people saying "y…

Hm...my response was the exact opposite of that. Maybe I need to rephrase? In bullet points: 1. Yesterday someone presented a case where they needed to interact with a DOM API that used local state. 2. I didn't think it would be worth the trouble to wrap that API. 3. That is not an endorsement of local component state. Hopefully that clears things up. :)

So basically you think it's ok to use local state, but only for DOM related stuff?
Post reply on HN