I wonder if it is also possible in elm to perform layout-dependent logic. For example: show a piece of text horizontally, but if it is too wide (in pixels), show it vertically.
The Elm Architecture
21–30 of 38 posts
Re: The Elm Architecture
#22Earlier quoted context omitted.
The trouble though comes about once you have to start working with a UI library. It's a mess and a half unless you use C++. I'd like to try using Elm, or Purescript for UI work using atom-shell or nw.js. That opens almost the same can of worms (how easy it might be to 'bind' your engine to your UI/view). I've written a non-trivial application using QtWebkit entirely for the UI and it was a very agreeable experience.…
Actually that I my opinion from any web based UI, a mess of JavaScript/CSS trickery and HTML. Native UI development feels so much more advanced and user friendly. Saying this as a UX developer since the mid-90's.
My comment was in reference to using native toolkits from a language other than C++ and not the status of using native toolkits in general. I have a hard time believing that you've been using native UI toolkits using Haskell since the mid-90s. :)
Re: The Elm Architecture
#23Wow, that looks like COBOL.
Re: The Elm Architecture
#24Earlier quoted context omitted.
Actually that I my opinion from any web based UI, a mess of JavaScript/CSS trickery and HTML. Native UI development feels so much more advanced and user friendly. Saying this as a UX developer since the mid-90's.
My comment was in reference to using native toolkits from a language other than C++ and not the status of using native toolkits in general. I have a hard time believing that you've been using native UI toolkits using Haskell since the mid-90s. :)
No, but I was using Turbo Pascal followed by Delphi. Also played with C++ Builder, but by then Visual C++ had taken over as Borland was going through their Inprise phase.
Re: The Elm Architecture
#25I've been thinking of giving Elm a go, and this walk-through is very helpful in breaking the initial barrier. Exciting to see these ideas finally giving us answers on how to do user interfaces on the web right.
ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way bound callbacks in plain React, Actions when using Flux).
I have a question for anyone who've worked with both Elm and React. It seems to me that these ideas (component model, well-defined mutation point for state, composability, one-way binding etc.) are what matters more than the language itself. Granted that the language can influence how code is written (immutability, pure functions, ..), but does Elm (or ClojureScript for that matter), drastically improve creation of typical user interfaces just by virtue of the language?
Re: The Elm Architecture
#26Wow, that looks like COBOL.
I've programmed COBOL for a living back when it was still fashionable and I don't think it looks like COBOL at all, what specifically triggers your 'looks like' bit?
Re: The Elm Architecture
#27I've been thinking of giving Elm a go, and this walk-through is very helpful in breaking the initial barrier. Exciting to see these ideas finally giving us answers on how to do user interfaces on the web right. ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way boun…
When there was no React.js, I had in mind something like that and implemented a very simple concept like this with ghcjs. Functional languages tend to let you write this kind of code.
It felt very organized and just worked, then I looked at Elm and said: "that's exactly what I thought I'd do with ghcjs". Then with react.js: "finally somebody implemented the concept in plain javascript". Which is after all a kind of stricter mvc model for the single-page web applications. The fact is that with an haskell-like language, the kind of mvc concept is much more structured, you do less design mistakes because the language itself constraints the effects. So what react.js did is adding these constraints on top of plain js in an elegant way.
In other words: I think the addition of elm is the language itself, for those acquainted with haskell and where type checking matters a lot, compared to plain js.
On the same path, there are other libs similar to react.js that are even faster because they have stricter requirements on how data is mutated.
Re: The Elm Architecture
#28Re: The Elm Architecture
#29Earlier quoted context omitted.
I've programmed COBOL for a living back when it was still fashionable and I don't think it looks like COBOL at all, what specifically triggers your 'looks like' bit?
The separate sections for data definitions, forms, etc.
Ah, the 'divisions'. Right, I see what you mean. Quite a few languages have such 'divisions', though they're not usually explicit. For instance, C code usually has a bunch of include statements at the top, followed by internal structure declarations followed by function definitions.
We don't name the sections there but they might as well have names (you can include a file in the middle of another but that's pretty bad form). Other languages are more formal (for instance Modula-2, Erlang, Ada). That's not a COBOL specific thing.
Re: The Elm Architecture
#30I've been thinking of giving Elm a go, and this walk-through is very helpful in breaking the initial barrier. Exciting to see these ideas finally giving us answers on how to do user interfaces on the web right. ReactJS has also converged into the ideas proposed by Elm: the Model is explicitly defined (props and state); view is always a function of the Model; and the Model is mutated only through Signals (one-way boun…
When there was no React.js, I had in mind something like that and implemented a very simple concept like this with ghcjs. Functional languages tend to let you write this kind of code. It felt very organized and just worked, then I looked at Elm and said: "that's exactly what I thought I'd do with ghcjs". Then with react.js: "finally somebody implemented the concept in plain javascript". Which is after all a kind of s…
Thanks a lot for the response. Your comment about constraints improving design makes a lot of sense.
As to libs similar to React, I assume you're talking about Mercury and Mithrill. But I'm quite happy with React's performance and escape latches (shouldComponentUpdate). I'll however switch in a heartbeat if a better design comes along.
The problem is that unlike when I was mutating DOM with spaghetti JS or wrangling with Angular, I am yet to say "why is this thing so darn difficult" with React for almost all use cases I've thrown at it (yet to figure out animations). And the last React.js Conf has taken care of most things that I could imagine improving in web development with Relay and CSS in JS.