51–60 of 92 posts
I wish the clojure compiler also had the explicit goal of making things easier like this...
I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…
> There are all sorts of transient states that a parent's component shouldn't have to care about. The problem with this way of thinking is that there are invariably things that you initially believe will be of no concern to the parent that later become concerns of the parent. It's tempting at that point to graft on some event system so the parent can watch the things that it now cares about, and then maybe you add so…
Traditional UI frameworks try to avoid sending events unnecessarily for performance reasons; they're designed so that each component can declare which events it's listening to and can start and stop listening as needed.
Perhaps Elm can make this work, so that unwanted events get filtered out so quickly that it's not a concern. Also, these days everything gets animated anyway based on things like scroll events, so apps are perhaps a bit more like video games that run at 60 frames/second regardless of what's going on, at least while they're in the foreground. And the browsers themselves perform a lot better.
But it shouldn't be hard to see why people who have experience building UI frameworks might be concerned about unnecessary event traffic, particularly on mobile where battery life is an issue.
Earlier quoted context omitted.
It looks like you can always avoid needing signals of signals by declaring one signal for each type , not a signal for each instance . All instances of the same message type can share a signal, as long as the messages contain a unique key to distinguish between objects, and the code that lives downstream filters events by key. It's much like a database-backed app where you don't dynamically create tables while your a…
No because you must might want a whole subgraph of dataflow associated with each instance. You are right you can perhaps do it with collection primitives as signals. Creating tables is appropriate for multi tenancy apps. Or apps that let you build apps, or analogously, a drawing program for graphics.
At the top level you might just have a single native signal for all events delivered to any child app.
But I agree that the ability to start and stop reactive sub-programs would be a useful thing.
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?
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
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 or Handlebars.
Earlier 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…
Earlier 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…
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 complete state in your head
2. When you define it as local state you risk conflicting with some state set in a different component
3. You still have to change state. If you define your state in your components you will also have to include all the state changing logic inside the component. Your components will become very hard to reason about. And what if two components uses the same state and both of them needs to update the state? You will need to put the same logic into two different components
4. You could say Relay fixes this, but Relay just handles one thing and that is state related to the server. We build applications that does a lot more than talking to the server. Changing the state of your application is a huge problem space and though Relay is cool technology I can not imagine anyone expressing and changing all their state using Relay. So you need some other concept(s) to change all the other state and multiple concepts for doing the same thing is harder to reason about
Personally I think local state is a bad idea and currently I also think Relay is too limited. When I jump into an application I need to reason about what state it handles. With a global state store I can do that. Then I need to know how that state can be changed. Ideally that should be one concept, but we usually have lots of concepts for changing state. Then I want to see how the UI is expressed. Components are great for that, except when they are filled up with state definitions and state changing logic.
So from my perspective I am also trying to contribute with a solution :-) www.christianalfoni.com/cerebral
Earlier quoted context omitted.
Reflex is great (and its author is a genius) but it's not really useful yet for non-desktop apps. Because Reflex + GHCJS is impossibly slow on mobile. As an experiment, try using chrome (iOS) or android to load this: obsidian.systems/reflex-nyhug/ or this: https://obsidian.systems/ They're both reflex apps. GHCJS is bees-knees. But unfortunately, minimizing-code-size/mobile-performance has not been a priority. (It's…
> 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.
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 is too small to support several Haskellish-AltJS compilers. Do we really want several perpetually nascent solutions?
> "One of the nice things about AltJS is that several languages can coexist in the same codebase."
Theoretically, you're right. But how many production code bases are there in AltJS-Haskell (vs. say, Clojurescript)?
I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…
This allows you to react differently to actions in each component if you want. You can check out the whole project here: https://github.com/brodo/MushroomCup/tree/master/elm
Earlier quoted context omitted.
What do you mean by "dynamic GUI"? As opposed to what other kind of GUI?
A GUI with n buttons and a button to add and remove additional buttons