51–60 of 67 posts
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.
Unless the only purpose to this is to just not write javascript.
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 webse…
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 webse…
Please don't just copy and paste from the website... it's obnoxious. We see the link, we can read.
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.
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.
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 roo…
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.
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…
Ferro makes the whole process more natural, at least.
Earlier quoted context omitted.
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 to…
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 defi…
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.
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.
---
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?