7 ms·

I'm torn about this. I'm rooting for Elm and I think it currently might be the best frontend solution. I really like Evan's focus on developer UX and simplicity

by erokar 8y ago

I'm torn about this. I'm rooting for Elm and I think it currently might be the best frontend solution. I really like Evan's focus on developer UX and simplicity. This means removing things, making the language smaller and simpler. And to do that you need to maintain a certain amount of control. However this seems to have backfired. Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. JS interoperability and just enough Algol syntax to staisfy the masses. Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev.

jnbiche 8y ago
> Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. That's not the only reason ReasonML will win. The BuckleScript JS compiler generates fantastic JavaScript, with no huge extra runtime at all. Also, ReasonML benefits from all the stability of OCaml's type checker. And, as you suggest, both ReasonML and BuckleScript are in my experience a much friendlier and open community to experienced devs and commercial users.
- sdnguyen90 8y ago
  The runtime is not that big with 0.19 in my experience. I rewrote a (P)react component that was 5kb and Elm came out to be 6.8kb. If you're comparing it to ReasonReact, you still have the React/ReactDOM Javascript dependency which is still ~30kb gzipped
  - bjz_ 8y ago
    Kind of curious if anyone's played around with using incr_dom with Reason: - https://github.com/janestreet/incr_dom/ https://github.com/janestreet/incr_dom/ - https://www.youtube.com/watch?v=h_e5pPKI0K4 https://www.youtube.com/watch?v=h_e5pPKI0K4 Seems like it might be tied to js_of_ocaml though...
  - PascalW 8y ago
    React is unfortunately quite big indeed. However you can actually replace React in ReasonReact with an API compatible alternative via Webpack. I tried this a few weeks back and have to say that it only worked with Inferno.js though, not Preact (lack of React 16 feature support) nor Nerv.js.
chenglou 8y ago
Thanks for the plug! I work on Reason. We do have great interop, but we also make other trade offs; hopefully folks don’t rage-join for the wrong reasons =).
hazza1 8y ago
It's an alpha pre v1 language, it's going to break things to get better. However they also need to encourage users to build things so they can observe patterns and improve the language - often by removing the functionality developers relied upon (in the maintainers opinion wrongly.) These pre v1 developers are going to get angry and burnt, the main problem is that Elm is ambitious and reliant on just one guy. 18 months with few warnings on breaking changes gives developers a long time to become reliant on deprecated functionality. I've done some Elm development, the lack of documentation and support unless you hang out on chat channels put me off. I might try again post v1 but that feels a very long way away.
- bostonvaulter2 8y ago
  > It's an alpha pre v1 language Not according to the homepage. According to the homepage you should install now and it's already used in production by major companies!
  - hazza1 8y ago
    > According to the homepage you should install now and it's already used in production by major companies! > > they need to encourage users to build things Is obvious from feedback on this article that this is alpha quality software. Feel free to be a guinea pig but I'd be very worried if I had any Elm code in production (unless you are no red ink and can hire the language author)
staltz 8y ago
I author the Cycle.js framework and for a good while I considered it to be a sister project to Elm, because both had a focus on simple functional reactive programming for frontend. I've advocated Elm and been a bit in the community as well. Evan is great person, I still remember fondly the time we had good long conversations at a conference. I started the first attempt at integrating Elm with React Native, and that was only possible through hacking the native modules in various ways. I figured I couldn't progress with this plan due to how restricted Elm is regarding native modules, but also other things like naming of community modules. Elm is strict not just as a language but also as a community culture. What shocks me about the latest state of Elm and its community is how easily conversations get locked. Locking should be the last resort. What leaders block or ban indicates what they do not want to risk. There should always be the possibility of blocking to say that "we cannot afford having X in our community." and defend some basic principles. In many communities, X is just personal attacks or harassment, that kind of thing. The consistent pattern I see in the Elm community management is that X is dissent. "We cannot risk having divergent discussions (polite or impolite) in our community" is message that restricts thought freedom and reinforces cult-like behavior. It's not a good thing to have in a community, specially in an open one on the internet where membership is fluid (unlike dissent in a company for example). Curbing dissent ultimately leads to lack of innovation (which comes from freedom to create without fear of rejection), which reinforces the status of the leader as the primary source of innovation, because whatever the leader does is assumed to be never rejected. I think these community dynamics are bad in the long run, it creates more feeling of rejection, decreases innovation, and centralizes even more responsibility and power to the BDFL.
- maxhallinan 8y ago
  Andre's talk "The Past, Present, and Future of Cycle.js" [1] describes how Cycle was grown by the community through discussion and experimentation. [1] https://vimeo.com/216787869 https://vimeo.com/216787869
