[prev in list] [next in list] [prev in thread] [next in thread]
List: ruby-talk
Subject: Re: [Ruby] No more html
From: Michal Molhanec <molsoft () centrum ! cz>
Date: 2018-02-13 18:39:11
Message-ID: 05f92c7a-17a4-9173-3d21-e6216acaf923 () centrum ! cz
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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>
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello Ivo,</p>
<p>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!</p>
<p>Regards<br>
Michal<br>
</p>
<br>
<div class="moz-cite-prefix">Dne 03.02.2018 v 16:38 Ivo Herweijer
napsal(a):<br>
</div>
<blockquote type="cite"
cite="mid:2378B25D3AA7478DA477233D0A260704@AMD6">
<div dir="ltr">
<div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR:
#000000">
<div>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.</div>
<div> </div>
<div>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'.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Love to hear what you think about Ferro.</div>
<div> </div>
<div>Cheers,</div>
<div>Ivo</div>
<div> </div>
<div>[1] <a
href="https://github.com/easydatawarehousing/opal-ferro"
moz-do-not-send="true">https://github.com/easydatawarehousing/opal-ferro</a></div>
<div>[2] <a href="http://opalrb.com/" \
moz-do-not-send="true">http://opalrb.com/</a></div> <div><strong>[3] </strong><a
href="https://easydatawarehousing.github.io/ferro/"
moz-do-not-send="true"><strong>https://easydatawarehousing.github.io/ferro/</strong></a></div>
<div>[4] <a
href="https://github.com/easydatawarehousing/ferro"
moz-do-not-send="true">https://github.com/easydatawarehousing/ferro</a></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">
Unsubscribe: <a class="moz-txt-link-rfc2396E" \
href="mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe"><mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe></a>
<a class="moz-txt-link-rfc2396E" \
href="http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk"><http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk></a>
</pre>
</blockquote>
<br>
</body>
</html>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic