Front end development options 2017

General Prog (Archived)
41

HTML, CSS, and ES6. Frameworks and other abstractions and magic I will avoid. Sprinkle jquery and other libraries as I go.
and use something like skeleton or maybe blaze instead of bootstrap.

2 Likes
42

Totally agree with you. I just finished a rather large SPA with complex data interaction (60+ models interconnected with a variety of relations), extensive use of websockets
etc.
The backend is a json api server powered with elixir/pĄoenix (fell in love one year ago :wink: ).
The frontend is Ember.

Just for fun, I’m currently playing with Vue.js, React/Redux, Phoenix/Unpoly
 to see how I would recreate a similar app with those libraries/framework.
At first sight, what I’m missing the most is Ember Data.
For instance, Ember natively “speaks” json api (handling includes, many to many relations, meta 
). When I modeled the application, I just had to declare the models and their relations, lightly customize the serializer and adapter to fit the Phoenix server, and voilà, I could CRUD the resources.
From what I read in other framework’s documentation (except Angular), it seems that I would need to spend a lot of coding time to achieve the same level of functionality as Ember Data.
Js-data.io tends to fill this gap but it does not feel as mature yet.

2 Likes
43

Actually, i’m using Js_of_OCaml. Because I like OCaml (and the binding will be easy, for example : broadcastchannel in Jsoo.
I like Elm and PureScript, and I will try ReasonML + BuckleScript

44

JSOO is pretty awesome! It’s a compiler back-end plugin like bucklescript but targeted at the output of the processing chain, at that point all type information is lost and it is working on raw memory, that is why its output looks very machine-code’y, because it is. ^.^

It is pretty fast though even then. :slight_smile:
If you’ve not tried Bucklescript yet, you should, it hooks into the compiler just before the type information is lost so it can create very natural and fast javascript. I would recommend JSOO over Bucklescript if you work a lot more with OPAM though, although Bucklescript can work with OPAM libraries it is much more natural with NPM libraries (and there is a way to bring OPAM packages to NPM). Or if you work with PPX’s a lot, usually easier to stay with JSOO too. :slight_smile:

The output of Bucklescript is just so fantastic though, and getting better (more natural, readable, faster) with every new version. :slight_smile:

1 Like
45

I use Ember/Java at work. I have tried Angular/PhoenixFramework for a side project and couldn’t be more happy. Angular has a very low learning curve compared to that of Ember (unless you are a Rails dev). For me Angular seems pretty straightforward than Ember.

46

As hefty as the latest versions of Angular still are, I’m impressed at just how fast it is now! Angular 1 was so so very slow, but the latest Angular 2’s are very impressive.

1 Like
47

Agree. Elm is really, really nice program to in. Like, ultra amazing. If you code compiles, it works!

It’s hard to really wrap your head around how cool Elm is until you completely refactor an entire project, spend 15 minutes getting rid of compiler errors–and then it just works. Perfectly. Forever. Yay!

You would be loath to tackle the level of refactoring in other languages that you’d regularly do in Elm, for fear you’d break it permanently. And if you did, it would be a “PROJECT” with a timeline, not an afternoon’s work.

Here is a simple example of using Elm with JS interop:

And yes, Daily Drip is a great way to learn Elm and Elixir.

Vue.js is nice in that you can just drop in existing HTML and wrap your code around it, similar to .html.eex files. They are called ‘single file components’, and have html, js, and css in a single file.


https://vue-loader.vuejs.org/en/start/spec.html

If you’re looking at Vue.js, start with the CLI:

But it is pure javascript., and a lot can go wrong. I found that once you started adding a bunch of components and passing data around, things got quite hairy. It’s all about managing state, no?

Speaking of which, Vue.js state management is based on Elm/TEA:

48

Backend if possible, Ember.js if there is a real, measurable profit or a necessity for the project to succeed. And it happens like almost never: someone from the Ember core team - Yehuda Katz or Tom Dale said that Ember shines within the apps that are a kind of “desktop apps” - ERP, CRM, workflow systems, i.e. those in which user spends most of his working time and I do agree with that. Otherwise, framework maintenance cost might be just too high.

I really love doing as much as possible on the backend, especially with Elixir because of JS is a leaky language with mostly predictable behaviors across browsers. Ember solves that to great extent, but once we left a prototype until we have more resources for the app and we couldn’t upgrade it to the current Ember version one year after. That cost us around 300 man/hours and after that, I liberate myself from the seeing SPA as a “modern way to do web apps”.
There is an interest in mastering new technologies and there is an interest in doing products and I prefer the later.

Regarding Vue, I will never touch it because of two-way bindings and Elm application, IMO, is narrowed to the DOM manipulation. It was created to solve that problem and falls short everywhere outside that area so far and will do it for the next 5 years.

In the Phoenix case, page-specific JS views together with ES6 inheritance capabilities proved itself as a viable and sane solution.

Update: and also I’m looking forward to trying TypeScript on the next project.

1 Like
49

Uhh, just wait until you get to bigger projects. Don’t forget it runs on Javascript and javascript is weird, so you can do things like randomly get NaN’s in your integers and things like event handlers in the DOM break in subtle ways in Elm unless you know just how the DOM works. In addition it has a lot of typing-system bugs because it is trying to fake a limited set of typeclasses without being full typeclasses, which let you suddenly start changing types among a huge host of other basic compiler issues in addition to a host of language issues (plus slow compilation). I’d really say take a look at Bucklescript/ReasonML, at least that way you’d only be fighting the DOM and not a young language (since OCaml is very well proven at this point).

You can use Vue.js from Bucklescript/ReasonML, or you can use Elm’s TEA style with the bucklescript-tea library, or you can use React, or etc
 etc


1 Like
50

Let’s face it, everything has subtle bugs. With Elm’s are flagged, fixed and well known, whereas with React / Vue they’re usually brought by lack of programmer discipline or knowledge of FP in the case of older, more general purpose FP languages.

The best thing is, if once get up to speed with Elm you can hop to other ML/FP languages : )

