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.
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.
In the spirit of your general enquiries …
In my experience
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 reference to the frameworks mentioned (my “exposure”)
- Elm (2012) - now at 0.18 (no 1.0 yet)
- 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).
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.
However Elm would not really build on my JS knowledge and would not be transferable to other frameworks or even JS itself.
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.
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.
You may consider PWA (progressive web app) - so ELM it’s a good fit;
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).
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.
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
That description is for Progressive Enhancement.
What @cmnstmntmn said is for PWA’s.
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.
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.
There is also https://github.com/alexmingoia/purescript-pux for PureScript. PureScript actually has a lot of front-end stuff, some of it 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.
Vue is, like angular, html-centric. Would not be my choice.
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!
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.