I’m asking this because I don’t know if I should learn Elm or polish Vuejs and vanilla javaScript.
4 Likes
It depends on your target. Do You want to do web? web and mobile?
Web and mobile.
For this very same target, I choosed to go the React way, because the target is wide.
But there are many valid solutions.
- Flutter, backed by google, dart language
- React and React Native, backed by Facebook, JS language
- Vue also can target mobile, JS language.
I am not sure if ELM is targeting mobile.
I do not like JS, but it’s useful when You separate Backend from Frontend.
I am also looking to switch to FP frontend, with ReasonML, Bucklescript or any …script.
But for the moment, I am fine with a Phoenix/Absinthe API, and React/React Native, Relay modern on the frontend.
6 Likes
I had the same target and wanting to avoid JS decided on ReasonML with ReasonReact talking to Phoenix over Apollo GraphQL. Really liking this so far despite smaller community at this point.
Targeting mobile is difficult with Elm (although a working experimental package exists) also if you need a lot of JS interop it’s more arduous. With ReasonReact you can easily use React Native.
Alternatively if you don’t mind JS then Vue (with Weex or NativeScript-Vue) or React+RN are fine whatever you like better when trying them out.
3 Likes
In the spirit of your general enquiries …
In my experience
- JavaScript avoidance strategies do not work - they simply leave you weak in an area where having strong skills (really) is a requirement. Once you have strong JS skills it can make sense to look into a transpiled language to make your life more pleasant or better yet, to add sound static typing (I personally don’t count TypeScript). In some ways the trick is to also program outside of JavaScript.
- When learning a client side web framework/library you are just learning that - you don’t magically by osmosis somehow learn how to build good web app frontends - ultimately that still requires a solid understanding of HTML/CSS/JS (and how the web works in general). Also web frameworks/libraries come and go - for the time being JavaScript is still here to stay - WebAssembly notwithstanding.
Designing for mobile can be done with “mobile first CSS” - Example: sidecar.us (github) by Keith J. Grant (author of CSS in Depth).
Now I understand that HTML/CSS are utterly boring (and at times incomprehensible) from a programming point of view but them’s the breaks.
The complexity of client side rendering (SPA) only really starts to pay off when you need highly interactive features or when you are moving into a space where processing is done on the client side (e.g. serverless). There are plenty of testimonials that SPA technology will slow down the development process (and will make it more (and sometimes unnecessarily) complex).
The Mozilla Developer Network has some guides to fill in any HTML/CSS/JS gaps that you may have.
In terms of JavaScript You don’t know JS is often recommended but it is largely ES5 based and it is becoming increasing important to be able to understand ES2015 and beyond - which is why I’m mentioning Practical Modern JavaScript/Mastering Modular JavaScript (online) here (http://javascript.info/ also recently appeared).
In reference to the frameworks mentioned (my “exposure”)
- Elm (2012) - now at 0.18 (no 1.0 yet)
- React (2013) borrows Elm’s ideas back into the JavaScript space. Now v16.2 - note that in 2016 v15.0 followed version 0.14.
- Vue.js (1.0 October 2015; 2.0 September 2016; 2.5 October 2017) now at 2.5.16
Vue.js is easy enough to get started in but ultimately the way it’s reactivity system embraced mutability didn’t sit well with me (though that could simply be a matter of personal taste). Also unless you give the documentation a good deep dive you may end up being surprised by what and when things become reactive (or not).
I only ended up back at React because of ReasonML but in order to use ReasonReact previous React knowledge is assumed - knowledge that is usually documented in the JavaScript space. In my opinion lots entry level React material takes an oversimplified approach that overemphasizes components while not highlighting design for composability. And then there are a number of JavaScript React practices that don’t translate to ReasonReact, creating a strange “React the good parts/React the bad parts” kind of situation.
In the end there isn’t a “perfect” (framework/library) solution, something designed for complicated implementations is just going to weigh you down for simple solutions, something designed for simple cases will likely turn into a hairball if your solution has complex needs.
55 Likes
I prefer to use React because I’m familiar with it and I don’t have to learn a new JavaScript-based frontend language. With React, most of my existing JavaScript knowledge is applicable and it helps me learn JS better as it doesn’t really abstract any JS away, just DOM stuff.
However Elm would not really build on my JS knowledge and would not be transferable to other frameworks or even JS itself.
1 Like
At work we use Vue.js for the front-end of our Phoenix app. I really like working with it to be honest. We started out with a server rendered HTML + bit’o jquery thing and I wish we’d used Vue from the beginning - its a bit more work I guess but its easier to reason about and is a better user experience. While it embraces mutability it does so (if you use Vuex) in a very disciplined way with one-way data flow that doesn’t bog you down in nearly as much ceremony as Redux does with React.
React is fine too and like kokolegorille points out it has a very mature solution for native mobile. (Vue has something too but it is not nearly as mature or well-adopted even as Vue.js is). If you wanted to use Typescript then React will benefit more from it than Vue will, because your JSX code is typed too so all the props you pass to components for example will be type-checked.
As far as Elm - I think its architecture has done a lot of good for front-end in general, but the platform is so hostile to foreign code and the language itself has been dumbed down far to much (Haskell w/o typeclasses!?). It has really no facilities for generic or meta-programming, so for example there is no way for it to automatically derive or generate Json serialization code into and out of its native types, you will write all that code yourself, over and over. All that I could probably look past if the compiler were not so slow, but it is VERY slow, page refresh times will be measured in multiple seconds right from the beginning, I would hate to see it in a large project.
11 Likes
By the way, for the people (like me) who like Elm but are actually used to Haskell with its more advanced features like typeclasses, there is miso. It is an amazing tool, but its compilation times are even longer than Elm’s, because of the Haskell+GHCJS stack underneath.
3 Likes
You may consider PWA (progressive web app) - so ELM it’s a good fit;
This is the first time I’ve heard the term Progressive Web App. Does it mean a web application whose core functionality does not use any JavaScript, but the user experience is improved by adding features?
I have used a little bit of Elm myself, and I have used a little bit of React. Of the former, I think it is both an advantage and a drawback that you don’t use JavaScript: On one side your code might become easier to read because there is less ceremony here, on the other hand it is harder to connect to the rest of the front-end world that is written in JavaScript. (and it definitely is harder to get started with it unless you’re already somewhat used to the Haskell syntax).
React on the other hand, is very interesting with its notion of JSX that is close to HTML (unfortunately with a couple of minor but important edge cases). However, I find React’s default execution model to be a quite messy way to do Functional Reactive Programming, because every component can mess with its own state (rather than passing the flow down from the far top).
Flow managers like Flow, Redux et al. try to fix this by altering the execution model to again be more close to what Elm does by default, but they are yet another tool to learn (and there is a lot of React stuff out there that does not use them, making this issue somewhat confusing for new users).
So I’d say Elm’s largest hurdle is its syntax but it has a very simple and easy-to-understand execution model, while React is easy to get started with as an existing JS developer, but the amount of not entirely transparent magic that is going on can confuse people (as well as the eas of introducing mutability in places where React really requires immutability for its rendering model to not break down).
3 Likes
No; it’s a pure html5 responsive website and it can be used as an app.
There’s no need to put it in any stores (App Store, Google Play, etc).
You have also acces to notifications API and other things that an installed app has.
More on PWA: https://developers.google.com/web/progressive-web-apps/
And a list of websites that behave as PWA’s http://pwa.rocks
PS: in order to work the website must be served over https
3 Likes
I know Vue and React are targeting similar use cases… And when it comes to choose one of them, it boils down to personal taste.
“React kind of attracts a lot of functional oriented programmers. Vue attracts a lot of people who’d prefer the more classic HTML, CSS & JavaScript model of development. And Angular attracts a lot of people coming from a Java or C# enterprise background.” – Evan You, creator of Vue.js. https://blog.hackages.io/https-blog-hackages-io-evanyoubhack2017-cc5559806157
100% agree, it all boils down to personal taste. React and Vue are targeting the same use cases and both work well with large communities. I don’t think you can go wrong trying out both on a small project (assuming the project requires enough client interactivity to need them) and see which clicks better with you.
1 Like
There is also https://github.com/alexmingoia/purescript-pux for PureScript. PureScript actually has a lot of front-end stuff, some of it[0] actually popular out on the job market. Pux isn’t necessarily one of them, but user experience-wise it’s a good implementation of the Elm Architecture.
1 Like
Vue is, like angular, html-centric. Would not be my choice.
https://medium.com/@CalinLeafshade/why-i-chose-react-over-vue-3dd9a230b507
Sincerely, that’s just non-sense.
If you know react or prefer the way it looks and organises your code (edited to remove -weird preferences- reference, it was meant to be humorous but someone might actually take you seriously) then by all means go react. If you don’t know React and are picking up what to learn, I sincerely can’t see any reason to go React instead of Vue because for me it looks much more sane when it comes to code organisation (as long as you use single file components, vuex, etc) than any of the react best practices examples. None of the arguments I’ve seen for React really make sense, the ones that do and are really valid in my opinion are :
- We have already invested in React, we know React, JSX and redux, since both Vue and React are very similar there’s no gain for learning vue
- We don’t like having neat files organised by Markup, JS, and CSS, we prefer to go through a lot of render functions, that look just a bit worse than a vue component with directives, and are not organised in the way they are going to appear in the dom (edited to remove a potentially unfair and insulting line since I didn’t meant it to be read as if it was referring to anyone here…)
- We don’t really know what to use so we’ll just use what is more popular
- We are heavily invested in making mobile apps, we don’t speak chinese so Weex is more difficult to grasp hence React and React-Native offers us a much better way to build those mobile-apps off the same webapp codebase
- We don’t like the way the name Vue was meant to imply “View”, we think it’s a bad word play by someone not native to the english language
Vue is great!
1 Like
Conceptually Vue and React are pretty similar. I would not have a problem working with either one, but I prefer React because its simpler (smaller API surface) and because it avoids adding its own templating language to HTML. Your post is meant humorously, I suppose, but with that kind of rethoric you risk coming accross as disingenuous and aggravating.
