Ferro – Simplifying web development, no more HTML

This is more a ruby-to-js compiler than a simplification of web development. You can do the same thing is pure javascript (generate html and css rather than specify it) - which would likely have even less ceremony.

no. stahp. plz.

But why? Why should web pages that don't require javascript require it?

Did you really take "no more JS/HTML" in previous title wording as for "browser not needing to run JS/HTML anymore", rather than for "developer not needing to write JS/HTML anymore"? Even though the title starts with "simplifying web development"?

Ok :)

For a moment I forgot this is homeland of JS-at-any-cost :) so to let this go through a bit more I'll just post excerpts from the linked website:

---

Introduction

Simplifying web-development with Ferro

- An example

Imagine a webpage that displays a form with a checkbox and an input field. The input should only be enabled when the checkbox is checked. This kind of logic is best handled by the webbrowser, not the webserver. So we would write or generate an HTML page with the two inputs and some javascript. The javascript runs when the page is loaded, it runs a (jQuery) selector to find the checkbox and adds an eventlistener to the click event. When the checkbox is clicked the javascript event-handler function is executed. This runs a selector to find the input field and modifies its disabled attribute. Ironically we need some code to look for the elements that we know are there. We just created them in html!

If we look at this example from a functional perspective we only need two things: (1) a form with a checkbox and an input and (2) an action that should run when the checkbox value changes. Wouldn't it be nice if we could translate these functional requirements into some Ruby classes and be done. Well, and this should come as no surprise, we can!

- Opal-Ferro gem

Let me introduce the Opal-Ferro gem. Opal is that wonderful piece of kit that allows us to run Ruby in the webbrowser. Ferro is a small Ruby library that manages the webbrowsers DOM, erradicates the need for searching for elements and introduces some handy naming conventions to simplify CSS design.

But most importantly, using Ferro the webdeveloper only needs to think about the structure of the code, not about all the things that are needed to make the code work in a webbrowser.

- What are the advantages?

Only Ruby and CSS needed

Easy naming conventions: CSS classnames match Ruby classnames

Easy naming conventions: every DOM element has same ID as the corresponding Ruby object. Useful when attaching javascript libraries to elements

Never lookup an element in the DOM. Ferro keeps a handle to each and every element which you can access from Ruby, object oriented style

It is fast, browser javascript engines are highly optimized. The developer can control when to render components, only render what is needed when the application loads

More secure: it is easy to embed scripts into html. As long as you stay away from using the innerHtml method, XSS attacks should be impossible

Easy integration into serverside frameworks like Rails Ruby == Programmer happyness, Javascript === confusion

- What are some disadvantages

Every solution to a problem has its pro's and con's. Ferro is no exception. Here are some of Ferro's disadvantages

SEO results may suffer if the webcrawler only looks at html. Not really an issue when creating a webapp Separate content for screenreaders and javascript disabled browsers is needed

Coding errors may disable (parts of) the webapp. A good set of (integration)tests is useful

Somewhat higher browser memory usage to store the MOM No support for older browsers

- Is Ferro finished?

No, Ferro is not yet feature complete. Most of the basic DOM components are done. Navigation and routing are handled. AJAX calls are wrapped.

Areas that need work are:

Adding a service worker to catch all networktraffic when the browser is offline

Adding support for storing and retrieving data (Object Relational Manager)

A nice ActionCable / websockets client

A markdown parser (that does not produce html but directly adds elements to the DOM)

Localization (I18n)

Many more ready made components, for instance a table component with sorting, filtering, etcetera. Preferably in separate gems

Capture touch events and gestures

Proper documentation and testset

A utility to convert html to ferro code might be useful

- What we don't need when using Ferro

HTML

Javascript DOM finders (like jQuery, Zepto, ...)

Javascript libraries/frameworks that extend html (like Ember, Angular, JSX, Vue, Stimulus)

Shadow DOM Javascript frameworks (like React)

---