Re: [Ruby] No more html


(Maria Tikhonova) #1

This sounds great to me, i will surely try. Thank you

···

On Sat, Feb 3, 2018 at 5:38 PM, Ivo Herweijer <info@edwhs.nl> wrote:

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>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>


(Karthikeyan A K) #2

To me this looks amazing. One must be vigilant, there was a framework
called Volt which was kinda more of ruby and great, but it disappeared, I
hope such a fate does not fall upon ferro.

I have just glanced it, I wish more examples and documentation are present
so that people feel more comfortable with it.

···

On Sun, Feb 4, 2018 at 3:59 AM, Maria Tikhonova <ritz.rkraft@gmail.com> wrote:

This sounds great to me, i will surely try. Thank you

On Sat, Feb 3, 2018 at 5:38 PM, Ivo Herweijer <info@edwhs.nl> wrote:

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>
<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>

--
Karthikeyan A K
Author of https://mindaslab.github.io/I-Love-Ruby/


(Phil) #3

A K,

This looks fantastic! - all of my (small) sites are in straight HTML, Jekyll or Rails - but I am definitely going to look at the Ferro gem more closely.

Thanks!

Phil.

···

On 2018-02-04 18:52, Karthikeyan A K wrote:

To me this looks amazing. One must be vigilant, there was a framework
called Volt which was kinda more of ruby and great, but it
disappeared, I hope such a fate does not fall upon ferro.

I have just glanced it, I wish more examples and documentation are
present so that people feel more comfortable with it.

On Sun, Feb 4, 2018 at 3:59 AM, Maria Tikhonova > <ritz.rkraft@gmail.com> wrote:

This sounds great to me, i will surely try. Thank you

On Sat, Feb 3, 2018 at 5:38 PM, Ivo Herweijer <info@edwhs.nl> wrote:

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 [1]
[2] http://opalrb.com/
[3] HTTPS://EASYDATAWAREHOUSING.GITHUB.IO/FERRO/ [2]
[4] https://github.com/easydatawarehousing/ferro [3]

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

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

--

Karthikeyan A K
Author of https://mindaslab.github.io/I-Love-Ruby/

Links:
------
[1] https://github.com/easydatawarehousing/opal-ferro
[2] https://easydatawarehousing.github.io/ferro/
[3] https://github.com/easydatawarehousing/ferro
[4] 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>

--
Philip Rhoades

PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au


(Easy Datawarehouse Solutions) #4

To me this looks amazing. One must be vigilant, there was a framework called
Volt which was kinda more of ruby and great, but it disappeared, I hope such a
fate does not fall upon ferro.

I have just glanced it, I wish more examples and documentation are present so
that people feel more comfortable with it.

>
> This sounds great to me, i will surely try. Thank you

Thanks for all the kind words. Documentation is the next item on my list. The source for the ferro website itself is currently the best example application.

The volt framework was very promising, much to my surprise it was abandoned. I will do my best not to let ferro go the same way by keeping it as small and simple as possible (but no simpler of course) in order to keep maintenance workload low.

tl;dr

This reminds me of a video of a ruby-conf talk by Justin Searls (2014 ?). If I remember correctly he spoke about the open-source maintenance trap that a lot of projects fall into. Especially if software is created for the 'fame and glory', which fades quickly, there is little motivation to keep maintaining a piece of software.

My take on this is that there are several possible reasons to start an open source project:

1. Open sourcing a project used internally by a company (Rails)
2. As part of a freemium model (Sidekiq)
3. You have an 'itch to scratch' (Ferro)
4. As an exercise
5. Something to put on your resume (as an employer I would be more interested in the other projects you worked on)
6. For the fame and glory

First 2 reasons probably means a well maintained long running project. Anything below that and you are in the dangerzone.

Rhetorical questions: out of the 140K gems on rubygems how many are actually maintained and useable? And out off the millions of github repo's, how many are really in the github graveyard?

Cheers,
Ivo

···

From: Karthikeyan A K
Sent: Sunday, February 4, 2018 8:52 AM

> On Sun, Feb 4, 2018 at 3:59 AM, Maria Tikhonova <ritz.rkraft@gmail.com> > > wrote: