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] GitHub - easydatawarehousing/opal-ferro: Ferro is a small Ruby library on top of Opal that enables an object-oriented programming style for creating code that runs in the webbrowser. No more distractions like HTML and searching for DOM elements, just beautiful and simple Ruby code. See the Ferro website for background information and examples.
[2] http://opalrb.com/
*[3] **Ferro - No more Html with Opal-Ferro*
[4] GitHub - easydatawarehousing/ferro: This repo holds the source of the Ferro website. Ferro is demonstration of the abilities and use of the opal-ferro ruby gem.Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>