
Ferro – Simplifying web development, no more HTML - MrBra
https://easydatawarehousing.github.io/ferro/introduction/
======
jamestomasino
It literally doesn't load anything without javascript enabled

~~~
vim_wannabe
Every day we stray further from hyperlinked documents.

~~~
Pxtl
Good. An application platform shouldn't pretend to be a hyperlinked document
platform. Embrace the reality of the modern web instead of torturing us with
the backwards perverted abstraction.

~~~
vertex-four
Or perhaps you can build a decent application platform instead of torturing a
very useful hyperlinked document platform into doing something it wasn’t built
for.

~~~
Pxtl
It's about 20 years too late for that conversation.

~~~
vertex-four
It’s really not. The only thing going for the web as an application platform
is decent sandboxing and the fact that web browsers are installed on most
computers by default - it’s not actually good, hence the proliferation of
native apps on mobile. So perhaps it’s worth thinking about how to put a
better system for distributing applications into people’s hands, rather than
continuing as a society to waste effort on torturing web technologies into
doing it.

~~~
L0stLink
I could not agree more.

------
kowdermeister
> no more HTML/JS/CSS

But it's there, just an abstraction (or many) away. If you don't get HTML/CSS
then no framework will help you that generates it. You can avoid JS, but
understanding the DOM and CSS best practices is essential. Once you get it,
you don't need libraries like this.

~~~
nine_k
Theoretically you could write WebAssembly code that generates e.g. a bitmap,
or an SVG, and have a minimal, unchanging HTML+JS "bootloader" for it.

Using browser's caching, you can save bandwidth and keep that WebAssembly code
from being re-downloaded. Then you can feed it URLs serving your own content
in your own compact, logical and otherwise awesome format, and have it
rendered.

By that moment you will have reinvented something like Flash, only completely
static.

~~~
kowdermeister
> Theoretically you could write WebAssembly code that generates e.g. a bitmap,
> or an SVG, and have a minimal, unchanging HTML+JS "bootloader" for it...

I was expecting something like that from the OP title. I don't doubt however
that this technology will come, it's a question of when. I hope they will
support text selection :)

------
nodelessness
It is possible to define an android application without defining a single XML
file. There's a reason Android provides XML based definition for layout
definition. The alternative is VERY tedious and bloats the code. Which is what
this seems to be going towards.

This has the added disadvantage of not making it clear in one place what the
structure of things is. You have to hold it in your head or on paper what the
defined structure is.

~~~
MrBra
Flipping your comment upside down: then we just need a layout design tool on
top of Ferro and we'll get a Ruby equivalent to VS or Android Studio for the
web.

~~~
L0stLink
Do you remember swing and awt on Java? because that is what you are moving
towards. This will not simplify web development, it will just produce code
that is not maintainable for a project with any significant level of
complexity.

------
matthewmacleod
It’s great to play around with madcap ideas like this! That’s how we move
towards better technology, and that path isn’t always obvious.

That said, this is awful. Never, ever, ever override native scroll experience
unless you’re building something that isn’t a page - and even then think
thrice about it.

~~~
madeofpalk
> _Never, ever, ever override native scroll experience_

I don't think it does.

~~~
bdcravens
Yeah, looks to just be an <article> tag with overflow:auto set

------
ricardobeat
Hard to get past the wall of misinformation:

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

jQuery and Zepto are not “DOM finders”, they are cross-browser compatibility
layers (that include querySelector).

“Frameworks that extend HTML” definitely encompasses Ferro itself.

React uses a virtual DOM. “Shadow DOM” is unrelated and part of the web
components proposal.

~~~
MrBra
Whatever they are, they suck. Actually what sucks is not them specifically,
but the reason because they exist.

Ferro makes the whole process more natural, at least.

~~~
ricardobeat
It’s easy (and meaningless) to criticise while not fully understanding what
they do.

From an architecture standpoint, this is very similar to building a tree of
Backbone views + a few abstractions. Writing OO code instead of a markup
language (JSX/HTML) has few intrinsic benefits besides “feels familiar to me”.
And it goes head on against the resurgence of functional programming, reactive
UI and declarative code. You need much more than “they suck” if you want to
profess that your system is better.

