La zanzara.
1,214 karma · joined December 27, 2012
You'll get dark mode everywhere, automatically, with good looking dark colors.
I think it does that by leveraging color theory and CSS filters.
I think it achieves that by leveraging color theory and CSS filters.
Once you try it you cannot go back :)
I am not involved in development nor devs are friends of mine, I just think it didn't get all the exposure it deserves.
PS if you're on chrome, after installing Darker Reader the infamous chrome white flash problem will mess with your eyes... Following thread has a partial solution to that:
https://easydatawarehousing.github.io/ferro/introduction
Did you get inspired by that?
On the Chromium front, someone forked and fixed it at https://github.com/hbtlabs/chromium-white-flash-fix but Chromium never merged it because, quoting the repository:
---
What is the chromium team doing about this issue?
Issue has been logged multiple times since https://bugs.chromium.org/p/chromium/issues/detail?id=1373 Most recent progress is https://bugs.chromium.org/p/chromium/issues/detail?id=470669
The issue has been broken down since they are attempting an algorithmic fix https://bugs.chromium.org/p/chromium/issues/detail?id=21798
Algorithmic fix: determining what's the background color of the current page or theme page then applying it during rendering instead of choosing white by default.
---
And what about Chrome? From the same repository:
---
Why doesn't the Chrome team merge this?
Because it replaces the white by black and most websites have a white background and most people don't use a dark theme. Hence, the white flash is a non issue for the majority of users. Also, the webkit fix changes the background of chrome:// pages to black
---
I also found multiple StackExchange questions on this with many answers providing obsoleted solutions and others which rely on very inelegant hacks, like using desktop automation software to interact in the browser in a really invasive ways.
https://superuser.com/questions/580228/prevent-white-screen-...
I suspect that after "Dark Reader" there will be so many users getting terribly annoyed by this issue and a solution must be found. So with this post I'd just like to raise some attention on this: if your eyes are being hurt by white flashes too, please upvote this post.. We know many Google employees like to hang out around here. :)
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:
---
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?
Ferro makes the whole process more natural, at least.
---
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)
---
Ok :)
Especially annoying when testing multiple queries to find the optimal one and you decided that a query of 3 submissions ago was the most effective and you couldn't remember it precisely.