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"?
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 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.
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.
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.
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 :)
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’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.
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?
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.
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:
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 Emb...
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.
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.
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.
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.
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?
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.
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.
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:
66 comments
[ 4.6 ms ] story [ 48.1 ms ] threadOk :)
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.
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.
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.
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.
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 :)
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.
I don't think it does.
https://chrome.google.com/webstore/detail/quick-javascript-s...
If it's broken, don't expect us to fix it.
---
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 Emb...
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.
Unless the only purpose to this is to just not write javascript.
---
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?
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.
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.
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.
> 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.
Ferro makes the whole process more natural, at least.
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.
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