Pull out of Pheonix?
vans163 opened this issue · comments
I think this will really differentiate Drab from LiveView.
For my usecases I often dont use Pheonix because its just so bloated. I need a VERY TINY http server with minimum functional. Infact I wrote my own for the usecase as there were not any at that time, Cauldron only, which was broken as doodoo, ex, automatically parsed a cookie header and crashed if a ; was present at end.
If it can be pulled out of pheonix and made modular, so can be used with Cowboy, Mochi, etc I think it would be really a strong case.
This is tempting.
Drab is strongly attached to Phoenix, but it could be another low-level library, which Drab could be based on.
The new library (codename Drut) must expose only three functions:
Drut.exec_js/3to execute JS on the browser on the serverDrut.broadcast_js/3to broadcast JS- In the browser,
Drut.exec_ex()method to execute function on the server side (similar to Drab's Drab.exec_elixir())
Drut must have the own transport (websocket, longpoll?, others?) and must be used directly with Cowboy, without any of frameworks.
Then, the next step would be Drab 2.0 which would rely on Drut, instead of Phoenix Sockets.
The, we could create Drab-like libraries to the other web frameworks.
If possible, it'd be great to also include https://github.com/CrowdHailer/Ace in this. It'd require abstraction even beyond cowboy, though, so I could see this not being a tempting first step to take.
Both exec_js and exec_ex must have async and sync version, broadcast_js is async only.
Cool. I want to start contributing to drab. I spent a lot of time on ElixirScript, React and state differentials because im lazy and don't want to code a lot. I think drab is perfect fit here to allow me to be even more lazy :).
I think the concepts in drab are the future. Is there a developer slack/discord/irc/etc?
You are very welcome!
There is no official channel for developers, as I am doing it mostly myself. Some concepts were discussed on exlirforum, as I did announce the new features, ideas there.
For my usecases I often dont use Pheonix because its just so bloated
I don't want to derail the conversation much here, so I'll be brief in disputing this claim. Drab can by all means work to remove the Phoenix dependency, but claiming Phoenix "is just so bloated" is a blatant mischaracterization, especially in the context of Drab, which builds on our primitives :)
What Drab (and you as a user of Drab) get out of the box because of Phoenix is our robust realtime channel layer, including the phoenix.js channels client with connection recovery, exponential backoff etc, as well as Phoenix PubSub, which is a distributed PubSub layer, which powers all the server -> client updates. So given Drab is built on these primitives, the only other "bloat" we have is... controllers and views?
To be clear, @grych has been nothing but positive and Drab going this route is fine, but blatant mischaracterizations like the above are not :)
@chrismccord, true, Drab is and will be "Remote controlled frontend framework for Phoenix".
This is not going to change. This discussion may bring the birth of the new entity, which will not be Phoenix-based.
Closing as it is not related to Drab. For now :)
For my usecases I often dont use Pheonix because its just so bloated
I don't want to derail the conversation much here, so I'll be brief in disputing this claim. Drab can by all means work to remove the Phoenix dependency, but claiming Phoenix "is just so bloated" is a blatant mischaracterization, especially in the context of Drab, which builds on our primitives :)
What Drab (and you as a user of Drab) get out of the box because of Phoenix is our robust realtime channel layer, including the phoenix.js channels client with connection recovery, exponential backoff etc, as well as Phoenix PubSub, which is a distributed PubSub layer, which powers all the server -> client updates. So given Drab is built on these primitives, the only other "bloat" we have is... controllers and views?
To be clear, @grych has been nothing but positive and Drab going this route is fine, but blatant mischaracterizations like the above are not :)
bloat Full of features I don't need and wont use that are forced upon the user, like setting up a MVC hierarchy which does not really fit anywhere in post 2010 unless your still coding in PHP, touching /config, pulling a crapload of deps, also writting a bunch of boilerplate code just to return hello world to the user. :P
So yea its not bloated, just rich in mandatory features.
Phoenix was the only basement I could start doing Drab on. Drab relies on a lot of Phoenix features, channels, eex engine. I would never say it is bloated.
Actually starting new library which will not depend on Phoenix would be like rewriting half of it.
Please be more moderate on your opinion. We are on GitHub, not a Twitter! There is thread on elixitforum about this, please move the discussion there.
Its strange no one is seeing eye to eye here but, common really, cowboy is just one of the deps of Pheonix. If you need a simple webserver, no extra features other than to reply "hello world" to a POST request, and you compare cowboy/other_barebones vs pheonix for the task, both are equal and do not ship with any extra modules beyond getting the task at hand done "reply to POST req with hello world" plus both equally allow you freedom without forcing you into certain design patterns?
Channels, eex engine could be modularized and pulled in as deps without all of Pheonix.
And I will digress because indeed inappropriate.
mandatory features
@vans163 Every single one of those features you listed are not mandatory, nor is any part of phoenix mandatory. Phoenix is a set of additional optional plugs on top of Plug along with a few other optional things like an optional better template compiler (you can use the built-in elixir one if you want instead, or use something else, or none), and an optional websocket system in the form of channels (which of course you also don't need to use, you could use, for example, raw websocket interfaces from cowboy or any of the others as well). The phoenix template project shows off a lot of the features, but none of them are by any stretch mandatory and you can plug phoenix into an existing pure-plug project via whatever tiny pieces you want. What is with all the mis-information? o.O