After read this and this I wonder if Drab proposal isn’t the best solution for rich interactive web apps.
marciol
kelvinst
I wonder the same… I really try to avoid JS logic for everything I do, and I do not miss it. There is always ways to do everything without the need of JS at all, and sometimes you will even get surprised of how easier, better and faster it becomes!
kelvinst
Right!!? I’m really tired of listening the old argument: “but the screen blinks when I click on a link”. Which is not true if you’re using phoenix to render HTML on the server! Actually quite the opposite, if you refresh your JS-rich SPAs, you’ll see that having lots of JS to be executed is not that shiny!
I know the argument presented is a very dumb, and there’s lots of other arguments to use a client side framework. My point is that we really do not need a lot of JS to do what people are doing with a lot of JS…
And common! Most of these SPAs and reactive frameworks rely on something that is really bad and hard to manage: A HUGE AND HAIRY STATE!!!
I really advocate a lot for server-side rendering and I think drab is going in a interesting direction to solve some problems you might get when you need some richer interface.
Thanks @grych!
marciol
Think with a clear and almost nubie approach, we can observe that whatsapp works exchanging only text, even accross much limited connections, while some web apps simply doesn’t work.
It is really interesting, given that web is text after all, so if you can remotelly control the ui only sending enough and absolutelly necessary javascript to client, I think that it could be a good solution for several problems that needs much more work using SPA tech, even being a very uncommon approach, but it could be explained if you take in account that erlang is not broadely used. This is a kind of secret weapon!
abitdodgy
I ran into a problem while trying to incorporate Drab into a project. I have a bunch of helper functions that I’m using all over the application, so I added them to my app’s foo_web.ex:
def view do
quote do
# ...
use Phoenix.HTML
import FooWeb.Router.Helpers
import FooWeb.ErrorHelpers
import FooWeb.Gettext
import FooWeb.InputHelpers
import FooWeb.HTMLHelpers
import FooWeb.ApplicationHelpers
end
end
It seems that Drab isn’t able to find those functions. While reading the docs I stumbled on the Evaluating Expressions section, which might hold some clues.
If I understood that section correctly, drab doesn’t evaluate any import statements beyond the following:
Import Router.Helpers
Import ErrorHelpers
Import Gettext
I tried changing the config, but it seems that a 3 element tuple is hardcoded into the config function.
Any idea how I can include the rest of my modules? I can get around this by fully qualifying the function names (<%= FooWeb.HTMLHelpers.icon_tag ... %>), but obviously that’s not ideal.
grych
Creator of Drab
grych
Creator of Drab
I’ve changed the config entry for :live_helper_modules, now it gets a list. Will go live with v0.6.2
grych
Creator of Drab
Request for Comment: Shall the handler process survive websocket disconnections?
Hi folks,
I’ve got a brand new idea how to make life easier with Drab, and need your opinion on it.
Nowadays, when you run the handler function in the commander, Drab runs it in the process, which is linked to the channel. It means that in case of network disconnection, closing browser, etc this process is going to die. This is a safe approach - Drab is all about manipulating the UI, so when UI is gone, Drab is gone.
By the other hand, I want Drab to be helpful to run long-running processes which communicates back to the client (as in this example). When the disconnection happens, this process is killed, and you need to restart it from the scratch. Not very handy, isn’t it?
So, what if the process would not be linked with the channel and would not be killed when the channel closes? And would be able to re-bind the new socket to the running handler process, so it could continue updating the page after the reconnection?
In this case you just don’t care about disconnections. You can run the 24-hour long loop on the server, and don’t even care if the UI is still there or not.
Of course you can’t read the browser when it is disconnected, but all reading function could return {:disconnected, _} instead of raising an error, so you could do something with this. For the UI updating functions: we could stack up all the javascripts generated during the disconnection and send them to the browser on re-connect.
For sure it would be some performance downsides, as I need to store this “sessions” somewhere on the server side, wipe it out from time to time (so introduce handler timeouts as well). But IMO it is worth doing it. What do you think?
OvermindDL1
Eh, I’d think it would be best to kill it when the channel closes regardless. If the user wants to do some things out of band then a database or some other dedicated process is better for them to start up.