is there any progress in thinking about drab-polymer? This was jumping to my mind as well whaile reading the posts here. Is not drab + client side web components a good fit?
hwinkel
grych
Creator of Drab
Finally, I am not planning to integrate Drab with any client side library, myself.
The reason for this is I would rather focus on the core Drab. I made Drab modules (like Drab.Live or Drab.Query - for jquery) independent from others, and there is a Drab.DrabModule behaviour, so it is not very complicated to create your own module for polymer, or angular or other. Simply, I will not have time to learn all the client side libraries 
- and there are plenty of people who understand it better than me.
So far I am developing the whole thing myself, but if someone is interested to create Drab module for any client-side library, I will give all the help. There is still no documentation or howto about this topic yet, sorry.
OvermindDL1
Oh I used to use nitrogen back in my old erlang days, it was an awesome server-side-driven web framework. You might indeed get some ideas from it, but I’d not go its whole route of html defined in code.
In the process so in one of my projects, it might be something I can rip out over time. ^.^
In my case it would have to be every single commander in every single controller. What I’m wanting to accomplish is this:
- User goes to my site, some URL, does not matter where, it loads like normal.
- User clicks (most of) a link on my site and instead of navigating to that page it instead fetches the page (via unpoly, not drab, although if drab could do this…) and swaps the main page body (not touching the header/footer).
- On any page load or change, anything decorate with some drab thing, like say
<div drab-commander="BlahCommander"> ... </div>then drab should load up BlahCommander and link it to this element for it to then control (and to control only this element). - When page changes then when such an element vanishes then drab should let it die and unhook it. There might even be multiple elements on the page going to the same commander, each should be unique in their control.
Right now I’m playing with a Drab module idea that enhances a Commander to do something similar. Right now you just use it in a command, then use that same commander from every controller (easy to add to your web’s using for controllers), and it then maps elements to names, so for a given <div drab-commander="blah">...</div> it will use the command :blah, BlahModule so the BlahModule will become the callback module. It has it’s own set of helper functions that basically copy the normal drab ones but constrain to the element that it is bound to.
Sadly is is still in early dev because I’m basically having to rewrite drab to add this functionality it seems, hence why I would love it baked in to it. ^.^;
EDIT: But with the above ability I’d be able to, say, put a notification handler on the header, a chat popup on the footer, various other drab things in the body that get swapped in and out on unpoly changing the pages, and so forth. All a single, unified, server controlled view.
fusillicode
Oh gosh @grych I’m really sorry for the lateness of my reply 
Anyway everything you pointed out were my silly errors and all your suggestions just worked fine without any hassle! 
Thank you really a lot for your quick support and sorry once again for the bother and for the lateness of my feedback.
Cheers! 
grych
Creator of Drab
vfsoraki
Man, this is awesome!
Just about the time I was reading through Vue docs to build a dashboard. This could be way better. I will test it, even build a simple server monitoring dashboard (using simple commands as data source) and put it here to give and receive more feedback.
One thing that came to me while reading docs and this topic, is how much drab is dependent on phoenix?
I mean, if it is decoupled enough, maybe think about a new SPA server-side framework? Maybe named Brad? 
Just thinking though, I just ran the through the example provided in readme.
AstonJ
grych
Creator of Drab
It is completely dependent on Phoenix. And I think it is not worth to build completely new framwork, if we can just extend the existing one (and such great and reliable as Phoenix).
Perhaps that was the problem with project which tried to accomplish the same, like nagare or volt. They tried to build a new framework, which is a lot of work. My job is much easier
AstonJ
I agree - fitting in nicely with Phoenix is a smart move.
Incidentally, I actually think it was Phoenix that ‘killed’ Volt - when Phoenix came on the scene I noticed interest in Volt declined significantly. Volt was trying to offer many of the things Phoenix does and that Phoenix does much more performantly, albeit with the notable omission of the front end side.
vfsoraki
I know phoenix is a great framework, I love it too.
But it it designed as a normal server side framework (api/regular).
Leveraging drab, we can build a framework that can replace any client side framework, at least in elixir world .
The thing that always bothers me about client side frameworks is that you need server side rendering if you want to go for SEO or such. With this, we can eliminate it.
Anyway, you made it clear that you are not planning to add routing support to drab. End of discussion .
Anyway, Is there an issue or todo list somewhere? I can’t seem to find one in repo or docs. Maybe I can help.