Re: [Ruby] No more html


(Michal Molhanec) #1

Hello Ivo,

sounds very interesting! I've been playing with the idea of having virtual/shadow DOM in non-webbrowser languages too. It's great to see that somebody already did that and that it works!

Regards
Michal

Dne 03.02.2018 v 16:38 Ivo Herweijer napsal(a):

···

Yes, I know this is a Ruby mailing list and this post is about webdevelopment. But I promise there is a happy Ruby ending to this story.
As webdevelopers we have become accustomed to writing HTML and CSS. And for webapplications that are rich in front-end logic we add lots of Javascript libraries and code. What I have always found annoying about this style of building webapplications is the fact that a lot of steps are involved to add interactivity. We define elements in html and give these elements an id, look up this id from within javascipt and add an event to the element that points to some code that finally does what we want it to do. Most javascript front-end frameworks remove some of this hassle by adding an extended version of html inside javascript. This html is linked to javascript by adding some 'magic markers'.
One might think that we *have* to use html since this is what webbrowsers use internally. But that is not quite true, a webbrowser uses the Document Object Model (DOM) internally which is a memory structure. Using html is one way of specifying what that memory structure should look like. Another way to specify the DOM state is using javascript api's. This is what javascript front-end frameworks tend to do. Some frameworks even keep a shadow DOM where changes in html are written to. The shadow DOM is kept in sync with the webbrowsers DOM.
I have been tinkering with the idea to take this last approach a step further. To skip html altogether and only define the desired structure of an application in code. So let's use Ruby for this and let's call this structure of the application the Ruby Object Model (ROM). Add the needed components of the webapplication to the ROM, a header, an article, a menu, etcetera. And add logic to ROM objects, so when for instance a button is clicked some code is executed belonging to that object. Immediate advantage of this approach is that, apart from specifying CSS rules, we can focus all our attention on one piece of Ruby code.
Now to prove that I'm not just some evil mad scientist and this idea could actually work I have created a gem called Ferro [1]. It can translate the ROM state to the webbrowsers DOM state. It relies on Opal [2] to run in the webbrowser.
There is also a website [3] to demonstrate and explain Ferro's abilities. If you would visit this website and type ctrl+U, you would see there is hardly any html source code present. As you can see in the source code [4] it is a Rails website. All the action happens in the app/assets/javascripts folder.
Love to hear what you think about Ferro.
Cheers,
Ivo
[1] https://github.com/easydatawarehousing/opal-ferro
[2] http://opalrb.com/
*[3] **https://easydatawarehousing.github.io/ferro/*
[4] https://github.com/easydatawarehousing/ferro

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>


(Vijayshree Moyade) #2

Kudos !!!!

···

On Wed, Feb 14, 2018 at 12:09 AM, Michal Molhanec <molsoft@centrum.cz> wrote:

Hello Ivo,

sounds very interesting! I've been playing with the idea of having
virtual/shadow DOM in non-webbrowser languages too. It's great to see that
somebody already did that and that it works!

Regards
Michal

Dne 03.02.2018 v 16:38 Ivo Herweijer napsal(a):

Yes, I know this is a Ruby mailing list and this post is about
webdevelopment. But I promise there is a happy Ruby ending to this story.

As webdevelopers we have become accustomed to writing HTML and CSS. And
for webapplications that are rich in front-end logic we add lots of
Javascript libraries and code. What I have always found annoying about this
style of building webapplications is the fact that a lot of steps are
involved to add interactivity. We define elements in html and give these
elements an id, look up this id from within javascipt and add an event to
the element that points to some code that finally does what we want it to
do. Most javascript front-end frameworks remove some of this hassle by
adding an extended version of html inside javascript. This html is linked
to javascript by adding some 'magic markers'.

One might think that we *have* to use html since this is what webbrowsers
use internally. But that is not quite true, a webbrowser uses the Document
Object Model (DOM) internally which is a memory structure. Using html is
one way of specifying what that memory structure should look like. Another
way to specify the DOM state is using javascript api's. This is what
javascript front-end frameworks tend to do. Some frameworks even keep a
shadow DOM where changes in html are written to. The shadow DOM is kept in
sync with the webbrowsers DOM.

I have been tinkering with the idea to take this last approach a step
further. To skip html altogether and only define the desired structure of
an application in code. So let's use Ruby for this and let's call this
structure of the application the Ruby Object Model (ROM). Add the needed
components of the webapplication to the ROM, a header, an article, a menu,
etcetera. And add logic to ROM objects, so when for instance a button is
clicked some code is executed belonging to that object. Immediate advantage
of this approach is that, apart from specifying CSS rules, we can focus all
our attention on one piece of Ruby code.

Now to prove that I'm not just some evil mad scientist and this idea could
actually work I have created a gem called Ferro [1]. It can translate the
ROM state to the webbrowsers DOM state. It relies on Opal [2] to run in the
webbrowser.

There is also a website [3] to demonstrate and explain Ferro's abilities.
If you would visit this website and type ctrl+U, you would see there is
hardly any html source code present. As you can see in the source code [4]
it is a Rails website. All the action happens in the app/assets/javascripts
folder.

Love to hear what you think about Ferro.

Cheers,
Ivo

[1] https://github.com/easydatawarehousing/opal-ferro
[2] http://opalrb.com/
*[3] **https://easydatawarehousing.github.io/ferro/*
<https://easydatawarehousing.github.io/ferro/>
[4] https://github.com/easydatawarehousing/ferro

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe> <ruby-talk-request@ruby-lang.org?subject=unsubscribe><http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

--
Thanks & Regards
Vijayshri Moyade

--
*
***Disclaimer**
*This email communication (including any attachments)
contains information which is confidential and may be legally privileged.
It is for the exclusive use of the intended recipient/s. If you are not the
intended recipient, please delete this email communication (including any
attachments) and hard copies immediately, please preserve its
confidentiality and notify the sender. Any unauthorized use or
dissemination of this email communication (including any attachments) in
any manner whatsoever, in whole or in part, is strictly prohibited. This
email communication (including any attachments), may not be free of
viruses, you should carry out your own virus checks before opening any
attachment to this e-mail. The sender of this e-mail and Cuelogic
Technologies shall not be liable for any damage that you may sustain as a
result of viruses, in completeness of this message, a delay in receipt of
this message. Any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of Cuelogic
Technologies. Cuelogic Technologies will not accept any liability in
respect of such content of this email, and the author shall be solely
responsible and will be personally liable for any damages or other
liability.*