Ellie – An Elm Live Editor(humblespark.com)
humblespark.com
Ellie – An Elm Live Editor
https://www.humblespark.com/ellie-announcement/
93 comments
Clicking the About button I see:
"All content created with Ellie is released in the public domain (CC0)."
Are they claiming that any program written with Ellie is in the public domain?
(edit) I've emailed to ask their intent. I'll post an update if I get a reply.
"All content created with Ellie is released in the public domain (CC0)."
Are they claiming that any program written with Ellie is in the public domain?
(edit) I've emailed to ask their intent. I'll post an update if I get a reply.
Evidently their intention is that if you write a program with Ellie and save it it is in the public domain. According to my correspondent, they may switch to releasing edited code with the MIT license.
I let him know that those terms would make me very reluctant to use Ellie for anything, even open source code, since the ability to apply an open source license requires that I have a copyright. I suggested that they putting a very visible statement of what they're doing on the page.
I let him know that those terms would make me very reluctant to use Ellie for anything, even open source code, since the ability to apply an open source license requires that I have a copyright. I suggested that they putting a very visible statement of what they're doing on the page.
Ellie has been quite helpful in my efforts to convert my company to Elm, so many thanks to its creators.
Wow, that's awesome! Can you expand on this a little either here or at [email protected]? I'd love to hear how this helped.
Sure, I'll write something up this weekend.
Just tried Elm yesterday (not using this editor, though). Neat and simple.
But I found the documentation to be of a really low quality, and I believe good docs are the most important thing for any language aiming for developers' adoption.
At least the docs on elm-lang.org weren't any good - maybe there's some alternative projects out there?
let rant_ = [
I just wanted to have a thin non-breakable space (U+202F) and haven't found anything about actual syntax in the "syntax" document, nor anywhere around that. Syntax docs is just a bunch of examples with a short notes - a quick cheatsheet at best.
Then I wanted to browse Html package contents and see what's the difference between beginnerProgram and program and what else do they have in stock (with Haskell I always had good idea of module's contents by reading docs on Hackage), but the docstrings were nearly meaningless, not even listing the arguments. "Read about The Elm Architecture", really? I just came from that document (and they only cover beginnerProgram basics), hoping a module docs would give me better idea.
] in sorryAbout rant_ -- I had eventually figured it all out, but was quite disappointed.
But I found the documentation to be of a really low quality, and I believe good docs are the most important thing for any language aiming for developers' adoption.
At least the docs on elm-lang.org weren't any good - maybe there's some alternative projects out there?
let rant_ = [
I just wanted to have a thin non-breakable space (U+202F) and haven't found anything about actual syntax in the "syntax" document, nor anywhere around that. Syntax docs is just a bunch of examples with a short notes - a quick cheatsheet at best.
Then I wanted to browse Html package contents and see what's the difference between beginnerProgram and program and what else do they have in stock (with Haskell I always had good idea of module's contents by reading docs on Hackage), but the docstrings were nearly meaningless, not even listing the arguments. "Read about The Elm Architecture", really? I just came from that document (and they only cover beginnerProgram basics), hoping a module docs would give me better idea.
] in sorryAbout rant_ -- I had eventually figured it all out, but was quite disappointed.
Cool, now if there were Vim bindings, I could really use it for something fun (don't have the patience to use arrow keys + mouse). Even crude bindings covering the basic Vi command. Anyone know what are they using for the text editor? If it's something like CodeMirror, adding Vi bindings is pretty trivial.
I feel your pain. Here's what worked for me:
Spacemacs + elm layer + elm-hot-reload. If you have two screens (or enough resolution) you can have something similar to this app with all the power of a great editor. (Sure it could be emacs + evil or Vi(m) instead)
Spacemacs + elm layer + elm-hot-reload. If you have two screens (or enough resolution) you can have something similar to this app with all the power of a great editor. (Sure it could be emacs + evil or Vi(m) instead)
Try to make a type error. Beautiful.
Format seems to be in Alpha, doesn't limit line length?
It's tricky with Elm because it's written in Haskell, so compilation etc. takes long time in the browser, but this is quite nice. Should definitely push to replace /try with this.
Format seems to be in Alpha, doesn't limit line length?
It's tricky with Elm because it's written in Haskell, so compilation etc. takes long time in the browser, but this is quite nice. Should definitely push to replace /try with this.
This is beautiful. I'm sure it'll make picking up Elm much easier. Good job!
By "live" is the intention that the program will recompile without losing the state of the running app? I remember seeing a cool Elm demo of that, but it seems like Ellie requires recompilation.
My thoughts exactly. Title is misleading. If I have to click compile or hot reload it's not really a live editor. You can't change values and watch them update on the fly.
¯\_(ツ)_/¯ idk it's just a neat name. the env is more "live" than downloading the platform, setting up an editor and running the compiler and package manager from the terminal. i mean, is the name elm misleading because it's not a programming language for trees?
Essentially just asking if my browser was running it correctly :)
This is incredibly cool! I'm running an Elm workshop for my coworkers next week, and this will provide a much better experience than having them install everything locally.
Seems really well-suited towards teaching functional programming.
it's a little bit pink for my taste. There's a way to change the CSS, right?
im a huge fan of the Elm broswer. and have been using Elm with atom along with elm reactor. That has worked adequately. Most difficulties are ironed out by making sure the Elm code compiles. Then at least all the parts are fitting together.
But maybe I have written code that compiles, but doesn't express what I am wanting.
im a huge fan of the Elm broswer. and have been using Elm with atom along with elm reactor. That has worked adequately. Most difficulties are ironed out by making sure the Elm code compiles. Then at least all the parts are fitting together.
But maybe I have written code that compiles, but doesn't express what I am wanting.
We're going to change the color. We've been hearing feedback that it's a little hard on the eyes.
Definitely better than http://elm-lang.org/try
Awesome! Anyone else having issues in chrome? The buttons along the top bar are missing for me. Woks fine in Firefox and Safari.
this could have been the server falling over briefly and features being turned off as a result. we weren't expecting so much attention tonight since it's friday!
Congrats Luke!
Can there be an option for it not to be pink ?
It's a bit much in the morning.
It's a bit much in the morning.
Not suggesting this as a perfect alternative, but you could use Stylish to change the header color. Since I already have stylish installed on my chrome it only took about five seconds to open it and add a style rule like
.components_header_Header {
background-color: #000080;
}It's got some interesting design decisions for what's potentially a cool classroom tool. If it appeals to girls that's great, but I'd have to hope it wouldn't actually repel the boys.
I don't know who I've offended but I hope it wasn't the developers. I genuinely think this is very cool, and if I can get my boss on board I will try using it in my class.
Probably the sexist nonsense about pink appealing to girls and scaring off "the boys"?
I think it is disgusting that you throw around accusations of sexism without foundation. I acknowledged ideas that children tend to have concerning sexual identity (as the designer of Ellie will have done, as anybody who wishes to address the issue of diversity in computing will have to do). I can assure you I played no part in inculcating them.
as a ruby dev that constantly dips into irb over syntax and semantic questions, a tool like this really helps me think at the same increment with elm!
(Ellie is really cool, apologies for the meta comment, but):
It's a shame that all that hits me in the face with Elm code examples lately is awkward style conventions. Why do they have to be so user hostile?
Trailing brace on the next line even for this?
It's a shame that all that hits me in the face with Elm code examples lately is awkward style conventions. Why do they have to be so user hostile?
Trailing brace on the next line even for this?
type alias Model =
{ counter : Int
}
type alias Model = { counter: Int }
Html.program
{ view = view
, update = update
, subscriptions = \_ -> Sub.none
, init = ( model, Cmd.none )
}
Html.program {
view = view,
update = update,
subscriptions = \_ -> Sub.none,
init = ( model, Cmd.none ),
}
div []
[ div [] [ button [ onClick Increment ] [ text "+" ] ]
, div [] [ text <| toString model.counter ]
, div [] [ button [ onClick Decrement ] [ text "-" ] ]
]
<div>
<div><button
<div>{toString model.counter}</div>
<div><button
</div>
The DOM syntax makes perfect sense, but you have to realise it's not a 'transformation' in the sense of taking a stream of text and converting it into a stream of HTML for the browser. It's just Elm code that returns DOM nodes.
The HTML functions in Elm tend to take two parameters: a list of attribute values and a list of child DOM nodes. Again, this is all code. The list values you specify are again just functions that get evaluated.
It's a little less obvious because of the syntax style of Elm, but it does let you write the function calls out in such a way that they express that tree structure.
It bears repeating: your Elm div example, at the top level, is a single function call with the first parameter '[]' being an empty list (because you aren't assigning the node any attributes like a DOM id or CSS class) and the second parameter being a list that'll be made up of the DOM nodes that result from each of the function calls within it.
This was one of the biggest mental roadblocks I had to get past when learning Elm. Just forget the idea of HTML and think instead of DOM tree-of-nodes and a lot falls into place. The 'view' function you write will return a DOM tree data structure which is then taken and applied to the browser document. You pass in your model as a parameter to that function and then other functions you call within this DOM-generating code you've written will use that data to return different DOM contents depending on it.
The HTML functions in Elm tend to take two parameters: a list of attribute values and a list of child DOM nodes. Again, this is all code. The list values you specify are again just functions that get evaluated.
It's a little less obvious because of the syntax style of Elm, but it does let you write the function calls out in such a way that they express that tree structure.
It bears repeating: your Elm div example, at the top level, is a single function call with the first parameter '[]' being an empty list (because you aren't assigning the node any attributes like a DOM id or CSS class) and the second parameter being a list that'll be made up of the DOM nodes that result from each of the function calls within it.
This was one of the biggest mental roadblocks I had to get past when learning Elm. Just forget the idea of HTML and think instead of DOM tree-of-nodes and a lot falls into place. The 'view' function you write will return a DOM tree data structure which is then taken and applied to the browser document. You pass in your model as a parameter to that function and then other functions you call within this DOM-generating code you've written will use that data to return different DOM contents depending on it.
Yes I do understand all that, as I'm a React dev, in which render() methods and 'pure function components' work in exactly the same way (take props and state as input and return dom-creation-calls).
That is why I used JSX as a counterexample. Basically I'm questioning Elm's choice to stick with the raw dom-creation-function-style vs adopting a JSX equivalent.
That is why I used JSX as a counterexample. Basically I'm questioning Elm's choice to stick with the raw dom-creation-function-style vs adopting a JSX equivalent.
Why introduce additional syntax when the native language works fine?
Elm is a functional language, and you build the desired DOM structure with functions. Why should it be any other way?
JSx looks sort of like HTML, but HTML isn't even the target here, just DOM nodes.
Elm is a functional language, and you build the desired DOM structure with functions. Why should it be any other way?
JSx looks sort of like HTML, but HTML isn't even the target here, just DOM nodes.
I'm suggesting it doesn't 'work fine', because syntax matters.
Lisp-style 'S-expression' syntax for describing documents never took off. We have to take something from that - it seems the vast majority of developers don't enjoy that syntax, irrelevant of how 'simple' its just-functions nature makes it.
JSX also 'targets DOM nodes', but I don't see what that has to do with anything.
The closer correspondence between how JSX looks, what you see in your browser DevTools, and how it seems that most developers prefer to mentally model documents ... is where the win comes from IMO.
The reality is the vast majority of React code I see uses JSX, even though it's optional. It's been hugely successful in React world and I don't think that should be ignored by Elm.
Lisp-style 'S-expression' syntax for describing documents never took off. We have to take something from that - it seems the vast majority of developers don't enjoy that syntax, irrelevant of how 'simple' its just-functions nature makes it.
JSX also 'targets DOM nodes', but I don't see what that has to do with anything.
The closer correspondence between how JSX looks, what you see in your browser DevTools, and how it seems that most developers prefer to mentally model documents ... is where the win comes from IMO.
The reality is the vast majority of React code I see uses JSX, even though it's optional. It's been hugely successful in React world and I don't think that should be ignored by Elm.
I'd say the problem isn't "this is not JSX", but that the syntax just looks awful:
Given that Elm is "just" for making HTML apps, this does seem like something the language should focus on.
div []
[ div [] [ button [ onClick Increment ] [ text "+" ] ]
, div [] [ text <| toString model.counter ]
, div [] [ button [ onClick Decrement ] [ text "-" ] ]
]
div
div
button onClick: Increment
text "+"
div
text <| toString model.counter
div
button onClick: Decrement
text "-"
Given that Elm is "just" for making HTML apps, this does seem like something the language should focus on.
[deleted]
Your syntax only looks good in hello-world examples and will stumble upon the same sort of ambiguities that things like coffeescript grappled with.
It turns out that it's less work to always have delimiters than it will be to have to add them anyways to disambiguate.
It turns out that it's less work to always have delimiters than it will be to have to add them anyways to disambiguate.
[deleted]
It's an interesting balancing act. I think when most devs look at JSX for the first time they instantly recoil at the rebellion against years and years of "separation of concerns", yet as you say it's a syntax that devs have embraced regardless.
I love Elm and think it or something very close to it should become way more mainstream, but I do find its bracket-heavy DOM syntax off-putting in comparison.
EDIT: That said, I do agree with the leading commas in laying out models as opposed to the trailing. Scanning the models of an Elm file is far faster than, say, a JS file, subjectively at least.
I love Elm and think it or something very close to it should become way more mainstream, but I do find its bracket-heavy DOM syntax off-putting in comparison.
EDIT: That said, I do agree with the leading commas in laying out models as opposed to the trailing. Scanning the models of an Elm file is far faster than, say, a JS file, subjectively at least.
HTML and XML for describing documents also never took off; they are largely generated from something else rather than hand-edited.
Thus, no structural, recursive syntax for document editing has "taken off".
Word processing is still done in Microsoft Word by most of the planet. HTML e-mails are written in some WYSIWYG client program. Web forums use variations on markdown (with raw HTML only as an escape hatch).
People do work with *ML by hand, but largely reluctantly.
If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.
Thus, no structural, recursive syntax for document editing has "taken off".
Word processing is still done in Microsoft Word by most of the planet. HTML e-mails are written in some WYSIWYG client program. Web forums use variations on markdown (with raw HTML only as an escape hatch).
People do work with *ML by hand, but largely reluctantly.
If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.
HTML and XML took off for web. That's what the vast majority of devs write and that's how all devtools display the DOM.
> If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.
Convince the masses, because they don't seem to agree.
> If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.
Convince the masses, because they don't seem to agree.
The reason for the commas at the beginning, is that it is easier to add a new line at the end. That is, if you forbid a "last comma". Traditional languages don't let you do
Also, it is much easier to look at this
Html.program {
view = view,
update = update,
subscriptions = \_ -> Sub.none,
init = ( model, Cmd.none ),
}
Also, it is much easier to look at this
Html.program
{ view = view
, update = update
, subscriptions = \_ -> Sub.none
, init = ( model, Cmd.none )
}
Yep, I get the preference over a lang that can't do trailing commas, which is why I used the trailing comma style as the counter-example. In a compile-to-JS language it's hopefully possible to make trailing commas legal. They've been legal in JavaScript itself for a long time (ES5) [0]
> Also, it is much easier to look at this [...] and see if all the commas are actually present.
ESLint can trivially lint that you haven't missed a comma (including the final trailing comma). The style guide/ESLint config I use (Airbnb's) enforces trailing commas. If ESLint can do it, Elm should be able to.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> Also, it is much easier to look at this [...] and see if all the commas are actually present.
ESLint can trivially lint that you haven't missed a comma (including the final trailing comma). The style guide/ESLint config I use (Airbnb's) enforces trailing commas. If ESLint can do it, Elm should be able to.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
They might have been technically legal since ES5, but they were only finalised this year (ES2017, with function params), and still don't seem to have full support. I've been burned a few times by that: I know that MDN article cited says they are, but code with trailing commas (esp objects) breaks in eg IE without transpilation
Yeah as the article says they were only added for object literals in ES5, which is the main place the 'issue' comes up, and where I was making the comparison to Elm. That works in IE > ~7/8? without transpilation.
> In a compile-to-JS language it's hopefully possible to make trailing commas legal. They've been legal in JavaScript itself for a long time
Well, Elm is not trying to be JS, it's trying to be better, and there's really no reason to need trailing commas. I'd even argue that it argue it leaves a message of mixed intent "did the author want to continue the list?" and needlessly enables duplicate styles for the same one thing.
Well, Elm is not trying to be JS, it's trying to be better, and there's really no reason to need trailing commas. I'd even argue that it argue it leaves a message of mixed intent "did the author want to continue the list?" and needlessly enables duplicate styles for the same one thing.
That's a tenuous argument. I've yet to meet a developer who thinks a trailing comma is the slightest bit ambiguous when the next character is a closing bracket.
[deleted]
> Traditional languages don't let you do [...] Because the parse would expect something to come after that last comma.
Which languages are you referring to? Almost every language I'm aware of allows trailing commas.
C, C++, Java, Python, C#, Javascript (somewhat), Ruby, Objective-C, Perl, PHP, Elixir, Rust, and Go all allow trailing commas.
Which languages are you referring to? Almost every language I'm aware of allows trailing commas.
C, C++, Java, Python, C#, Javascript (somewhat), Ruby, Objective-C, Perl, PHP, Elixir, Rust, and Go all allow trailing commas.
> And thus you would have the last line being special and different.
Except you've now traded the last line being special for the first line being special.
Except you've now traded the last line being special for the first line being special.
[deleted]
Regarding "weird bracket soup", isn't the HTML version "weird arrow soup"? I suspect you're just used to seeing HTML, so you forgive it for its ugliness and oddities.
The main difference is that the Elm "bracket soup" is just a composition of functions and is subject to some type checking by the compiler. Elm view code as such can easily be restructured and refactored using the simple laws of function composition, which are very powerful, especially in combination with a strict type system.
The main difference is that the Elm "bracket soup" is just a composition of functions and is subject to some type checking by the compiler. Elm view code as such can easily be restructured and refactored using the simple laws of function composition, which are very powerful, especially in combination with a strict type system.
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 [1] https://github.com/pzavolinsky/elmx
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 [1] https://github.com/pzavolinsky/elmx
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.
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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
There are reasons for all these, the first two are both to optimize for VCS changes, since adding something to your first to examples would now only generate a minimum diff[0]. That, and considering Elms roots in Haskell, this is the common style for things there.
The last one is because all html in Elm are just regular Elm functions. This means no special syntax to manipulate html, and you have the power of all of Elm at your fingertips, without shoehorning it into a new syntax. [1]
Honestly some quite silly arguments...
[0] You can read some of the benefits on the style here https://github.com/avh4/elm-format/blob/master/README.md
[1] Explained a bit down the page https://guide.elm-lang.org/architecture/user_input/buttons.h...
The last one is because all html in Elm are just regular Elm functions. This means no special syntax to manipulate html, and you have the power of all of Elm at your fingertips, without shoehorning it into a new syntax. [1]
Honestly some quite silly arguments...
[0] You can read some of the benefits on the style here https://github.com/avh4/elm-format/blob/master/README.md
[1] Explained a bit down the page https://guide.elm-lang.org/architecture/user_input/buttons.h...
What if you want to change the first item of a list? If you're going for smallest diff (which I'm not even convinced is a worthwhile consideration in language design), then allover's example is clearly superior to Elm's current convention.
The comma first is not with language design, it's a convention from FP langs (at least Haskell).
>What if you want to change the first item of a list?
I mean, there are quite a bunch of languages that don't support non-terminating commas, which is really a bit of parsing that hides intent.
Other than that, bashing a language for having the convention (that is not forced by the language but by... convention) is quite ridiculous. The HTML comment is a valid point to raise, but there is quite a good reason for having it be native Elm, which brings a ton more benefits than having JSX'esgue syntax.
>What if you want to change the first item of a list?
Html.program
{ view = view
, update = update
}
Html.program
{ view = newView
, update = update
}
I mean, there are quite a bunch of languages that don't support non-terminating commas, which is really a bit of parsing that hides intent.
Other than that, bashing a language for having the convention (that is not forced by the language but by... convention) is quite ridiculous. The HTML comment is a valid point to raise, but there is quite a good reason for having it be native Elm, which brings a ton more benefits than having JSX'esgue syntax.
I meant what if you wanted to add a new item to the front of a list or change the order of items in the list.
It is forced slightly by the language as trailing commas are currently invalid syntax (though this is on the roadmap to be fixed). It's also more than just a convention, as it is explicitly recommended in the official Elm docs.
[ 1
, 2
, 3
]
[ 0
, 1
, 2
, 3
]
- [ 1
+ [ 0
+ , 1
, 2
, 3
]
It is forced slightly by the language as trailing commas are currently invalid syntax (though this is on the roadmap to be fixed). It's also more than just a convention, as it is explicitly recommended in the official Elm docs.
Nobody has mentioned it, but in this sort of language, you're chaining expressions onto the right-hand side.
Putting commas on the left-hand side means they're out of your way once and for all.
The versioning diff argument is much less interesting. Most people don't care about that.
Putting commas on the left-hand side means they're out of your way once and for all.
The versioning diff argument is much less interesting. Most people don't care about that.
[deleted]
Elm definitely tries painfully hard to be different, which is only exacerbated by its one-true-way attitude.
Regarding HTML, you may want to look at elmx [0]. It accomplishes exactly what you described.
[0] https://github.com/pzavolinsky/elmx
Regarding HTML, you may want to look at elmx [0]. It accomplishes exactly what you described.
[0] https://github.com/pzavolinsky/elmx
>"Regarding HTML, you may want to look at elmx [0]."
In a similar vein...
https://marketplace.visualstudio.com/items?itemName=Rubymani...
https://atom.io/packages/html-to-elm
In a similar vein...
https://marketplace.visualstudio.com/items?itemName=Rubymani...
https://atom.io/packages/html-to-elm
What actually distract people are boilerplate/composability, lack of fancy types, package publishing openness and slow-paced community. Don't get me wrong, I like Elm, this is just my observation.
The boilerplate issue is frustrating. It sometimes seems like the Elm resources out there all stop at toy examples; SPAs with only three or four different screens without components that need to manage internal view state.
Really I think it's just the stage of adoption that the language is in. It really is cutting-edge in that way and everyone is figuring out the best way to do things. It's early, early days.
In my current project, I've used templating to solve this. I ended up with a huge Elm main program that was 90% case-statements to call the appropriate update, view or other functions (eg- passing JSON data from the back-end server to the appropriate places). I got cranky enough with it that I made a templates version of it using the doT.js library and a script.
Now I can specify the subscreens I want in my application in a JSON file and have a script take that and my Elm code template and spit out a perfectly readable main.elm file which then gets compiled as normal. It's actually turned out really well for my purposes.
Really I think it's just the stage of adoption that the language is in. It really is cutting-edge in that way and everyone is figuring out the best way to do things. It's early, early days.
In my current project, I've used templating to solve this. I ended up with a huge Elm main program that was 90% case-statements to call the appropriate update, view or other functions (eg- passing JSON data from the back-end server to the appropriate places). I got cranky enough with it that I made a templates version of it using the doT.js library and a script.
Now I can specify the subscreens I want in my application in a JSON file and have a script take that and my Elm code template and spit out a perfectly readable main.elm file which then gets compiled as normal. It's actually turned out really well for my purposes.
[deleted]
<div> is html while div[] is elm code. Are you asking why not support html in the elm code? IMO its much much nicer to just program the DOM in elm than translate between elm and html.
Also, I type my code any old way such as { counter: Int }. When I save elm-format reformats automatically.
Can't upvote this enough.
I am sure one gets used to it after some time, but prepending lines with comma, just because it makes it easier to add new lines is so so ugly and takes away from the main intent for newcomers.
This is akin to starting each sentence in English with a dot!
I am sure one gets used to it after some time, but prepending lines with comma, just because it makes it easier to add new lines is so so ugly and takes away from the main intent for newcomers.
This is akin to starting each sentence in English with a dot!
Reading the comma style, to me, is cleaner. But typing it while writing the record type is urgggg! It is this cycle: type words -> enter -> repeat tabs -> type comma -> type words Or you will have to keep hitting `save` command for auto-formatting.
Seems like you need to find better auto-formatting and fix your workflow.
Else every language would be annoying to write, especially a lisp.
Else every language would be annoying to write, especially a lisp.
Not only have I gotten used to it (pretty much immediately), I get really annoyed when it's the other way.
I don't read code like I read a novel. I read it in an attempt to understand the writer's intentions, and what the code is meant to accomplish. I find the leading commas to be far easier to scan than the other way around.
You can use elm-format and never think about formatting again.
Instead of mixing html and js why not use function calls for everything. I believe there would be no jsx if javascript would allow function calls without the parens.
It's a shame its maintainers are so hostile towards customization.
https://github.com/avh4/elm-format/issues/210
https://github.com/avh4/elm-format/issues/210
I consider it a blessing. It means we never need to argue about these things. Go's go-fmt has the same philosphy.
That philosophy works better when the style you enforce is, if not happily accepted, at least not moderately controversial. Otherwise many developers will choose simply not to use x-format—or worse, be turned off from the language.
In such layout-block languages (without curly braces and semicolons for denoting blocks and "statements") it shouldn't be a big deal one way or the other anyway..
Well, just look at the thread-derailing peanut gallery explosion in this very comment thread to see it's not such a bad idea to limit customization.
People can live with different tab lengths. I'm not so sure every project needs to be bike-shedding about it, though.
People can live with different tab lengths. I'm not so sure every project needs to be bike-shedding about it, though.
Yep, I think the emerging tradition with Elm is just to leave it to elm-format. I wonder if tooling may end up being the answer to composability and boilerplate too, though I'm not sure quite yet how.
There is no boilerplate in Elm if you don't write self-contained components and you really shouldn't. You end up with huge model/update/view functions that you split down into modules. Here is an example app - https://github.com/knewter/time-tracker.
Really cool app! I'm going to study this. I'd love to put the app I'm working on up as an example to share lessons learned but it's commercial work, so I'll have to make another hobby one in the future and use that :)
I alluded a bit to it in another comment here, but I'm not entirely convinced that the "you shouldn't write components" is a good design target overall vs. just being a necessity because of the limitations of Elm the language right now.
It probably hinges on what you mean by 'component'. When I say 'component', I mean a bit of UI I'm planning to reuse across multiple pages, where there might be some private model, where I would not want the internals of that model duplicated across and polluting otherwise clean page models.
Here is an example that comes to mind: I have common functionality across pages in my app where I want to let the user edit a database field.
To do this, the user can select the list of fields from a drop-down or they can type the field name into a search box, with choices being displayed as they type in real-time; they can then click on a choice and edit that field.
To submit the edit, they click an 'Update' button.
Now, this functionality is shared across different pages in my app. None of these pages should, IMHO, necessarily have to care about the intermediate states of the field-list as it is auto-completing. I simply want a function I can call from any view like this:
renderChoiceThingy : List FieldChoices -> ChoiceThingyModel -> msg -> Html msg renderChoiceThingy fieldsToPickFrom model actionOnSubmit = ....
Not only might I want multiple instances of this same thing across many pages, but I'll also want multiple instances of it on the same page sometimes. For example, let the end-user build up a list of changes and then submit them all in a batch or cancel them all at once.
Without treating this like a self-contained unit, I'm now duplicating model bits in all my pages that use this function. So it's nice to wrap that control up into a module, with its' own 'update' and 'view' and have appropriate parameters to allow the proper message types to work.
Another example (not one I've implemented); say you have an interactive colour picker, that you can click on an icon to exapnd, select the colour you want by changing sliders interactively, then have the picker disappear and the page know what colour you've selected. To me, the containing page shouldn't care about all that slider stuff and all the messaging and updating that goes on, just to draw the picker.
Would love to hear other Elm devs thoughts on this. These are the kinds of examples I don't see directly addressed when people say "don't write components". Though I suspect, having not used other 'component' frameworks like React, that people might generally mean something slightly different to what I'm thinking when they say "no components". Really interested to find out what others think about this.
I alluded a bit to it in another comment here, but I'm not entirely convinced that the "you shouldn't write components" is a good design target overall vs. just being a necessity because of the limitations of Elm the language right now.
It probably hinges on what you mean by 'component'. When I say 'component', I mean a bit of UI I'm planning to reuse across multiple pages, where there might be some private model, where I would not want the internals of that model duplicated across and polluting otherwise clean page models.
Here is an example that comes to mind: I have common functionality across pages in my app where I want to let the user edit a database field.
To do this, the user can select the list of fields from a drop-down or they can type the field name into a search box, with choices being displayed as they type in real-time; they can then click on a choice and edit that field.
To submit the edit, they click an 'Update' button.
Now, this functionality is shared across different pages in my app. None of these pages should, IMHO, necessarily have to care about the intermediate states of the field-list as it is auto-completing. I simply want a function I can call from any view like this:
renderChoiceThingy : List FieldChoices -> ChoiceThingyModel -> msg -> Html msg renderChoiceThingy fieldsToPickFrom model actionOnSubmit = ....
Not only might I want multiple instances of this same thing across many pages, but I'll also want multiple instances of it on the same page sometimes. For example, let the end-user build up a list of changes and then submit them all in a batch or cancel them all at once.
Without treating this like a self-contained unit, I'm now duplicating model bits in all my pages that use this function. So it's nice to wrap that control up into a module, with its' own 'update' and 'view' and have appropriate parameters to allow the proper message types to work.
Another example (not one I've implemented); say you have an interactive colour picker, that you can click on an icon to exapnd, select the colour you want by changing sliders interactively, then have the picker disappear and the page know what colour you've selected. To me, the containing page shouldn't care about all that slider stuff and all the messaging and updating that goes on, just to draw the picker.
Would love to hear other Elm devs thoughts on this. These are the kinds of examples I don't see directly addressed when people say "don't write components". Though I suspect, having not used other 'component' frameworks like React, that people might generally mean something slightly different to what I'm thinking when they say "no components". Really interested to find out what others think about this.
If you haven't seen it, take a look at elm-sortable-table [0]. It's an example reusable view, written by Evan, that's meant to demonstrate exactly what you're asking about.
[0] https://github.com/evancz/elm-sortable-table
[0] https://github.com/evancz/elm-sortable-table
[deleted]
[deleted]
[deleted]
Commas-first give you an obvious visual clue when you forget a comma and let the reader immediately know that the current line is a continuation and not a new expression.
Linters (or in Elm's case), the compiler, should tell you when you forget a comma.
Indents let the reader know the current line is a continuation.
Comma-first also creates worse diffs than (enforced) trailing comma.
Indents let the reader know the current line is a continuation.
Comma-first also creates worse diffs than (enforced) trailing comma.
Elm made me enjoy frontend development again. Can't recommend it enough.