2 Likes
51

You can use Vue.js from Bucklescript/ReasonML, or you can use Elm’s TEA style with the bucklescript-tea library, or you can use React, or etc
 etc


I’m interested to know how (i.e., using Vue.js from Bucklescript).

52

Brunch. It breaks module imports inside my single file Vue components. It’s webpack now for me.

Drab. The new live controller module seems amazing. Still haven’t tested it properly.

Vuejs if you haven’t already. It worke great with phoenix channels, especially for displaying, filtering and and editing lists of components.

1 Like
53

OCaml has a full FFI system via external. It is similar to typescript (in fact typescript modeled it’s a bit on how OCaml’s works) where you define ‘types’ for external calls, then you can call them as normal. That is how I, for example, wrapped the DOM in my bucklescript-tea library. Also a side bonus, Bucklescript can generate typescript type files for you. :wink:

1 Like
54

I’ve tried React, and I think that it’s pretty good. The things that I like about it are as follows:

  • The support for it is unmatched.
  • It’s very easy to drop React into an existing project and gradually migrate an interface to React.
  • It works quite well with existing, plain JavaScript functionality.
  • It’s fast to get things going and really doesn’t require much boilerplate.

However, I feel that React has the following drawbacks:

  • I you don’t have your entire interface written in React, the framework is going to give you some pushback. I feel that anything that isn’t a single-page interface app is going to give you some trouble in React when you try to hop in and out of React and regular GET requests and try to transfer data around.
  • Propagating data and up and down the hierarchy can get confusing and complicated very quickly.
  • Bindings are annoying

I’m now starting to try/learn Elm (so keep in mind I am a newbie at Elm), but Elm seems like it is less friendly to dropping it in an existing project with its own server, and all of that. So far, Elm has given me the impression as an entirely separate environment for building the interface of your application as a separate app, which I don’t like very much. I will continue on with Elm and see how it goes. The major drive for me is that much of the Phoenix community seems like favor Elm so there are a lot of resources there. I’m also interested in Vue but haven’t tried it yet.

55

Bucklescript/ReasonML is being dev’d by the same people that invented React. :wink:

I helped that drive along by pushing out a lot of examples and how it works and how to integrate it into the phoenix build system, but language and community issues around it pushed me away, like you mentioned I you don't have your entire interface written in React, the framework is going to give you some pushback. I feel that anything that isn't a single-page interface app is going to give you some trouble in React when you try to hop in and out of React and regular GET requests and try to transfer data around. and Bindings are annoying, but Elm makes that much much worse. In Bucklescript/ReasonML you can at least break out of it if necessary to make direct calls (though for sanity it is good to minimize those regardless).

Vue.js is a pretty cool library though, you should give it a whirl even if you do not use it. :slight_smile:

56

Remarkable remark.

57

Oh! I did not mean it how it looks (I should have re-read it, but overall I’m noisy about the things I find useful, why do you think I’m so noisy around Elixir ^.^), I mean that I started posting up a lot of examples of code and how it works and how to integrate it with phoenix and all such (pre-bucklescript even existing)! It is a good language, just still very young and buggy, but the style is sound (hence why I duplicated it in bucklescript-tea). :slight_smile:

I clarified it a touch. ^.^;

58

I actually really like this approach. Ember always just feels so “big” when a lot of the time I just need an ajax call.

59

This is all true, but brunch breaks your vue components, so webpack might be worth it in some cases. I still don’t like it, especially because it’s very slow.

60

Actually the latest webpack2 versions (still in dev and not released) have stated to have made substantial strides in speed, I’ll be keeping an eye out on it soon.

Also I don’t use brunch, I just use npm scripts directly since we have to have npm anyway, no point adding more stuff on top of that of which it can already do. ^.^