I’d seen cycle.js as better than vue2 overall, though I have less experience with vue2 than I do cycle…
OvermindDL1
AstonJ
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 Separate Logic from Effects in Cycle.js | egghead.io
Perhaps as a community we could come up with what’s the best fit for Elixir/Phoenix (and perhaps at different requirements).
0
OvermindDL1
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
sotojuan
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
AstonJ
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?
0
sotojuan
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
AstonJ
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
brightball
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.
0
ibgib
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