There is no right answer it’s application specific. You are just balancing sets of tradeoffs with business requirements.
About seo I never thought. Never had a need. I read that crawling spa’s not a problem anymore with google: https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html. Worth a case study?
This is an interesting read (in part about seo) I find: https://www.airpair.com/javascript/posts/the-tipping-point-of-clientside-performance , but the new google crawler is not mentioned.
Concerning initial render-time I would stick to the rule of the thumb: first a good architecture, then optimize performance.
1 Like
Ooo, thanks for the links, not read about that yet. 
Great to see that SPA’s are indexable by Google now.
It still an issues that’s why the whole isomorphic/universal js thing exists in the first place aside from faster initial render (Including Angular 2 Universal). It’s nice to not have a need for SEO but for majority of external facing apps it’s obviously a big concern. SPA is not automatically “good architecture” or even “better” it’s all a function of requirements you have in any given case. There is no good by default architecture it’s specific to requirement of a given project. Every bullet point you listed as a pro of SPA has a set of cons that you have to accept. BTW I am not against SPAs we build a lot of them but it’s good to have realistic understanding of tradeoffs one needs to make.
1 Like
Havn’t used it myself, but it seems that are already some solutions for serverside rendering for React and even Elm. Of course I haven’t used this in production
Personally I find it hard to decide on one or the other. I work with React a lot and love it. But taking into account that the the inventors of React trump that the greatest innovation of React is compenentization, we already have that in Phoenix. I also feel that all that power that React gives us will result in more complexity and it’s ecosystem is very much oriented on a JavaScript backend (although changing a bit lately).
I haven’t used it enough, but a worthy alternative looks Vue.js. The greatest benefit is that you don’t have to use a virtual DOM, and can still render your (initial) HTML, and from there pick it up with Vue.js.
Some interesting links (not with a Elixir backend):
You’re Missing the Point of Server-Side Rendered JavaScript Apps
Experimentally verified: “Why client-side templating is wrong”
Don’t forget that a big reason for universal JS, for companies like Twitter, Facebook, is support for old devices and countries with slow internet connection. For most application this isn’t an issue at all.
Also, from what i’ve read the whole SEO not working on SPA thing seems to be a thing of the past.
1 Like
It’s not a thing of the past and will not be a thing of the past for a long while.
1 Like
Could you eloborate a little more? Should I read it as: SPA’s are indexed by search crawlers, but will not offer the same SEO as server rendered apps?
Martin.Fowler.Thoughtworks
3 december 2014 ·
Retweeted Justin Searls (@searls):
“Isomorphic JavaScript” is a new term that describes software systems which are a total >mess on both the front-end and the back-end.
No, isomorphic javascript is not a mess, it is “a function of requirements”. 
SPA’s might or might not get indexed by a crawler Panda might or might not penalize you. Google’s crawler will try to index an SPA but it has aggressive timeouts undisclosed limits on number of requests it will process number of js files you can have and it does not support # urls Service Workers, the Fetch API, Promises, and requestAnimationFrame among other things.
1 Like
Vue2 supports templating, JSX, and progressively scales with routing, state management, and possibly native mobile (weex, beta?). It competes and exceeds React in every category (my opinion) except community mindshare. It has big international mindshare, from the likes of Alibaba etc., though.
Both Vue and React don’t have to take over your entire page. You can use bits of Vue or React. Just target #vue-app and #react-app in their own divs. I think Elm also can do this, but it outputs the source into a giant JS file.
Vue would be perfect as an elixir front end with server side rendering support straight from Elixir/BEAM if there was a library to do JSON-IO similar to react-stdio.
The templating DSL of vue is nice and simple (and you get JSX support, too!). It’s easy to see what’s happening at a glance in vue components, and it’s super easy to unit test.
1 Like
I’d seen cycle.js as better than vue2 overall, though I have less experience with vue2 than I do cycle…
I hadn’t even heard of Cycle.JS 
We really could do with a wiki about all these front-end options @OvermindDL1 
_Here’s a course on Cycle.js https://egghead.io/lessons/rxjs-the-cycle-js-principle-separating-logic-from-effects?course=cycle-js-fundamentals_
Perhaps as a community we could come up with what’s the best fit for Elixir/Phoenix (and perhaps at different requirements).
Lol, I heard of cycle.js before I heard of vue. ^.^
And yeah, it is a huge list of front-end things, javascript is beyond even the very definition of fragmented. ^.^
1 Like
I don’t think any one is a better fit for Phoenix… I mean just about anything that takes in JSON and turns it into HTML is a good fit. People will use different frontend technologies based on their location’s market, hype, or use case.
Dockyard uses Ember for example, but almost every JavaScript job where I live (even those with Elixir backends) uses React or Angular.
2 Likes
Shall we start with a basic wiki and then just append to it as and when we need to? @OvermindDL1 I think it could help a lot of people
@sotojuan, that’s true, although I do think having some discussion about the options (and how they might relate to Elixir) could prove beneficial. Best case scenario is the Elixir community backs a certain front end tech and that helps give that tech a really good chance of succeeding. What do you think?
Sure, I don’t mind. As long as there are actual reasons for why it’s a good fit (I keep seeing people say Elm is a “perfect” fit but giving no reasons why outside of “they’re both functional”).
A good baseline are technologies that follow at least a bit of convention over configuration.
1 Like
I agree - perhaps we could have a series of threads:
- Which front end technologies make sense when using Elixir / Phoenix (Discussion thread)
- Shall we as a community back a certain front end technology? (See if there’s merit in the idea)
- Front end technologies that the Elixir community favours (Results from above two threads)
None of this would be set in stone btw, if it transpires this initiative is not going to work we can just ditch the idea.
Personally I think settling on a few stacks for different requirements could well prove beneficial in the long run.
Anyone else think this is worth a go?
1 Like
Separation of rendering, display and site breaks from the maintenance burden of browser differences and vulnerabilities is also a factor in server side HTML. Before JS framework lifecycle is even brought to the discussion.
I think this is a great idea. 
I’m in the middle of deploying the first stab at ibgib (v0.1.0) which uses server-side rendering + plain vanilla js (mostly relying on d3.js) to simplify development. But I inevitably need a real solution on the front end, so I’ve been keeping a watch on this thread and others similar to it.
So your idea of a slightly more formal wiki of the landscape would be a big help. I would only hope that in addition to what “should” be a good stack, that we also encourage anyone who lists in the new Showcase category to include what they are actually using WRT front end and how they communicate with the back end (channels/sockets, json api, etc.). This way, we could see real world 
examples of the end result of the stack.
1 Like
