What does HackerNews think of drab?

Ash Framework | Sep 2023

All I would say to Zach, other than appreciating his efforts on this, is to not give up, and to be in it for the long haul. The Elixir community needs a different flavour of making webapps other than Phoenix.

It was a bit dishearting to see drab[1] development stop once Phoenix Liveview took over the mindshare.

[1] - https://github.com/grych/drab

EDIT --

Sorry - adding in that drab's author suffered a major health issue - https://github.com/grych/drab/issues/205#issuecomment-795137...

Your Front-End Does Not Have to Be Rich | Mar 2019

Expand Context ↕

I think it makes sense to just stick with what you know, unless you have good reasons not to. But since you asked (and mentioned Elixir), Phoenix live view or https://github.com/grych/drab.

The “Developer Experience” Bait-And-Switch | Sep 2018

Expand Context ↕

The idea in this case is that you'd have a bit of JS that would take care of updating the DOM, binding event handlers (which is specified and taken care of server-side), and so on.

How Phoenix.LiveView would do this exactly is still being worked on, but [Drab](https://github.com/grych/drab) will probably offer some inspiration.

Escaping the SPA rabbit hole with modern Rails | Jul 2018

Expand Context ↕

I generally agree with you, and as a front-ender-first that feels kind of uncomfortable to say. In my personal projects I do often go for a more conservative server-side first approach.

That said, it really feels like a chasm that quite often I choose to cross simply because it'll be easier down the line. I've been bitten more than once by server-side-first projects where going full-on client-side with the server-side as an API would've probably been better.

Whether it was because I needed a mobile app to communicate with said API, or whether the complexity ended up being more of a client-side thing, the result was often that I had to focus on the back-end as as API and go for the full complexity of a front-end app anyways.

I'm enough of a fan of my preferred back-end languages (Ruby, but mostly Elixir these days) that I try to find ways to keep the complexity there, but truthfully I often opt for going for the full complexity of a client-side JS/TS stack because I'm likely to end up needing it eventually anyways.

I've looked into things like Drab (https://github.com/grych/drab), but ultimately there are many reasons why 'going with the flow' seems like the better solution (even if just because it's so much easier to find JS devs than Elixir ones).

So far I'm not confident enough to make any sweeping statements, but from that lack of confidence I tend to opt for the 'safer' option, which seems to be the SPA route much of the time.

Web frameworks are transforming from runtime libraries into optimizing compilers | Sep 2017

Expand Context ↕

Yes. This Elixir library aims to have a virtual DOM on the server and send minimal diffs to the client: https://github.com/grych/drab

It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.

Towards a JavaScript Binary AST | Aug 2017

These are random thought I just wrote on twitter in the morning(UTC+7):

"I kinda think that there were no front-end languages actually. It's kinda all about web platform & browsers can't do things out of the box."

"Graphic interface shouldn't execute program on its own rather than rendering string on _platform_ which won't bother more."

"This is partly why people delegate js rendering to server. At the end of the day all script should be just WebAssembly bytecodes sent down."

"Browser should act as physical rendering object like pure monitor screen. User shouldn't have to inspect photon or write photon generators."

"SPA or PWA is just that about network request reduction, and how much string wanted to send at a time & today http/2 can help that a lot."

"Project like Drab https://github.com/grych/drab 's been doing quite well to move computation back to "server" (opposite to self-service client)"

"WebAssembly compromise (to complement js) to implement the platform. JS api and WebAssembly should be merged or united."

"VirtualDom as if it is a right way should be built-in just like DOM get constructed from html _string_ from server. All JS works must die."

"That's how WebComponent went almost a half way of fulfilling web platform. It is unfortunate js has gone far, tools are actively building on"

"I'd end this now before some thought of individualism-ruining-the-platform take over. That's not gonna be something i'd like to write (now)"

-----

Not a complete version though. Kind of general speaking but I've been thinking in detail a bit. Then hours later I found this thread.

Elixir in Depth – Reading and personal notes | Aug 2017

Expand Context ↕

You can look into drab, an elixir server-side DOM manipulation library: https://github.com/grych/drab. I've never used it, but many people in the Elixir community think it holds a lot of potential.