vmchale 8y ago
> Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev. Evan is suffering the direct consequences of his actions because he tried to recruit people to the community and then fucked over their production projects.

by erokar 8y ago

jnbiche 8y ago

> Too many in the community want this or that and/or don't feel their opinion is heard. Then they switch to something else. Unfortunatley I think something like ReasonML will win in the end. That's not the only reason ReasonML will win. The BuckleScript JS compiler generates fantastic JavaScript, with no huge extra runtime at all. Also, ReasonML benefits from all the stability of OCaml's type checker. And, as you suggest, both ReasonML and BuckleScript are in my experience a much friendlier and open community to experienced devs and commercial users.

sdnguyen90 8y ago
The runtime is not that big with 0.19 in my experience. I rewrote a (P)react component that was 5kb and Elm came out to be 6.8kb. If you're comparing it to ReasonReact, you still have the React/ReactDOM Javascript dependency which is still ~30kb gzipped
- bjz_ 8y ago
  Kind of curious if anyone's played around with using incr_dom with Reason: - https://github.com/janestreet/incr_dom/ https://github.com/janestreet/incr_dom/ - https://www.youtube.com/watch?v=h_e5pPKI0K4 https://www.youtube.com/watch?v=h_e5pPKI0K4 Seems like it might be tied to js_of_ocaml though...
- PascalW 8y ago
  React is unfortunately quite big indeed. However you can actually replace React in ReasonReact with an API compatible alternative via Webpack. I tried this a few weeks back and have to say that it only worked with Inferno.js though, not Preact (lack of React 16 feature support) nor Nerv.js.

chenglou 8y ago

Thanks for the plug! I work on Reason. We do have great interop, but we also make other trade offs; hopefully folks don’t rage-join for the wrong reasons =).

hazza1 8y ago

It's an alpha pre v1 language, it's going to break things to get better. However they also need to encourage users to build things so they can observe patterns and improve the language - often by removing the functionality developers relied upon (in the maintainers opinion wrongly.) These pre v1 developers are going to get angry and burnt, the main problem is that Elm is ambitious and reliant on just one guy. 18 months with few warnings on breaking changes gives developers a long time to become reliant on deprecated functionality. I've done some Elm development, the lack of documentation and support unless you hang out on chat channels put me off. I might try again post v1 but that feels a very long way away.

bostonvaulter2 8y ago
> It's an alpha pre v1 language Not according to the homepage. According to the homepage you should install now and it's already used in production by major companies!
- hazza1 8y ago
  > According to the homepage you should install now and it's already used in production by major companies! > > they need to encourage users to build things Is obvious from feedback on this article that this is alpha quality software. Feel free to be a guinea pig but I'd be very worried if I had any Elm code in production (unless you are no red ink and can hire the language author)

staltz 8y ago

I author the Cycle.js framework and for a good while I considered it to be a sister project to Elm, because both had a focus on simple functional reactive programming for frontend. I've advocated Elm and been a bit in the community as well. Evan is great person, I still remember fondly the time we had good long conversations at a conference. I started the first attempt at integrating Elm with React Native, and that was only possible through hacking the native modules in various ways. I figured I couldn't progress with this plan due to how restricted Elm is regarding native modules, but also other things like naming of community modules. Elm is strict not just as a language but also as a community culture. What shocks me about the latest state of Elm and its community is how easily conversations get locked. Locking should be the last resort. What leaders block or ban indicates what they do not want to risk. There should always be the possibility of blocking to say that "we cannot afford having X in our community." and defend some basic principles. In many communities, X is just personal attacks or harassment, that kind of thing. The consistent pattern I see in the Elm community management is that X is dissent. "We cannot risk having divergent discussions (polite or impolite) in our community" is message that restricts thought freedom and reinforces cult-like behavior. It's not a good thing to have in a community, specially in an open one on the internet where membership is fluid (unlike dissent in a company for example). Curbing dissent ultimately leads to lack of innovation (which comes from freedom to create without fear of rejection), which reinforces the status of the leader as the primary source of innovation, because whatever the leader does is assumed to be never rejected. I think these community dynamics are bad in the long run, it creates more feeling of rejection, decreases innovation, and centralizes even more responsibility and power to the BDFL.

maxhallinan 8y ago
Andre's talk "The Past, Present, and Future of Cycle.js" [1] describes how Cycle was grown by the community through discussion and experimentation. [1] https://vimeo.com/216787869 https://vimeo.com/216787869

vmchale 8y ago

> Evan is between a rock and a hard place here and it's due to the current sentiment in frontend dev. Evan is suffering the direct consequences of his actions because he tried to recruit people to the community and then fucked over their production projects.