Is parsing json still an ugly mess? That was what put me off actually using it for anything.
A Farewell to FRP
21–30 of 246 posts
Re: A Farewell to FRP
#22I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?
First page of the Elm guide covers it pretty well:
http://guide.elm-lang.org/
> No runtime errors in practice. No null. No undefined is not a function.
> Friendly error messages that help you add features more quickly.
> Well-architected code that stays well-architected as your app grows.
> Automatically enforced semantic versioning for all Elm packages.
Re: A Farewell to FRP
#23I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?
They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what?
So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.
Re: A Farewell to FRP
#24I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?
I don't know anything about Elm subscriptions yet. But there is a lot more to this stuff then just event emitters.
Things like:
* When an event/action/etc comes through, does it always call listeners synchronously? Can you change that and schedule events manually?
* How do you compose subscriptions/event handlers? This is usually the hardest part, and where simple event emitters really start breaking
* What about the lifecycle of the listener? What happens when it subscribes or unsubscribes? More importantly, what happens when the source that it subscribed to "shuts down"?
All of these things get pretty complicated and is the reason why various fields like FRP exist. Simple event emitters work immediately, yes, but they are a pretty terrible abstraction to build an app on.
Re: A Farewell to FRP
#25I like Elm but its development really seems to rely on a single person. I saw this post on elm-discuss which is a pretty good summary of my thoughts https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...
Yep every 'native' library needed arduous review process via github issues. I waited for over a month for elm overlords to approve my 'native use' library , they simply closed the issue.
Dropped elm for react and co. Now I have serverside rendering, code splitting, working debugger ect which was impossible with elm.
This was last year though so not sure if it is still the process. YMV.
Re: A Farewell to FRP
#26From the Lucid Synchrone paper referenced in the article:
"Synchronous languages are based on the synchronous hypothesis. This hypothesis comes from the idea of separating the functional description of a system from the constraints of the architecture on which it will be executed. The functionality of the system can be described by making an hypothesis of instantaneous computations and communications, as long as it can be verified afterward that the hardware is fast enough for the constraints imposed by the environment."
That sounds a lot like how functional programming works in a browser. If you assume function calls take zero time (or can be optimized so they're fast enough) then you end up with event handling and asynchronous I/O. Preemptive multitasking becomes a non-issue. But long-running computations (where you actually want to keep some CPUs busy for a while) need to be handled outside the system.
Re: A Farewell to FRP
#27I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?
The fact that you can immediately imagine how it works and think that it is a very simple comncept, makes the changes in 0.17 even more awesome.
It turned something that is in real life difficult to manage, compose and scale, into something not just easy to grasp, but also simple to read and safe to execute.
Congrats on everyone involved in making this release happen.
Re: A Farewell to FRP
#28Does Elm have any nice interfaces for common JS frameworks? (like reagent / om in clojurescript, or angular2 for dart / typescript)
elm-html gives you a very nice interface to virtual-dom, which combined with the Elm Architecture is all you need.
Re: A Farewell to FRP
#29Just out of curiosity. I'm trying to decide which client-side framework/language to dive into, and it seems that many people consider Om Next a really nice step forward, away from "giant blob of state". My (uninformed) observation is that Elm does things the way Om (previous) did it: is that correct? Is Elm aiming to incorporate Om Next's advantages?
Re: A Farewell to FRP
#30Does Elm have any nice interfaces for common JS frameworks? (like reagent / om in clojurescript, or angular2 for dart / typescript)
In general, you're unlikely to need them.
Instead of cobbling together disparate libraries for a virtual dom (React), state (Redux), immutability (Immutable.js), and types (Flow / TypeScript), the entire language and its core libraries are developed as a holistic (but still modular) unit. In this way, Elm is the BSD to JavaScript's GNU/Linux.
Strong typing and immutability are baked directly into the core language, elm-lang/html includes an efficient Virtual DOM, and Redux-style action / reducer cycles tend to naturally arise from "The Elm Architecture," and don't need significant support beyond what's already in the core language.
If you've bought into the React/Redux paradigm, it's worth giving Elm a shot: the entire language and core libraries are intentionally designed to more cleanly, reliably, and maintainably implement the same structure.