What are you all using on the front end in 2017?
What have you abandoned?
What are you keeping an eye on?
What do you think is worth checking out?
For SPA as well as non-SPA apps…
6 Likes
Hmm, in 2016 I’ve:
- Tried React, did not like it for various reasons, way too much javascript for one, way mutable for another.
- Tried Elm, quite liked it, however the community is bit too hostile for my tastes and it has no good integration with other things.
- Vue.js had similar issues to React.
- Polymer I like, especially the webcomponent concept (I’ve made a few without polymer even), but polymer wraps it all up nicely, now if only their API would stop fluctuating (not their fault, the webcomponent spec is a bit in flux, and apple is trying to destroy a very necessary part of it, grr).
- And of course Bucklescript with my own Elm-like library with the annoyances removed. ^.^
Currently using Bucklescript + Polymer for the SPA real-time part of the app.
Using a combination of Drab and Unpoly for the parts that need to work basically everywhere via progressive enhancement, including javascript-less text browsers. I found an MIT library called Surface that is pretty old on Github that is a pure CSS variant of material design that I started using, however it was highly incomplete and a bit buggy in areas and it has been substantially updated with new features and fixes by me over time (I should probably pull it out and put it on github), it is interesting just how much you can do in pure CSS. ^.^
12 Likes
Using Ember.js for all serious (i.e. business/startup) frontend development. It’s slightly less well-known/popular than React and Angular, but made by great people, with a democratic RFC process, an eye on backward-compatibility and clear migration paths, and focused on building features instead of glue code (like integrating 20+ libraries in React). It’s what used by many of the leading companies (e.g. LinkedIn just rewrote their whole frontend on Ember and also hired one of its creators) and tech consultancies like Thoughtbot and Dockyard (see e.g. Dockyard’s Betting the Company on Elixir and Ember).
I’m keeping an eye on Elm. Haven’t tried it yet though.
11 Likes
Vue is the go to front end framework, doing stuff its way is pretty productive and clean. Default choice for SPA, I tend to do more on the server side though if I can.
Looking at React (especially React Native, have some experience with it), Elm (played with it) and PureScript (looks haskellish).
Lately tried the “back to basics” approach that worked surprisingly well: Do as much as possible on the server (Phoenix with WebSockets) including generating templates in strings, delivering them to Frontend and (slightly) manipulating the DOM with old good jQuery. This way I barely have a front end part, the whole thing is very testable and the workflow is simple enough to be very productive. It only works good for classic apps that have real-time / interactive features though, a proper SPA would quickly become a mess.
5 Likes
I’d been using Ember.js for a couple of years, but gave up on it in 2016 - it started to get in the way on what I actually wanted to do - I do like it still, and keep an eye on it, but React has proved to be a much better fit for us.
ImmutableJS, MobX or Redux, StyledComponents and Apollo, all mixed together with Webpack2 and hot-reload, and I have a very nice (IMO) setup for knocking out frontends. I’ve started to build up a nice collection of components that I can re-use in various different projects. (I’ve been using an Atomic Design type structure for components which makes it a bit easier)
3 Likes
You should try the Elixir Drab library for that, it is quite useful. I’ve been using it with unpoly.js instead of jquery, but works well with anything. Built-in support for jQuery though. 
5 Likes
I’ll jump on the Ember.js train here. I’ve been using it for the past five years and it continues to get better and better. Unlike all the other flavor of the month javascript libraries, you can rest easy knowing that there is always an upgrade path, a commitment to stability, and an aim to solve your real-world pain points when building large SPA apps. You know… the things your customers like 
I’ve done the tour of React, Elm, Vue stuff… honestly, they need a fully supported framework to be productive. Whichever supporting libraries you pick you will be declared a monster in six months by the community and forced to rewrite everything 
You can’t build a spa without networking, storage, routing, serialization, validation, CSS, tests, and state management. Wouldn’t you rather have something that an entire community supports and has massive test suite around?
However… this only applies to the situation where a single page app actually makes sense. If you can get by with a handful of React components and some vanilla javascript, then you probably didn’t need to go full SPA.
In the cases of non-full spa… it’s mostly React. It’s still a pain in the rear, but the component life cycle makes things fairly easy to reason about and most people have a decent understanding of how to use it these days.
I want to love Elm, but it just seems too early to go all with it.
TLDR for 2017: SPA == Ember NonSpa == Sprinkle of React
4 Likes
I’m curious, is this a popular opinion? I also have the feeling that the BDFLs are not really approachable from my observations on the mailing lists, but I admit I’m not really involved. I’m still keeping it on my radar though, and made a couple toy projects with it, but I’m not really into front-end dev lately, it’s just so convoluted.
Basically my view also 
3 Likes
Yep, I’ve looked into it some time ago, didn’t want to use it just yet because of the experimental status - the app had tight deadlines and other (front end) guys working on it so I was unable to use it to play with too much new stuff
The idea is simple enough not to abstract it away though and I pretty much did what Drab does, just on a little lower level.
using it with unpoly.js instead of jquery
Looked at this one, again pretty much the same idea - it’s nice to see that other people do the thing you accidentally tried and liked
3 Likes
Just moved from Ember.js to Angular 2. Couldn’t be more happy.
2 Likes
After doing a year or so of frontend work (2015-2016), I thin my options for 2017 will be no SPAs or complex JS frontends
I do like Ember’s philosophy and leadership, they’re nice and awesome people, so I keep an eye on them.
2 Likes
Huge dashboard and IDE built in React, with Phoenix Rest + Channels endpoints.
3 Likes
In my company in 2015 we used backbone and jquery for integration on frontend and angular 1 for a SPA.
In 2016 we tried react (redux) for new features, abandoning backbone and jquery.
In the last two months of the year we pass to elm and we plan to use it for the new developments.
Backbone and jquery are “old style” javascript programming.
React has a lot of code to write and despite underline the reuse of components, it’s very difficult to implement something really reusable.
Elm seems to be really promising, with functional approach and immutable data; it is statically typed and the compiler is powerfull. I’m not yet personally used.
3 Likes
2 Likes
(A little background first: I know Vue the best but I’m not an expert, Ember a little, and I’m almost new to Elixir.)
I see some enthusiasm for Vue on this thread, but less than I expected. I’m curious to know why that is. Here’s the case I’d make for Vue:
– It’s very simple to get started with. I started building a basic but non-trivial Vue app (not an SPA) after reading just a bit of documentation. I just used the main Vue library which meant no build step was needed. I actually felt the code I wrote would be really easy for a JavaScript developer to understand without having any knowledge of Vue at all.
– It’s flexible. You can add extra pieces (Vuex, etc) as and when you need them to turn a basic app into a full SPA. Presumably these extra pieces integrate well with the basic Vue library?
– It doesn’t abstract much on top of JavaScript, so it helps you improve your JavaScript skills. (Is this true? I think I’ve read this before.)
– It’s become hugely popular on Github in 2016, so a lot of developers are clearly impressed with it.
So it’s possible to add a very lightweight Vue layer to an Elixir/Phoenix app at first, and then you can add pieces and work your way gradually towards a full-blown SPA if you want to. What’s not to like?
Compared to this, Ember and Angular 2 feel potentially like overkill, while React has a build step, and I’d prefer to put off learning any front-end build tools like Webpack for as long as possible (forever?)
So I’m curious to know what the downsides might be. Too mutable? Just not a good fit with Elixir/Phoenix? Is the ecosystem not mature enough yet?
5 Likes
I’m also very much on board with vue.js. There are a couple points for me to get to this conclusion:
- Not as boilerplate / buildstep heavy as react or angular (try plain js modules instead of .vue files)
- Not as rigid as elm, which seems nice for heavy stateful / involved js apps
- Can be used bottom-up style from simple event-triggered dom changes to handling a full SPA
I especially like the last part, because I can use vue to replace simple tasks (prev. jquery stuff) in most cases and on the other hand have it handle bigger more involved js interfaces in other parts of my app. And if I need it it’s as capable to power simple SPA things, but that’s not really a focus for me.
7 Likes
We use React mostly. With Redux or other similar thing, depends on project.
We have abandoned Angular (v1), Backbone, Dojo (anyone still remembers?), marionette and Ember.
Having said that, we will probably abandon React too.
As others pointed to https://github.com/grych/drab this is something I’m looking into. Also in combination with http://unpoly.com/.
It’s great that those things are possible since we have way better performance and concurrency in Elixir than we had in Ruby. I’d reject the idea straight away when doing it from Ruby. With Elixir this has a chance of successfull application in many projects. Not New York Times frontpage for sure, but many others will work well.
I do think, however, this is not yet good enough either. It takes step back, but I think we could steal more ideas from the 2016/2017 top front-end stacks. Most notably, virtual DOM and partial updates.
I am thinking about something similar to Drab, but that works with remembering HTML that was initially sent to client. A DSL similar to ReactDOM JS API is used to both: render initial HTML page sent out using GET, and then to render updates. VDom diff is computed, sent to client and update on the client-side.
This would have a lot of advantages (and some disadvantages). VDom is great for updating forms/inputs, since you don’t loose focus/state in native HTML controls.
4 Likes
this actually looks pretty cool
2 Likes
