Maybe I’m misunderstanding you, but are you using a VDOM both on the server and the client? Why not sending state through the network and allow the client to resolve the state into the UI using a VDOM?
This is the approach I intend to take: run VueJS on the client and sent state. The Elixir code doesn’t deal with the DOM at all.
My experiment was trying to remove as much JS from the client as possible, and just like Drab, try to send the entire view from the server to the client. So Bard is actually creating a stream of vdom AST that is sent to the server (the complete view at first and updates as they are produced over time), but since the View is just a function of the State, we could very easily send any portion of the state itself instead of the vdom produced by it.
Actually I have been thinking about something like what you mention for a few weeks but again havent had time to actually refactor Bard for it. This change would let you send as much as it makes sense for you from the server, and write as much JS on the client as you want. For example, you could send the complete vdom AST for react just to render (my original plan) or just send the props and use normal React components on the client, or send any bits of state for clients that can handle Observable streams, say polymer/angular/vue and let those libs mess with DOM updates.
(this might be veering a little offtopic, but I’ll answer here anyway, because it’s related to Drab, and might provide some ideas for someone who wants to write a Drab client that interfaces with different Javascript libraries)
Ok, my experiment is the philosophical opposite of yours: trying to remove as much DOM from the server as possible 
Javascript is already very good at manipulating the DOM. This means something like React handles the DOM on the client and the server sends props.
Actually I’m using VueJS instead of React because:
Until the Weex project is more well developed, VueJS is a big No for your use case, which require React Native, but if you’re developing for the web, it’s quite attractive.
This approach of sending pure values over the network might be useful too if you want to be renderer-agnostic. I could have a Qt-based client, for example (I have an unpublished React-like library for PyQt that would make a pretty good fit with this approach).
EDIT: I don’t think of these experiments as competitors in the capitalistic sense of trying to fight over user mindshare. I think that there is space for all these approaches, and they all can feed on each other for ideas or implementation details.
Changing extension from .html.eex to .html.drab breaks some stylings
by automatically adding wrapper to each elements
Is there anyway to avoid this problem?
<ul class="tab tab-block">
<span drab-ampere="gi3dqnrrg4yti">
<li drab-ampere="he4tmmztha4ds" id="hero_slide_tab_0" class="tab-item active active-tab">
<a drab-ampere="giztiobrgq4q" onclick="onSelectHeroSlide(0)" style="cursor: pointer;">슬라이드-0</a>
</li>
...
</span>
</ul>
I think it should be safe regardless, you may want to put user input into the html you are sending, and remembering to escape their input will be forgotten. At least with it being safe by default you will immediately see it escaped and thus can then just put ~E in front of it or so. ^.^
The wrapper is gone in the version 6 and above.
Anybody knows how to deal with special charactors?
Using special characters in form, and input causes error.
for example,
(1) % causes invalid www-form error (encoded form of ascii like %25 is okay)
(2) & makes my input params to be divided.
and because of (2), when handling wyswig editor’s innerHTML to be escaped also causes problems.
my form is like below
<form>
<div class="form-group">
<label for="accordion_body" class="form-label">body</label>
<textarea id="accordion_body" name="accordion_body"><%= @accordion.body %></textarea>
</div>
<input id="widget_name_of_accordions" name="widget_name" value="accordion" class="hidden"/>
<button class="btn btn-primary hidden" drab-click="save_accordion">Save</button>
</form>
if i type input like this.
accordion_body: Default Text will be like< ;THIS> ;
and i inspect sender params,
%{"accordion_body" => "Default Text will be like",
"lt;THIS" => nil, "gt;" => nil,
"widget_name" => "accordion"}
Using multiple drab partials in one template is not binding assigns properly.
How can I handle this?
[error] Process pid<0.3488.0> raised an exception
** (ArgumentError) Assign @services not found in Drab EEx template
Please make sure all proper assigns have been set. If this
is a child template, ensure assigns are given explicitly by
the parent template as they are not automatically forwarded.
Available assigns:
[:hero_slides, :page]
I ensured to put :hero_slides and :sections to assigns.
When I change the order of each partials, then I got
Available assigns:
[:services, :page]
some of my codes are like below.
# edit.html.eex
<%= for widget <- @page.widgets do %>
<%= if "hero_slides" == widget do %>
<%= render "hero-slides-edit.html", assigns %>
</div>
<% end %>
<%= if "sections" == widget do %>
<%= render "sections-edit.html", assigns %>
</div>
<% end %>
<% end %>
and
# hero_slides.html.drab
<form id="hero_slides_edit">
<%= for {hero_slide, idx} <- Enum.with_index(@hero_slides) do %>
...
<% end %>
<button class="btn btn-primary" drab-click="save_all_in_widget">Save</button>
</form>
and
# sections.html.drab
<form id="sections_edit">
<%= for {section, idx} <- Enum.with_index(@sections) do %>
...
<% end %>
<button class="btn btn-primary" drab-click="save_all_in_widget">Save</button>
</form>