Ferro – Simplifying web development, no more HTML | Hacker News Reader

Ferro – Simplifying web development, no more HTML

easydatawarehousing.github.io

24 pointsMrBra60 comments

It literally doesn't load anything without javascript enabled

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

Every day we stray further from hyperlinked documents.

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.

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.

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

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.

I could not agree more.

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

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.

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

You've basically just described "The Birth & Death of JavaScript" https://www.destroyallsoftware.com/talks/the-birth-and-death...

This is not just an abstraction layer for HTML/JS/CSS. This redefines the DOM paradigm and makes it available to the developer (and app) in a much more immediate and meaningful way.

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.

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.

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.

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.

> Never, ever, ever override native scroll experience

I don't think it does.

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

Your comment would have made more sense if you explained why do you actually think this is awful rather than just slipping to the custom scrolling argument. Or is it just because of that?

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.

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.

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.

> 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

Looks pretty simple alright https://i.imgur.com/sn69Wv0.png

Edge 15 is an "old" browser??

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

Why making web development more complicated instead of easier?

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

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.

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.

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

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.

Oh god, why?

https://news.ycombinator.com/item?id=16560016

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.

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

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.

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.

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.

It is not, check my answer to @krapp.

Not writing JS is not the only purpose:

---

Ferro uses an object oriented programming style. You instantiate an object, that object in turn instantiates more child objects and add these as instance variables to itself. And so on, producing a hierarchy of object instances. This is called the Master Object Model (MOM).

When an object is instanciated in the MOM, Ferro will add an element to the webbrowsers Document Object Model (DOM). The MOM keeps a reference to every DOM element. This erradicates the need for element lookups (jquery $ searches). If you need an element you know where to find it in the MOM. Getter methods are automatically added by Ferro for easy access to instance variables.

- Some advantages

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

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

- File size

Total size (Html+JS+CSS+AJAX) for a full application should be similar to a traditional application. All javascript for the linked website, including Opal, minified and gzipped is 89Kb. Compare that to jQuery: 73Kb, Ember: 111Kb, Angular: 111Kb, React: 35Kb.

---

AND YES, writing code in Ruby rather than Javascript is seen as an improvement by many. Or must we necessarily wait for WebAssembly and C# ported to the web before we can enjoy a better programming language without feeling ashamed for avoiding JS?

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.

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.

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.

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

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

ASP.NET Webforms all over again.

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.

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

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

see https://news.ycombinator.com/item?id=16560016

Why would you have JS disabled anyway?

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

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

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

no. stahp. plz.

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)

---

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

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

Judging from the comments, the majority just read the title, interpreted it wrong, and commented accordingly, so yes, I thought it was necessary to avoid misinformation for other people coming here.

Reply on news.ycombinator.com