tl;dr; A humble point of view of an average backend/"full stack" developer on JavaScript. How it evolved, how backend devs stayed in JavaScript 2010 and how the gap between jQuery-JS and ES6-JS became an abyss.

Terms

Let's wrap up some terms that I'll use further:

• Backend developer - a person who writes PHP/Ruby/Python/etc. server-side code.
• Frontend developer - a person who writes complex JS/CSS/HTML.

It is about specialization. Of course all web devs are a little bit "full-stack", but only a super guru are really "full-stack".

Once upon a time...

I remember the times 15 years ago when JS world was a total mess.
For me, as a beginner home-made web developer, it was a black magic.
It was hard.

I was making some PHP sites, generated everything at backend side. Sometime I needed some "bells and whistles". You could copy-paste some "pretty gallery or dropdown menu" from some "JS libs site". And you were lucky if it worked for you. If not - there was literally no way to get "what is happening there" and the JS code was just ugly mess (at least how I saw the situation at that moment).
It was hard.

Year 2006 blown web dev world ... jQuery.
Anyone could make some easy JS trick really easy with jQuery. And more over it had such a cool plugins system. You just add some "pretty gallery plugin" and attach that gallery with simple selector. There were clear "entry points" for customization.
Then AJAX epoch. And again jQuery made it as simple as $.ajax. All that things made JS world easier, simpler to backend developer (actually we were more like full-stack in that time).
It became easy.

But "the world has changed...". SPA and cross-platform JS mobile apps appeared. First it was "ugly-toys", but then it appeared to be serious. jQuery is not enough to make SPA or a big JS app.
Backbone came to the rescue. It was hard to get some things, but it was so "jQueryish". It literally added some app structure, but allowed us to use the same old-known things we had before (that was actually the key to adoption).
It was kinda easy too.

Dark times...

One day it just exploded: Node.js, Phonegap, Konckout, jQuery Mobile (*trollface*), thousands of Backbone-based frameworks, Marionette, Angular...

Some backend devs tried to follow, but honestly - for example it is too hard to follow your PHP news and keep yourself up-to-date with every JS framework. Someone took Node.js and became happy, someone chose Backbone-based things and decided to dive in there.

I have heard of Elixir in late 2015. Strong Ruby developers just started to write something about it in their Twitter accounts - that it is a functional programming language and one can do a blazing fast realtime web apps with it.

Then I have watched this intro video, made a quick look on Phoenix framework, read really inspiring comparison "Phoenix is not Rails" and my inner Magpie Developer was alarming "looks so awesome, you must try it !". I couldn't stand :)

I have started from the very beginnig. A few pages of Elixir lang introductions. Then first "hello world" Phoenix application. And... ok, just try to breath deep and calm after 4 ms response time... it is just a dummy page with static HTML (but all routing and Plugs infrastructure involved). But it already makes an impression, as PHP shows the same speed only with empty echo "hello world"; script :)

Phoenix web framewok app structure is pretty clear at the first look. And surprise - it uses Node.js/NPM + Brunch.io to manage and compile assets by default - good start, not inventing the wheel!
It introduces a lot of new concepts compared to RoR. Of course it has not clear yet WebSockets endpoints etc., but in general by mixing it with my knowledge of middleware (Plugs in terms of Phoenix) implementations in Ruby, Node.js and PHP - I see a way to go further.

Erlang and functional programming

But wait. Have I told you that Elixir is working on Erlang VM? That is well-known and rock-solid foundation. It has Ruby-inspired syntax, but not Object Oriented, it is Functional. And that is another reason to try it out - to make your coding paradigm wider. It really breaks all patterns of data flow in web app (that were made of concrete after years with PHP, JS and Ruby). I definitely love pattern matching concept, piplines and absence of "internal state". And these lightweight threads - I could not even dream about such things in PHP :)

Next steps

Get deeper in Elixir lang docs, walk through Phoenix docs and writing some basic "blog app" to see Phoenix in real action.

And as usual some resources collection to get started and move further...

REST API design is still a topic under discussion. I'll try to collect list of resources for web developers who want get deeper into it.

Free e-books

Start with Apigee: Web API Design.

Continue with more advanced topics in Thoughts on RESTful API Design .

Addtional interesting apects are covered in HTTP API Design Guide

To get brief understanding on different aspects of API variations refer to Undisturbed REST. Also it covers some instruments for building and prototyping APIs.

Non free books

If you want even more additional info and "other points of view"

• RESTful Web Services, by Leonard Richardson, Sam Ruby (this book is available fo Free on authors site in different e-formats)
• APIs: A Strategy Guide, By Daniel Jacobson, Greg Brail, Dan Woods

Play

• Apiary - powerful service to design, prototype, document and test APIs.
• MuleSoft. Anypoint Platform - Complete platform with API Design Studio for API protyping and documentation.

Specifications / Auto docs

RESTful API concepts are clear, but big and complex app still require more predictable way to organize APIs. People try to find a way to provide standartized way for documenting and organizing REST API protocol.

• Swagger - is a simple yet powerful representation of your RESTful API. Provides tools and standard to create GUI for API docs exploration and testing.
• RAML - RESTful API Modeling Language (RAML) makes it easy to manage the whole API lifecycle from design to sharing.
• JSONAPI - a specification for building apis in JSON. With the aim to make API response data normalized and API self explanatory.

Framework specific

• APIs on Rails, by Abraham Kuri Vargas - Building REST APIs with Rails

Preamble

Mostly it is about template engines (that hide away real HTML) in Ruby (as due to app runtime specific it is very easy to add pre-compiled "sweets" there, and everybody do it). But in general such tpl engines could exist in any server side language.
I don't like DSLs and abstractions that lead me away from the "origin". Ok, a careful reader have already got what will I write further :)
This post is not about "stop using it" or "it is bad", it is about "reconsider is it really so useful".

Let's start with examples

• Ruby: ERB, Slim, HAML
• Node.js + JS: JADE, Mustache, doT, Swig (it is unified now with Browserify or Webpack)
• PHP: Twig, PlatesPHP, Dwoo, Smarty

This just a small subset of all existing engines, that I have herd of, just to have an examples. Each language has it's specific, but mostly script web languages are good template engenes by themselves.

And I am really absolutely fine with most of them. Except those that force own HTML-replacement surrogate (it is Slim, HAML or JADE like).

 body
    h1 Markup examples

    #content
      p This example shows you how a basic Slim file looks like.

      == yield

      - unless items.empty?
        table
          - items.each do |item|
            tr
              td.name = item.name
              td.price = item.price
      - else
        p
         | No items found.  Please add some inventory.
           Thank you!

And now I'll try to explain this...

This component publishes json serialisable data as 'key -> value' from PHP code into global JS variable window.gon.

Why?

The need for such an extensions came while working on web apps with mixed approach: rich JavaScript GUI on web page, but each page is reloaded and most of bussiness logic is still on the backend side.

The simples solution for a quick prototyping is pushing a data from PHP controller to global JS variable. That makes you free from a lot of REST API getters (you can make a lot without an API at all). So I did the first protype of this extension during "EU Web Challenge 2015" tasks coding. And now publish it as a standalone package.

Idea is inspired by Ruby gem gon https://github.com/gazay/gon (the name is taken from it too. "GON" authors - in case of any naming issues, just ping me :))