8 ms·

Ferro – Simplifying web development, no more HTML

24 points by MrBra 9y ago

jamestomasino 9y ago
It literally doesn't load anything without javascript enabled
- deleted 9y ago
  [deleted]
- MrBra 9y ago
  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 :)
- vim_wannabe 9y ago
  Every day we stray further from hyperlinked documents.
  - Pxtl 9y ago
    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 9y ago
      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 9y ago
        It's about 20 years too late for that conversation.
        vertex-four 9y ago
        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 9y ago
        I could not agree more.
deleted 9y ago
[deleted]
desireco42 9y ago
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.
nodelessness 9y ago
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 9y ago
  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 9y ago
    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.
collegeman 9y ago
Oh god, why?
- MrBra 9y ago
  https://news.ycombinator.com/item?id=16560016 https://news.ycombinator.com/item?id=16560016
kowdermeister 9y ago
> 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 9y ago
  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 9y ago
    > 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 :)
  - madeofpalk 9y ago
    You've basically just described "The Birth & Death of JavaScript" https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- MrBra 9y ago
  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.
matthewmacleod 9y ago
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 9y ago
  > Never, ever, ever override native scroll experience I don't think it does.
  - bdcravens 9y ago
    Yeah, looks to just be an <article> tag with overflow:auto set
- MrBra 9y ago
  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?
kome 9y ago
Why making web development more complicated instead of easier?
thinkloop 9y ago
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 9y ago
  It's not just a ruby to js transpiler. Opal is that.
xtracerx 9y ago
no. stahp. plz.
Retroity 9y ago
But why? Why should web pages that don't require javascript require it?
- deleted 9y ago
  [deleted]
- MrBra 9y ago
  see https://news.ycombinator.com/item?id=16560016 https://news.ycombinator.com/item?id=16560016
- benbristow 9y ago
  Why would you have JS disabled anyway?
  - teleclimber 9y ago
    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-switcher/geddoclleiomckbhadiaipdggiiccfje https://chrome.google.com/webstore/detail/quick-javascript-s...
    - benbristow 9y ago
      You just make it harder for web developers to provide nice experiences. If it's broken, don't expect us to fix it.
roryisok 9y ago
Looks pretty simple alright https://i.imgur.com/sn69Wv0.png https://i.imgur.com/sn69Wv0.png
- teleclimber 9y ago
  Edge 15 is an "old" browser??
  - roryisok 9y ago
    I think they're probably reading user agent strings. Otherwise it's incredibly specific
MrBra 9y ago
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) ---
tomcooks 9y ago
Simplifying HTML by writing Ruby, and doesn't work in older browser?
rmason 9y ago
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.
velomash 9y ago
Says the website which has double scroll bars when the viewport is too short vertically? This is definitely under-baked.
appdrag 9y ago
Or how to produce a website that no one (or nearly) will be able to maintain :)
deleted 9y ago
[deleted]
feelin_googley 9y ago
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
deleted 9y ago
[deleted]
MrBra 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      It is not, check my answer to @krapp.
  - MrBra 9y ago
    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?
phaed 9y ago
ASP.NET Webforms all over again.
- Pxtl 9y ago
  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.
jokoon 9y ago
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 9y ago
  > 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.
fuzzy2 9y ago
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.
ricardobeat 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      > 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
supermdguy 9y ago
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.
easydwh 9y ago
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.

24 points by MrBra 9y ago

jamestomasino 9y ago

It literally doesn't load anything without javascript enabled

deleted 9y ago
[deleted]
MrBra 9y ago
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 :)
vim_wannabe 9y ago
Every day we stray further from hyperlinked documents.
- Pxtl 9y ago
  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 9y ago
    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 9y ago
      It's about 20 years too late for that conversation.
      - vertex-four 9y ago
        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 9y ago
        I could not agree more.

deleted 9y ago

[deleted]

desireco42 9y ago

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.

nodelessness 9y ago

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 9y ago
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 9y ago
  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.

collegeman 9y ago

Oh god, why?

MrBra 9y ago
https://news.ycombinator.com/item?id=16560016 https://news.ycombinator.com/item?id=16560016

kowdermeister 9y ago

> 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 9y ago
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 9y ago
  > 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 :)
- madeofpalk 9y ago
  You've basically just described "The Birth & Death of JavaScript" https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
MrBra 9y ago
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.

matthewmacleod 9y ago

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 9y ago
> Never, ever, ever override native scroll experience I don't think it does.
- bdcravens 9y ago
  Yeah, looks to just be an <article> tag with overflow:auto set
MrBra 9y ago
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?

kome 9y ago

Why making web development more complicated instead of easier?

thinkloop 9y ago

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 9y ago
It's not just a ruby to js transpiler. Opal is that.

xtracerx 9y ago

no. stahp. plz.

Retroity 9y ago

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

deleted 9y ago
[deleted]
MrBra 9y ago
see https://news.ycombinator.com/item?id=16560016 https://news.ycombinator.com/item?id=16560016
benbristow 9y ago
Why would you have JS disabled anyway?
- teleclimber 9y ago
  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-switcher/geddoclleiomckbhadiaipdggiiccfje https://chrome.google.com/webstore/detail/quick-javascript-s...
  - benbristow 9y ago
    You just make it harder for web developers to provide nice experiences. If it's broken, don't expect us to fix it.

roryisok 9y ago

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

teleclimber 9y ago
Edge 15 is an "old" browser??
- roryisok 9y ago
  I think they're probably reading user agent strings. Otherwise it's incredibly specific

MrBra 9y ago

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

tomcooks 9y ago

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

rmason 9y ago

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.

velomash 9y ago

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

appdrag 9y ago

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

deleted 9y ago

[deleted]

feelin_googley 9y ago

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

deleted 9y ago

[deleted]

MrBra 9y ago

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 9y ago
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 9y ago
  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 9y ago
    It is not, check my answer to @krapp.
- MrBra 9y ago
  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?

phaed 9y ago

ASP.NET Webforms all over again.

Pxtl 9y ago
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.

jokoon 9y ago

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 9y ago
> 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.

fuzzy2 9y ago

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.

ricardobeat 9y ago

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 9y ago
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 9y ago
  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 9y ago
    > 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

supermdguy 9y ago

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.

easydwh 9y ago

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.