I have been working with a SPA application using Phoenix, React + Redux so far I see the benefits of creating SPA the main one is that it becomes simpler to convert your app into mobile but so far it takes way more time and it’s more difficult to reason for layouts than working with elixir templates, I think if you want to make your apps like SPA you can use pjax, turbolinks or other similar use the power of elixir templates since they are really fast this way you can make apps way faster and the parts that need more UX I can work with angular, react or ELM (when I learn it).
Not sure what Chris and the Phoenix team think… but maybe it could be Phoenix’s take on modern/fast web apps (much like Rails with its own Turbolinks).
Actually more I think of this the more I think it is a great fit for Phoenix. Phoenix doesn’t need Turbolinks with its super speed, but slow content such as large or numerous images, or stuff that requires heavy computation would benefit enormously from something like this.
I also agree that it helps give the app a native feel.
I like the quick rendering of simple pages with elixir templates. But that’s the only aspect that I like. I do not like to see elixircode and html mixed. I don’t want a server-side mvc. I see it as obsolete technology and I’m not alone. See all discussions on internet. I want separation of concerns.
"Well done architecture has clearly defined separation of concerns (SoS). In most cases minimal high level configuration is:
Data storage
Services
API
Presentation
Each of those layers should have only minimal knowledge of the one above. Services need to know where to store data, API needs to know what services to call and the presentation layer can communicate with the rest only through the API. Important thing to note here is that knowledge about layers below should be non-existent. For example API should not know who or what will consume it. It should have no knowledge of the presentation layer. A lot more should be said for each of those layers and the situation in the “real world” is much more complicated than this. However, for the rest of the article the important takeaway is that the presentation layer communicates with the server through the API which, in turn, does not know anything about the “world outside”. This separation is becoming more important with ever-increasing types of machines and devices (laptop, mobile, tablet, desktop). Back-end should only provide business logic and data." (see https://technologyconversations.com/2014/07/10/server-vs-client-side-rendering-angularjs-vs-server-side-mvc/ disclaimer: I don’t like angularjs).
I want the ui to be rendered on the client, and traffic with the server minimal. The server has no knowledge of the ui - it could even be a desktop application - except some config in the database. The ui config I would generate in a json (with a screenbuilder you could maintain the json frame, I mean the json with some parts that can be replaced runtime) on the server, when needed. Including validations and language-dependent things like labels. Validations can be built with a simple rules engine that you build yourself. I did it myself. The rules-editor can be built in such a way that even a user could maintain the rules. These rules you persist in a database and you put them in a dataset (a map) on the server for quick access. You use the rules when you generate your ui json and you use them for validations on the server. The data that have to be validated could come from f.e. a webservice also. This way you do not have to write your validations twice + you have made them dynamic (no code to be delivered / compiled) etc. Lots of MDD again, and lots of work to get it right, but when you have this you have something neat.
I’d argue Elm is not much better. While it’s a cooler language and probably better developer experience and paradigm it offers less in the way of progressive or server-side rendering (Elm bundles are a lot bigger than a React app too).
If your app can work fine as a sever-rendered “old fashioned” one, do it. Much simpler, less to do, and you can sprinkle JavaScipt as needed (like in the Phoenix book).
Yeah that is what I mean, sometimes you just don’t need all the complexity of creating an API and another js app. As you said ELM is cool but for example try to parse JSON with it. I have been looking to riot.js recently and it really makes sense, it’s small and really easy to learn.
It’s about a lot more, it’s not a pure theoretical or developer-fun thing. When you only need a couple of simple screens that do not need much maintenance I could understand: there’s “theoretically” nothing wrong with it then.
One simple thing: say you ditch elixir and choose another language for your backend. Or your boss chooses for you. Now you have to rewrite your “front-end”!
Besides why did you choose elixir? Cool? Better dev experience? Paradigm? Or did someone else choose the language for you?
As old Java developer I don’t like server side rendering idea like JSP (Expect you want do server side render SPA for first load).
Problems:
Sometimes you don’t have separate of concerts -> mixed business logic into fronted -> big ball of mud
Unable to easy update fronted without not touching backend on production
If you have separate fronted you can just put it on nginx
You can have dedicated team working on fronted and separate team working on backed. I know backed developers who hate javascript and and vice versa. Let people do what they love
The idea is not about SOS and making a SPA, it’s about creating the app faster, sometimes you want to have a product faster and making an SPA with it’s API takes way more time than the traditional way using AJAX and some javascript, most of the times you need to test how your product works and time is really important, Phoenix is really fast and can scale, I know you will have technical debt but you must test with the customers how the product works see what changes are needed make iterations until you see what is your real product, also I think it’s important to think ahead by making good code for business logic and then later create an API and SPA.
Have you ever seen a mature model driven development environment? I have no numbers, but I know you can develop a lot faster with these tools than with phoenix. The problem now is that you have to create such an MDD environment yourself first. It would be great when MDD tooling (preferably using modelinterpretation, not codegeneration) would be added to phoenix. Elixir / phoenix - and ecto I think - have great potentials. I’m quite sure otherwise “taking the world by storm” will become a disappearing promise sooner than you might think. I don’t doubt a lot of good work has been done and that there will be a lot of good plans for the future, but I have not yet heard plans about these in my view very important parts.
“in search of the most productive envt”: which one are you thinking of, for building a MVP please? (as for now I’m using Python/Django, people tell me to stick to it, RoR might be even faster, and I don’t know anything easier/faster for producing prototypes and MVP to show off to customers…?) Thanks!
Just adding something: I’m building now an app that an API is a basic requirement, and I decided not to implement it as a SPA. Yes there are some “duplicated code” (basically the two controllers that I need to create), but they should be different anyways, because how your client use your API should not define it.
So far, I’m very happy with the decision, it’s going very fast, a lot more than my trials with SPA applications. The API controller is very simple, and gives me a very clean public API, specifically built for public usage.
And, I got “for free” a way to deploy two separate nodes, with two OTP applications, one for my HTML server and one for the API server.
So, even when you need the API, I would say that it can be productive not to do it a SPA.
IMO, it depends totally on the way you implement it. I like to think in my apps as a package of heterogeneous components, and if you develop this components decoupled enough, you are able to replace them with whatever you want, in whatever language you want.
And when I’m talking about components, I’m not talking about “Data Storage”, “Services” or “API” kind of components, I talking about giving names to pieces of your app and calling them components, making them decoupled. You can have your API and client totally independent one from another, but totally coupled on inside.
I’m not telling that you are one of them, but nowadays people going to SPA for this reason are just turning their big ball of mud in two independent medium balls of mud, and sometimes they put some strings between them. Unexperienced programmers will do wherever they go. You can do good old fashioned code with the same effort of SPAs, and you can do y code in SPAs with the same ease of old fashioned code.
Conclusion: SPA or not SPA, what makes your system good is you, there is no silver bullet.
On your comment about what I said: I was talking about this “way of implenting”: the mixing of elixir and html. See Thoughts about Single Page Applications. You have these eex files where you put this in.
I’m doing so as a learning project: 
wherever they go. You can do good old fashioned code with the same effort of SPAs, and you can do 
