It’s nor unfair indeed, but in the competition for user mindshare, it might lose future hsers to other applications that do not require that. We have an embarassment of riches in the web framework department. I’ve only used python frameworks and some JVM based ones. Python alone gives you Django, Flask, Pyramid, Websauna (on top of pyramid), aiohttp, sanic, falcon, CherryPy, Tornado, Twist. The JVM gives you several languages, each with one or more frameworks, like java (Spring, Spark, too many others to list), clojure (Luminus, noir, but it’s mostly DYI based on something like plug), scala (Play, Scalatra, Liftweb), kotlin, etc. This doesn’t even touch frameworks written for C, C++, go, javascript, ruby or many others.
Most of these frameworks are quite similar to each other (i.e, they consume requests and spits responses – booooooring, that’s so '00s!), but they all create noise. At the same time, some are obviously better than others for some uses, even within their sometimes limited capabilities.
A newbie doesn’t have time to run framework.new for every framework out there. This is not a value judgement, it’s just a fact of life. I’ve done it for most python frameworks, but I can’t do it for all frameworks out there. So frameworks must have some way to convince users to try it. For me, it was @chrismccord’s video in the phoenix’s website here. But the video is not thaaat convincing in general for a newbie. It convinced ME because I had a prototype of a web application I couldn’t make work with anything else the way I wanted it. But newbies often want to learn a tool to build something, to get “something” out there. And that video is not convincing for those use cases. I do believe that phoenix is the best tool for almost any web application, unless some other language already has something prebuilt that is just perfect for your project (libraries, frameworks, etc). But nothing in the docs/forums or videos would convince me of that.
To capture newbies, Phoenix must sometimes say: Phoenix is your application! Dump stuff into the controller! Request comes in, response comes out! Web apps are interfaces to a database! 90% of all web apps are CRUD and phoenix is very good with CRUD! Phoenix is Rails + websockets! Even if these are all either bold faced lies or very stupid marketing points.
This is what gets you newbies, not 9 nines of reliability, not code swapping, not references to boring european Telecom companies. I mean, these things totally got me, but I’m not thaaat newbie.
Now, it’s totally OK if you don’t want to get very green newbies, or if you don’t want to get them hard enough to use my sentences above as marketing points. Some users in this or other threads have actually said that too many newbies is not necessary a good thing. But to be really appealing to newbies, Phoenix reeaaaly needs to up its marketing game.
Another problem is the fact that many inexperienced people seem to be jumping to a release candidate that doesn’t even have a proper tutorial that holds your hand through an entire application.
But in any case, I think some concrete steps might help newbies and even some more experiences users that are struggling with contexts.
What might help newbies
First, from the point of view of the general documentation:
Django has the django tutorial. Flask has Miguel’s mega tutorial. Pyramid has the official docs and multiple tutorials. They all walk you through an example application, through which you can get a feeling for how an app is structured and why things are the way they are. Phoenix has some docs for 1.2 that are as good as the ones I’ve linked, but nothing that deals with contexts…
Newbies NEED and example of an application using 2 or more contexts with real boundaries, in a way that makes sense, even if it is a small application or almost a toy. As long as it’s real code it’s good enough. We don’t have anything like this yet, and we should. This is something I’d like to do, but for which I unfortunately have no time right now.
This is even more important if Phoenix wants to capture newbies that are learning Elixir as their first backend app (well, second if you count JS as a “backend app”). I came to phoenix already knowing what DB abstraction layers, models, routes were. Each of this things is a stumbling block. Functional programming (which is much simpler to me than any of the alternatives actually), processes, OTP (even if you can do stuff without knowing what this is) and Supervisors. Now, add the 3-4 levels deep abstraction (as I explain below) of contexts, and you might get the:
Second, from the point of view of context generators:
I think contexts are a very good thing. They are a nice way of organizing the code and very useful even for relatively small apps. But they are also a little abstract. In the end, a schema is a subset of DB columns, and a context is a set of schemas. If you think like this, you can actually draw some pretty Ven diagrams or some pretty tri-partite graphs. But a command line interface is not a very good interface to something that draws tri-partite graphs.
A way of visualizing DB tables, schemas and contexts graphically would be very helpful for some visual thinkers like me. Double so if you could actually plan and generate your contexts/schemas/migrations through a visual interface. The stack from contexts to DB tables is 3 levels deep (and 3 files away!). Also, migrations are “deltas” of tables, so you can count that as a 4th level.
(and for the express purpose of learning) I think this response indicates you are too close to phoenix (understandably) to understand the issue and its causing you to be quite unfair in your response to Shrike here.