Not to say this isn’t worth exploring, but the bold and dismissive claims
detract a lot from the project’s idea.

~~~
MrBra
> if you want to profess that your system is better.

Not sure if you thought I am the project creator or if you were just generally
speaking. Anyway, if you wanted to know more about the rationale behind this
project, you could address author's comment here:

[https://news.ycombinator.com/item?id=16571142](https://news.ycombinator.com/item?id=16571142)

------
roryisok
Looks pretty simple alright
[https://i.imgur.com/sn69Wv0.png](https://i.imgur.com/sn69Wv0.png)

~~~
teleclimber
Edge 15 is an "old" browser??

~~~
roryisok
I think they're probably reading user agent strings. Otherwise it's incredibly
specific

------
kome
Why making web development more complicated instead of easier?

------
feelin_googley
For those users who choose to disable Javascript or choose browsers that have
no Javascript engine:

    
    
        curl https://easydatawarehousing.github.io/ferro/main_content.json \
        |exec sed '/{\"/{s/{\"/<pre>\
        \
        &/g;s/,\"/\
        &/g;s/\content\":\"/&\
        \
        <\/pre>/g;};s/\"}/&\
        \
        /g;s/\\u0026/\&/g'|exec unvis -h > 1.htm
        
        exec firefox file:///1.htm

------
easydwh
I am the author of the _Opal-Ferro library_ and the _website_ this thread
links to. Thanks for all your comments.

Please note that the website is a technical demo of the ferro library and
gives some background information about how it works. The intended target
audience of the website are web- and software developers. I didn't invest a
lot of time in browser compatibility since web developers tend to use newer
browsers. Edge 15 is excluded because it doesn't fully support CSS grid. I'm
not a very good web designer nor a CSS expert, so the website is a little bit
rough around the edges. Please don't shoot the messenger/website.

Ruby's is all about programmer happiness. My intention with ferro is to
increase web-developer happiness. What makes me as a web developer unhappy is
front-end frameworks (regardless of the language they are written in). Using a
front-end framework usually involves a mix of some server-side rendered html,
a bunch of code and a templating language. The templating language looks like
html but with extra syntax added to connect with the js code. In other words
to be able to move application logic from the server to the web browser an
even more complex version of html is used. And I need to write in 3 different
languages. Very unhappy.

Ferro tries to solve this problem in a different way. By getting rid of html
(and thus any links between html and code) and replacing this with code to
create a memory structure that fits the application you want to build. The
ferro library handles the creation of the necessary DOM elements. The web
developer only needs to write in 1 language (apart from CSS). I think that
this makes front-end web development much simpler. And me a lot happier.

Some folks mentioned that html is used for tasks it wasn't intended for. I
agree, html was originally created as a markup language with some meta data
added. Kind of what we use markdown for these days. All sorts of things were
bolted on later: styling cues, document structure, semantical elements, js
code. It works but it makes separation of responsibilities
(structure/content/styling/logic) harder. Internally a web browser doesn't
even use html, but only keeps a memory structure we all know as the DOM. Html
is one way of telling the web browser what the DOM should look like. For
simple web pages that is absolutely fine. For (progressive) web apps html is
not ideal.

------
jokoon
Well time should better be spent working on another document language.

I'm curious what the alternative to HTML/CSS would be. If such a new language
could be made more readable for humans, just like json and yaml are more
readable than XML. Maybe even some stylized markdown or textile might offer a
partial solution.

I guess this would not incur such a big cost, since HTTP is still fine. I mean
the elephant in the room is that HTML was never designed for web applications
in mind, yet you cannot deny that smartphone browsers have a hard time dealing
with html web apps, for the simple reason that it's a nightmare to build and
run, which is why android apps have to be made.

I guess what I'm saying makes sense, I'm not sure if I'm throwing a pave in
the pond... But those things are the reasons I prefer working with languages
like C++ instead of HTML.

~~~
wwweston
> just like json and yaml are more readable than XML

Not sure this is true for every case. JSON and YAML often shine for cases
where data is primarily lists of key-value pairs (with some of the values also
being kvps).

If I'm dealing with a larger potential space that needs to allow for data
that's mixed-media long-valued and arbitrarily structured, my experience is
that markup often reads better.

------
desireco42
It is cool to see someone experimenting with Opal, since Volt framework which
was pretty cool, there were no attempts, that I know of, of using Opal well.

I think at this point, it is not quite clear where the whole thing will go and
benefits would be more obvious later when there is more development.

------
collegeman
Oh god, why?

~~~
MrBra
[https://news.ycombinator.com/item?id=16560016](https://news.ycombinator.com/item?id=16560016)

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

~~~
MrBra
It's not just a ruby to js transpiler. Opal is that.

------
MrBra
For those who have difficulties getting it: it's not about the browser not
running JS, it's about the developer not needing to write JS and not needing
to use libraries for managing the DOM. And more.

~~~
krapp
I don't see how writing Ruby and managing a Ruby abstraction of the DOM is an
improvement over writing JS and managing the DOM with that.

Unless the only purpose to this is to just not write javascript.

~~~
detuur
It is. Its elevator pitch is literally "write your website in Ruby". I think
it's very silly, especially considering that WebAssembly has just matured, and
it's been coming for a looong time. Not to mention it's 10x better supported.
If your website only runs on 90% of browsers out there, it's a terrible
website. And this thing as far as I can tell only runs on last-gen Firefox and
Chrome.

~~~
MrBra
It is not, check my answer to @krapp.

------
rmason
I've never been totally comfortable with CSS, even if it's been all I've used
for years. Something about thinking in tables and having to translate.

I've just begun learning CSS Grid and found it a vast improvement. It's so
great to not have to translate anymore. The two negatives are no support in IE
and it gets complicated once you get beyond simple forms though a fix is
promised.

------
supermdguy
Interesting concept, but the problem it intends to solve has already been
solved by JavaScript frameworks. Instead of having to define DOM elements
twice, in HTML and in JavaScript, Vue, Angular, React, etc. all automatically
map data to DOM within the template.

Also, I have concerns about the high level of abstraction -- it's not normally
a good thing, and I don't think it's justified in this situation.

------
fuzzy2
Viewing this on an iPad, I can see it doesn't have native scrolling. That's
not exactly good for UX. One should leverage native functionality instead of
working around it to achieve a controlled environment or whatever.

------
tomcooks
Simplifying HTML by writing Ruby, and doesn't work in older browser?

------
velomash
Says the website which has double scroll bars when the viewport is too short
vertically? This is definitely under-baked.

------
phaed
ASP.NET Webforms all over again.

~~~
Pxtl
Webforms was crap because it was all server-side and the component design API
was nightmarish, as was the client-side API.

The idea of a truly-component-oriented system for the web that abstracts away
the endless pain of modern html/css/js isn't a bad one.

------
appdrag
Or how to produce a website that no one (or nearly) will be able to maintain
:)

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

~~~
benbristow
Why would you have JS disabled anyway?

~~~
teleclimber
I disable JS more and more often because of all the crap popups and email
signup forms etc... I use this extension which makes it easy to toggle on a
per-site basis:

[https://chrome.google.com/webstore/detail/quick-
javascript-s...](https://chrome.google.com/webstore/detail/quick-javascript-
switcher/geddoclleiomckbhadiaipdggiiccfje)

~~~
benbristow
You just make it harder for web developers to provide nice experiences.

If it's broken, don't expect us to fix it.

------
xtracerx
no. stahp. plz.

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

\---

~~~
krapp
Please don't just copy and paste from the website... it's obnoxious. We see
the link, we can read.

~~~
adamzochowski
Not everyone can read the link. Many people are just presented with a
disclaimer : " No attempts have been made to support older webbrowsers like
Internet explorer and Edge 15. I recommend: Firefox ".

