4 ms·

As I alluded to I think the HTML version is less weird because it is close to what you're going to see when you open your browser DevTools. So the JSX/HTML styl

by allover 10y ago

As I alluded to I think the HTML version is less weird because it is close to what you're going to see when you open your browser DevTools. So the JSX/HTML style requires less mental gymnastics overall. Also there are some things about Elm's DOM style in particular that are especially awkward, compared to other function-style dom creation syntax [0], like the [ ] everywhere. > The main difference is that the Elm "bracket soup" is just a composition of functions So is the JSX counterexample I gave, (it de-sugars to function calls), which is why elmx [1] can exist, and seems like an improvement to me. [0] https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript [1] https://github.com/pzavolinsky/elmx https://github.com/pzavolinsky/elmx

ollysb 10y ago
Prior to Elm I spent 5 years building front end apps using ember.js(handlebars templates) and then JSX with React. From memory it took me about 2 days to get used to Elm's approach. Once you get used to have the full power of a programming language to build your view going back to using templates honestly feels painful by comparison. Aside from the power of having a full language available you also get the benefit of static typing. Refactoring your views with the same ease that you do with your normal code and with a compiler to watch your back is liberating. I wasn't aware how cautious I was with refactoring view components until I tried the alternative.
- allover 10y ago
  JSX is a language extension which desugars to JavaScript. It is not the same as 'going back to templates'. > Refactoring your views with the same ease that you do with your normal code and with a compiler to watch your back is liberating I have this experience with JSX (which I didn't have with string template libs), and I also don't see that an Elm equivalent like elmx would take anything away from that experience in Elm.
nilkn 10y ago
I still think you're trying to prematurely optimize against your very first impression of seeing a new syntax for a familiar data structure. I've actually written several thousand lines of Elm code for a real internal tool at work, and elmx feels like it just complicates the view code with virtually no benefit. I think it's solving a problem that doesn't exist -- and not at zero cost. The result won't be understood by elm-format. Compiler errors will exist at the level of Elm, not elmx. It's something extra that has to be learned by any other developer trying to work on the code -- and they'll still have to understand the pure Elm code that the elmx compiles to as well. Plus it has limitations like not being able to nest code interpolations.
- allover 10y ago
  > you're trying to prematurely optimize against your very first impression [...] No I'm not, and I'm tired of 'the familiarity argument'. > elmx feels like it just complicates the view code with virtually no benefit. See my other comments in this thread - I don't agree - JSX being more closely related to the DOM you're building is a significant benefit. Also empirically in React land, JSX is vastly more popular than not using it. > The result won't be understood by elm-format. If ESLint can understand JSX, then elm-format can understand elmx. > It's something extra that has to be learned by any other developer trying to work on the code That dev already knows DOM (or will have to do so via their devtools) if they're a front-end dev. (And React seems to have proven that's not an issue). > they'll still have to understand the pure Elm code that the elmx compiles to as well I don't experience this in React. I never think about the 'create dom'-ish JS calls it's translating to. > Plus it has limitations like not being able to nest code interpolations. Unless I misunderstand you, JSX can absolutely do this.
  - nilkn 10y ago
    This is getting more heated than I care for, so I'm going to bow out. As for your last sentence, just read the README for elmx: > Non-recursive interpolation: currently Elm code interpolated between { and } is not recursive (i.e. is a regular grammar not a CFG). This means that you cannot include curly brackets inside curly brackets. This is of course just a limitation of the implementation, not the idea.

by allover 10y ago

ollysb 10y ago

Prior to Elm I spent 5 years building front end apps using ember.js(handlebars templates) and then JSX with React. From memory it took me about 2 days to get used to Elm's approach. Once you get used to have the full power of a programming language to build your view going back to using templates honestly feels painful by comparison. Aside from the power of having a full language available you also get the benefit of static typing. Refactoring your views with the same ease that you do with your normal code and with a compiler to watch your back is liberating. I wasn't aware how cautious I was with refactoring view components until I tried the alternative.

allover 10y ago
JSX is a language extension which desugars to JavaScript. It is not the same as 'going back to templates'. > Refactoring your views with the same ease that you do with your normal code and with a compiler to watch your back is liberating I have this experience with JSX (which I didn't have with string template libs), and I also don't see that an Elm equivalent like elmx would take anything away from that experience in Elm.

nilkn 10y ago

I still think you're trying to prematurely optimize against your very first impression of seeing a new syntax for a familiar data structure. I've actually written several thousand lines of Elm code for a real internal tool at work, and elmx feels like it just complicates the view code with virtually no benefit. I think it's solving a problem that doesn't exist -- and not at zero cost. The result won't be understood by elm-format. Compiler errors will exist at the level of Elm, not elmx. It's something extra that has to be learned by any other developer trying to work on the code -- and they'll still have to understand the pure Elm code that the elmx compiles to as well. Plus it has limitations like not being able to nest code interpolations.

allover 10y ago
> you're trying to prematurely optimize against your very first impression [...] No I'm not, and I'm tired of 'the familiarity argument'. > elmx feels like it just complicates the view code with virtually no benefit. See my other comments in this thread - I don't agree - JSX being more closely related to the DOM you're building is a significant benefit. Also empirically in React land, JSX is vastly more popular than not using it. > The result won't be understood by elm-format. If ESLint can understand JSX, then elm-format can understand elmx. > It's something extra that has to be learned by any other developer trying to work on the code That dev already knows DOM (or will have to do so via their devtools) if they're a front-end dev. (And React seems to have proven that's not an issue). > they'll still have to understand the pure Elm code that the elmx compiles to as well I don't experience this in React. I never think about the 'create dom'-ish JS calls it's translating to. > Plus it has limitations like not being able to nest code interpolations. Unless I misunderstand you, JSX can absolutely do this.
- nilkn 10y ago
  This is getting more heated than I care for, so I'm going to bow out. As for your last sentence, just read the README for elmx: > Non-recursive interpolation: currently Elm code interpolated between { and } is not recursive (i.e. is a regular grammar not a CFG). This means that you cannot include curly brackets inside curly brackets. This is of course just a limitation of the implementation, not the idea.