I have noticed that several Phoenix examples on github are built as JSON API’s only. I am curious, which JS libraries to be used on the front-end to consume / interact with those JSON back-end API’s? Preferably, libraries that support rendering nested forms for adding / editing nested associations. Thank you.
1 Like
Currently really into marko.js
2 Likes
I like svelte.js.
I have to say RE:DOM. After working with huge frameworks like AngularJS, I love the simplicity of RE:DOM. It does only what’s needed to get rid of the biggest pain points with DOM interaction and then gets out of my way. I also feel like there’s a sort of irony with the fact that we started with direct DOM manipulation and it was slow, then we invented virtual DOM and it was fast, now RE:DOM is doing direct DOM manipulation again and it’s really fast. 
1 Like
I’ve been playing with mithril.js recently haven’t quite formed my opinion yet. But I do like how fast it loads.
2 Likes
We made a one-week workshop in our company to find the most compelling front-end JS framework back in february. We compared angular, react and vue and decided to use vue because it is very easy to use and well documented. Really enjoying it so far.
2 Likes
I prefer React. It’s very simple, and it’s widely used so there is a lot of documentation and the googleability is excellent. If you need even more speed, there are alternatives like Inferno which is very performant and has the same API as React.
I’ve also looked at Vue. Conceptually it’s very similar to React, but the larger API and the special markup syntax adds unnecessary complexity, imo.
I’ve also done a lot of Angular the last ~3 years, both 1.x and 2/4. I would recommend staying away from Angular. While Angular 4 is better than 1.x it has A LOT of accidental complexity, informed by Java-esque OOP. Its popularity also seems to be fading rapidly.
3 Likes
Yesterday, I experimented little bit with Vue.js, still learning the basics. Would be nice if you give your opinion on my other question at:
Thank you.
2 Likes
I’ve played around a little bit with mithril and I think it is great and I wonder why there is not more buzz around it. It is small, fast, loads fast, has great documentation, comes with batteries included and has tutorials on how to solve the common questions (such as how to do animation with vdom, authentication, drag’n’drop).
But, the thing is, I am not just disciplined enough to write javascript so I am looking more into Elm and recently bucklescript-tea which is the same architecture but with ocaml.
I am going to use Elm for a new dashboard prototype for work and I might just implement it in mithril as well for comparison, will be interesting to see how it pans out.
2 Likes
Also check out the other threads in this section… as well as this thread:
I am experimenting currently with Vue.js (day 2), looks pretty good.
I really like aurelia for a more structured application (think angular/angular2-4), however for simple things markojs is really straight forward. Good luck!
My beginner experience, for what it’s worth 
Angular, framework alone, minified = 164kb.
Polymer + basic website, minified = 84kb.
Native Web Components + ES6, same basic website = 17kb.
At the moment the website is at 172kb, 10kb more than the entire Angular library, it’s 49 sections with 30+ SVG icons included.
I can’t even begin to imagine what size it would have if I used a framewrok.
It was also far easier to write native Web Components + ES6 than to use a framework.
Not to mention the escape from the “Oh it’s 2018! Time for a new Angular/ Polymer/ w/e version! Rewrite your entire app!” fiasco.
Web Components + ES is my vote, as much as I hate JS.
4 Likes
Last time I looked into mithril was just because of this webcast, its very cool that the code in the “video” is editable.
Very interesting teaching tool.
1 Like
Web components are absolutely awesome! I wish they all followed that style!
Polymer is just a fairly thin layer over the webcomponent spec, it is not that large depending on what you use. Plus even with native you’ve still gotta use the polyfill’s in most cases. ^.^;
But yes, definitely web components.
3 Likes
Ember is my goto front end framework, especially when we’re talking about an API that returns JSONAPI formatted data.
3 Likes
I really like to use http://elm-lang.org in the frontend. In my opinion it simply gives you a very pleasant and fun experience while programming. And I guess especially when you come with some functional knowledge 
One I haven’t tried yet, but sounds great to me in theory is https://reasonml.github.io/guide/what-and-why
It is based on Ocaml and uses a lot of react ideas and the known boilerplates from the common js frameworks.
Have fun trying 
1 Like
You can use bucklescript-tea library in ReasonML to have an Elm-like interface/api if you don’t prefer the react one too (and it outperforms the react one as well! ^.^). 
I know you are asking about favorite JS frameworks, but keep in mind, you don’t need to structure your Phoenix App as a JSON API only web backend. You can (and in my opinion should) use the Phoenix Views and Templates to write your HTML code, and add JS when absolutely required. (you can see how much I hate JS by now 
)
Have a look at AlloyCI (a project I started) if you want to look at a Phoenix app that uses JS only when necessary.
6 Likes
I have just started this week experimenting with Phoenix as API backend only and VueJS at the frontend. One advantage I have noticed so far with this set-up is the immediate navigation / transition between app components / pages. With JS it’s immediate and smooth, whereas with Phoenix HTML there is some time delay when navigating between pages.
However, no doubt it is easier to have Phoenix deal with HTML (for example, when conditional rendering based on user variable is needed). It is also easier to maintain and structure. Using JS only when necessary is ultimately the way I will built future projects.
