Apparently the web site is having some issues?
Google cache:
http://webcache.googleusercontent.com/search?q=cache:http://...
Making Elm faster and friendlier in 0.16
81–90 of 92 posts
Re: Making Elm faster and friendlier in 0.16
#82Earlier 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…
It seems backwards to me to optimize a language for newbies.
Re: Making Elm faster and friendlier in 0.16
#83Earlier quoted context omitted.
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 a…
This is really interesting, we have very different perspectives on how to consume how an application works. Not saying you are wrong at all, just have different perspective :)
1. When I say "global state" I mean the actual state, actions and signals are state changers, not state. A global state store looks like this:
{ admin: { users: [], showConfig: false }, home: { isLoadingNotifications: false, notifications: [] } }
This is one file. If you use local state this example would be split into maybe 3 different files. I think we both agree it has to do with how many files you need to look into. And the amount of composition you need to do in your head.
2. It would be interesting to see Om Next in JavaScript syntax, too much brainpower going into trying to read Clojure :) Not because it is bad, just have not learned it
3. That is true, but now it is conceptually no different than signals/actions and for that very reason. You should look into a different file to read the state change. I think it is a good thing. State changes are often very complex, surprisingly complex. They should not be inside a component. I think a component should only be about rendering UI. State changes should be expressed by a different layer.
So what I think is interesting here is that we seem to look at the app from two completely opposite sides. I do not care about the components to understand my app, because they just express its output, the UI. My app is really the state defined and the way it changes that state. What I do care about though is having dumb components is that makes me able to do universal apps, just move my app to a new UI output like react-native etc.
It will be really interesting to see how Om Next affects the JavaScript community. We are good at getting ideas from other languages and practices, where Elm is a good example :)
Again, not stating that you are wrong about anything. It is nice to go into a component and understand how that component works. Its just in my experience really bad to use a "view" as a container for state and business logic. That said it is really important to be open minded and I hope to see us grab ideas from Om Next. Actually trying to inspire creator of Baobab to bring in some new ideas :-)
Re: Making Elm faster and friendlier in 0.16
#84Earlier quoted context omitted.
Local component state is the new two-way data binding. Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it. If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow c…
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…
Have you tried Freezer.js?
https://github.com/arqex/freezer
It is a global store that can be modified inside of the components safely, as if it was component's local state.
A change anywhere in the store will trigger an update event at the top of the store, notifying the rest of the app. So if you use a part of the freezer store as local state for your component, you'll get both requirements:
* Any change to the local state will rerender your component - ease of use. * Your component's local state won't be hidden anymore. You will be able to access it from outside the component.
Re: Making Elm faster and friendlier in 0.16
#85If 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.
That's true, although I see no reason Elm couldn't be compiled to server-side JS running in Node.
I'd love to see some full stack solution that would abstract away separation between backend and frontend (like Meteor perhaps) using some sane programming language and architecture.
Having built lots of SPAs and APIs serving as a backend for them I always feel that what's really relevant is modelling your data and domain logic (which tends to happen on a server side) and the UI consuming this data on the other end. Everything in between – endpoints exposing the data on the backend, frontend machinery to pull that data into client – seems to be totally arbitrary and implementing it is nothing short of a grind.
Re: Making Elm faster and friendlier in 0.16
#86Earlier quoted context omitted.
Yes ... but with a more natural implemention. That style won't scale up to real dynamic programs though without significant routing infrastructure outside of Elm's typical constructs.
Naturalness as a criterion for evaluating languages is not that compelling to me. I think a honest word for what people usually mean when they say "natural" in this context is the word "familiar". I know plenty of programmers who think that OOP is just more "natural" than FP. What I really would like to see is a counter example. Some GUI that just can not be done in Elm.
> What I really would like to see is a counter example. Some GUI that just can not be done in Elm.
I'm on the Elm/FRP fence myself but your comment here reeks of turing tarpit:
"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy."
Re: Making Elm faster and friendlier in 0.16
#87Earlier quoted context omitted.
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?
Nope, just that the effort required to wrap something in a nicer architecture sometimes outweighs the benefits you'd get from the upgrade. This was one of those cases.
Re: Making Elm faster and friendlier in 0.16
#88Earlier 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. :)
Don't feed the troll. While @ablesearcher's obviously part of the Elm community, he's using a throwaway account to vomit angry rubish on HN.
Re: Making Elm faster and friendlier in 0.16
#89Earlier quoted context omitted.
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. :)
Don't feed the troll. While @ablesearcher's obviously part of the Elm community, he's using a throwaway account to vomit angry rubish on HN.
Not everyone disagreeing is a troll.
Re: Making Elm faster and friendlier in 0.16
#90Earlier quoted context omitted.
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. :)
Don't feed the troll. While @ablesearcher's obviously part of the Elm community, he's using a throwaway account to vomit angry rubish on HN.
When did evidence-backed criticism become synonymous with trolling? Also, which statement exactly was angry? (Let alone rubbish? Or, gasp, vomit?)
It seems you want all Elm news to be positive Elm news. So does the language's author. In fact, when addressing the announcement re: Hacker news, he wrote this:
"Just an FYI, if you go to a HN post via direct link and vote on it, those votes either do not count or are used as demerits because it indicates that people are trying to artificially boost things. I guess getting a kickstarter to the top of HN can be worth a lot of money, so they try to protect against voting rings."
(See https://groups.google.com/forum/#!topic/elm-dev/NQxML4HA4X8 )
Civility is important. But so is the honest, unfettered exchange of ideas.