Live data from Hacker News

Elm for the Front End, Right Now

bendyworks.com

21–30 of 81 posts

Re: Elm for the Front End, Right Now

#21
post #17

Earlier quoted context omitted.

It's not at 1.0, there's no promise about preserving backwards compatibility at this point.

See my reply to the other thread. 1. If it is not ready for prime time, maybe we should stop promoting it? 2. React was 0.14 up to a year or so ago. The number doesn't mean anything.

People are excited by it, and managed to deal with prime-ageddon without any major headaches (it's like basic regex search and there's even an update tool, come on).

Re: Elm for the Front End, Right Now

#22
post #10

Earlier quoted context omitted.

> early stage language I keep hearing this excuse, and to be honest I don't like it. On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. > I'd say reducing weird syntax is a perfectly good reason I disagree with you on this, prohibiting the users from using the prime character has nothing to do with the language…

> On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language. Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's ackn…

> it would sound like there was some critical change to the core functionality of the language

No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so).

> 1. It confuses newbies.

Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.

Is a language that allows Unicode characters for variable names confusing for newbies?

> 2. It's an easy character to miss.

Again, it is in my code.

> 3. It's easy to migrate away from it.

That's not an argument for removing something.

Again, my point is that is has to do with personal taste, yet Evan decided to force it to anybody who uses the language.

He could have very easily enforce it to core packages, and nobody would complain. But forcing it on my code, is worrying.

Re: Elm for the Front End, Right Now

#23

From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.

Completely logical. Java, C, PHP are said to be algol descendants. In two words: curly braces. JS wasn't supposed to but ended up curly because social trends are that strong. Now imagine JS function being the only thing you use, then that language users and designers evolving a syntax for typed js-like functions, rince repeat, you get ML, Haskell, Elm.

In time your brain realigns, depending on how much you appreciate the functional style or not.

Re: Elm for the Front End, Right Now

#25

Earlier quoted context omitted.

Because I really like syntax like Haskell (the type signature is much clearer especially in generic code compared to Java or Scala etc. for example), I'm curious, what is so uncomfortable about the syntax?

The lack of parentheses around function calls makes it hard for people not familiar with ML-style languages to tell where the function calls are and what the arguments are to each function call. There is a wide variety of syntax among mainstream languages, but basic function calls are pretty much all the same. Take a look at Reason [1] for an example of how a functional language (OCaml in this case) can be made more…

Or maybe people could just become familiar with ML-style languages? The basic syntax shouldn't take more than an hour or two to pick up.

Re: Elm for the Front End, Right Now

#26

From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.

Yeah, it seems like a step back in readability... It's not at all intuitive and once I figure out what its doing, I can't find a reason for it.. Lisps are hard to read, but there are at least a few reasons for the syntax (not that i like them) ... This just seems... weird and unusual for no reason...

Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.

Re: Elm for the Front End, Right Now

#27
Speaking of Elm I liked this video from Erlang Factory about using Phoenix and Elm together. They both have a functional flavors so I think it might appeal to same people:

https://www.youtube.com/watch?v=XJ9ckqCMiKk

The first half is about Phoenix, the second about Elm. I don't know much about front-end stuff but I did like the Elm bit as an intro, especially the debugging and nice error messages part.

Re: Elm for the Front End, Right Now

#28

why not flowtype/typescript+js es6+react+redux/mobx? currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.

I'm quite sure it's exactly for that reason, not having to choose between

- Flow vs Typescript

- ES5 vs Babel

- React vs Angular vs Vue vs jQuery

- Webpack vs Rollup

- Redux vs Flux vs Mobx vs React states

etc...

Plus, probably lots of dev prefer Elm's syntax and design.

Re: Elm for the Front End, Right Now

#29
post #22

Earlier quoted context omitted.

> On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language. Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's ackn…

> it would sound like there was some critical change to the core functionality of the language No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so). > 1. It confuses newbies. Remove it from core language then. Having the prime character in my code, do…

> Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me.

Until you take your personal style to Github, or coworkers...

Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.

Re: Elm for the Front End, Right Now

#30
post #17

Earlier quoted context omitted.

It's not at 1.0, there's no promise about preserving backwards compatibility at this point.

See my reply to the other thread. 1. If it is not ready for prime time, maybe we should stop promoting it? 2. React was 0.14 up to a year or so ago. The number doesn't mean anything.

> prime time

Apparently, prime time came and went :)

> If it is not ready for prime time, maybe we should stop promoting it?

It's about as ready as the impression it makes: yes, you can use it for project. But you may need half an hour every few months to update.

Post reply on HN