Category: Web Application Techologies
Epic discussion: VS Code Uses 13% CPU When Idle Due to Blinking Cursor Rendering
VS Code Uses 13% CPU When Idle Due to Blinking Cursor Rendering
Discussions: Reddit and Hacker News
Couple of citations:
Assuming 1 million users of VS Code This blinking cursor will waste $3 million per year in electricity costs, and output 32,000 tons of c02 per year.
2150: “Grandpa, why did the ocean’s dry up?”
“well sonny, long ago, Microsoft didn’t optimize their code for a code editor’s cursor and pushed earth’s climate over the edge”
TL;DR:
All this is about Microsoft Visual Code editor that is Electron application — Chromium based.
They blink cursor by this CSS declaration:
@keyframes monaco-cursor-blink {
50% {
opacity: 0;
}
100% {
opacity: 1;
}
}
.cursor-blink {
animation: monaco-cursor-blink 1s step-start 0s infinite;
}
Problems with this solution:
- In chromium / webkit this animation runs with animation frame rate — each 16ms — 60 FPS.
- As Chromium (WebKit with Skia backend) uses mostly CPU rasterization than simple task of filling 1px rectangle eats CPU (and so drains batteries). On each frame rate whole window gets updated.
In principle all this can be solved by something simple as:
setTimer(function() { caret.toggleClass("visible") }, 1000);
“Expert’s pyramid”
Does front end developer need to know anything except of __HIS_FAVORITE_FRAMEWORK_HERE__ ?
From Dmitri’s Pavlutin “The path of software development craftsmanship”
Scalable Web Aplications
Nicholas Zakas is talking about basic principles of scalable [Web] application architectures:
While this talk was made in 2013 it is still 100% applicable to modern Web and Sciter (desktop) applications.
Web Frameworks: React vs Vue
Practical investigation on effectiveness of Virtual DOM (React) updates versus direct DOM updates (Vue).
Clearly React takes significantly more CPU time for the task of updating 100 items list.
That proves once again that there is no silver bullet in Web Front End design. Each task has its own optimal framework/architecture.
“Ideal framework” should allow to use multiple paradigms – list-of-items view should use virtual list, it could be one-way bound with data [model] and item-details may or may not be data bound – depends on its structure.
What if just start from our old friend jQuery with its system of plugins and/or components/modules architecture of Twitter’s Flight.
Where you can add view routing, data bound lists and other plugins of your choice? Only when and where they are needed …
Is it close to that optimal, flexible and stable architecture web applications we are dreaming of?
Maintainable CSS
I have found Maintainable CSS site exceptionally useful for designing maintainable CSS systems.
Modular and encapsulated: Styles don’t bleed or cascade without your permission.
Any design requirements: Completely flexible to your needs.
No tooling required: But you can use tooling if you want to.
Easy to learn: Read the guides and see.
Any size project: Whatever size project you have, MaintainableCSS will help.
Upgrade in your own time: You can start applying the approach today, bit by bit. You don’t need to upgrade the whole
Russian Roulette game, .JS style.
Disclaimer: the game is quite dangerous and may lead to alcoholism of participants even after first game. Play responsibly!
Idea of the game:
Players, in their turn, name random English word. To this word they add “JS” or “.JS” suffix and go google for it.
If google will give JS library or framework with that name – you won and drink one Vodka shot.
You’ll be surprised… and read disclaimer above.
Studies show that a TODO list is the most complex JavaScript app you can build before a newer, better framework is invented.
::mark(…) feature is comming
Please consider these tasks:
- Find all words in text on HTML page and highlight them
- Syntax highlighting: parse text of <pre> and mark all keywords by changing their color
- Find all misspelled words in <textarea> highlight them specifically.
Currently you can do #1 and #2 by wrapping each text found into <span>s with specific classes – thus to modify DOM structure of the document. Such modification by itself is a) not trivial to implement, b) is highly non-desirable (consider text editor with syntax highlighting) and c) even impossible in case of <textarea> for example.
Ideally we should have some facility that will allow us to a) mark text fragments, b) apply styling to such marked runs through CSS and c) do that without DOM tree modifications.
As a result upcoming Sciter will have:
- In CSS, support of
::mark(...name[s]...)pseudo element. - In script runtime, new methods of Selection class:
Selection.applyMark(start,end, ... mark names...);– to add marks to the range.Selection.clearMark(start,end, ... mark names...);– to clear marks from the range.
Example, CSS:
div::mark(hilite) { background-color:lime; }
div::mark(hilite2) { background-color:cyan; }
div::mark(literal,string) { font-style:italic; color: red; }
First rule will tell the engine to set background color on all text runs that are marked by “hilite” to “lime”.
And script code
var text = $(div).firstNode;
var start = [bookmark: text, 6, false];
var end = [bookmark: text, 11, false];
Selection.applyMark(start,end,"hilite");
will apply mark “hilite” to the text node from 6th until 11th position and so you will have the following rendering:
Note: this will not change DOM structure but rather apply some meta information to characters in the text.
display:none is considered harmful
Quite often in HTML/CSS based UIs we need to hide/show some elements in runtime.
Probably the most widespread (and the worst) solution is to set display:none CSS property programmatically.
That sounds quite easy at the first glance but solves only half of the problem – it hides – removes the element from rendering tree. But what you would do when you need to show element that was previously hidden that way? Setting it to display:block is very wrong. Far not all elements have display:block model by default in HTML. <img>, <input>, <select>, <textarea>, etc are display:inline-block. <table> and all its children have special display:table**** values. Setting them to display:block will lead you to quite surprising results.
Therefore in order to use display:none in runtime you will need to know original display value of the element. Not quite convenient and maintainable. Imagine that your web designer (probably sitting on other continent) decided to replace some elements horizontally by declaring display: table-cell on them. You will get problems hiding/showing such elements by switching display: none <-> block.
To overcome such a problem jQuery for example implements its hide() method by storing existing display value to special property named "olddisplay". And restores the display from that property when you need to show the element. That approach is far from ideal either for obvious reasons.
Better solution
Better solution is to use attribute "hidden". So instead of setting element.style.display CSS property you will need to add attribute "hidden" to the element when you need to hide it and remove that attribute when you will want to show the element. In order this to work you will need to add single and simple rule to your stylesheet:
[hidden] { display:none !important; }
If some elements need to be hidden by default you will use hidden attribute in your markup, for example as:
<button id="ok-button" hidden>OK</button>
In Sciter you can define some virtual property, e.g. "shown", to all DOM elements (in some common "utilities" module):
/* CSS must have [hidden] { display:none } rule in order this to work */
property Element.shown(v)
{
get return this.style#display != "none";
set this.attributes["hidden"] = v ? undefined : true;
}
and use it as
var someEl = ...
someEl.shown = true; // to show
someEl.shown = false; // to hide
The solution is not free from obvious drawbacks though:
- you need that special
[hidden] { display:none; }rule to be present in your CSS and - In all cases when you need to hide/show the element you should do it either through that special "shown" property or explicitly by removing "hidden" attribute from the element.
visibility:none
Since Sciter version 3.1.0.15 you can use visibility:none; in CSS to exclude the element from rendering. Exactly in the same way as display:none;. It has exactly the same effect.
As the visibility property is orthogonal to the dsiplay you can safely assign "none" and "visible" property to it without affecting display model of the element.
Therefore, the visibility property in Sciter can accept following values:
- none – the element is excluded from rendering tree in the same way as display:none, that is Sciter specific;
- hidden – the element is in rendering tree, takes space but not rendered;
- collapse – the element is in rendering tree, takes space but its height or width is collapsed to zero. E.g. in flow:horizontal container visibility:collapse child will take space vertically but rendering width will be set to zero. In Sciter this will work for any elements but in standard CSS only for table rows for some unknown to me reason.
- visible – default value, element is rendered normally.
And here is modified version of the shown scripting property defined above:
property Element.shown(v)
{
get return this.isVisible;
set this.style#visibility = v ? "visible" : "none";
}
10 years road to Sciter
Last year it was a jubilee of my BlockNote editor – it is 10 years old now. Quite a serious age for software product I think.
BlockNote, in particular its HTML WYSIWYG editing engine, was the very first version of H-SMILE core that works now inside the Sciter. H-SMILE core was used in other software products, for example in EverNote. In fact I was one of four developers who implemented excellent idea of Stepan Pachikov (EverNote idea-monger and founder) and created first public versions of EverNote.
In parallel and after that I was designing various UIs and editing components. WordProcessor engine that I’ve created for Top Producer Systems (The move.com company). That WordProcessor still works in their flagship product AFAIK. Current stack of Web technologies still does not provide facilities for page oriented WYSIWYG editing so there is nothing to replace WordProcessor yet. I’ve got quite interesting experience implementing text layout and editing algorithms there. Ideas from there have found their way in Sciter code in one way or another.
At some point I’ve got an impression that C++ is not the best language for UI programming. In particular GC as a memory management mechanism is significantly better suitable for typical UI tasks – many small objects with quite non-trivial ownership graphs. I’ve started looking on Java but having dependency on installed Java VM didn’t look right at the moment. So I’ve created so called j-SMILE JavaVM (based on SuperWaba) that was tailored specifically for UI purposes – designed to be combined into executable of the applications together with bytecodes it is running. J-SMILE demo (buggy but works somehow) and sources of class files are available here.
In J-SMILE I started experimenting with HTML as a UI layout manager and sinking/bubbling event propagation mechanism used in Web browsers. These mechanisms were proven to be highly useful for desktop UI purposes too.
Pretty much at the same time with my J-SMILE development Sun-Microsoft “Java Wars” had begun. And this immediately put the end to my J-SMILE development. I realized that I have no chances on this front and started looking for other options.
Some time later D-language raised in the sky and gave me real hope for the best ever language-behind-UI. GCable, natively compileable so fast and with pretty sufficient functional features. So I’ve started porting J-SMILE to it under the name Harmonia framework.
For those who are interested to see Harmonia in action: Harmonia demo, Harmonia sources and class tree.
D is really very cool and convenient language but after some time I’ve decided to stop Harmonia development for the following reasons:
- It was time when D-language was changing very frequently. Pretty much each nightly build was changing core grammar. So Harmonia development was similar to shooting a moving target. Far from being normal development process.
- Having each and every object manageable (garbage collectible) is far from being optimal. HTML DOM tree is a large set of small objects. All these small objects are flooding manageable heap making GC cycles very CPU intense. That’s not about Harmonia only by the way – I believe Android suffers from this problem too when its UI freezes noticeably.
- I’ve got very strong feeling that each part of UI framework shall use its own memory management and ownership principles that are optimal for the role they are playing. HTML DOM tree has very regular structure with clear one parent – many children ownership graph. Life cycle of DOM elements (read “UI elements”) is also quite deterministic. There is absolutely no need for GC if to speak about HTML/CSS.
- But code-behind-UI – code that does UI automation in “on-click-here-push-item-there-and-collapse-panel-over-there” fashion has to be manageable. GC there is the must – ownership graph is unknown upfront and frequently contains loops.
So I reverted back to C++ and created pure DOM and rendering implementation – HTMLayout. And started looking on embeddable languages that can be used with it as “language behind UI”. Here are languages that I considered for that purpose:
- Ruby and Python – were rejected almost immediately. HTML friendly language shall have syntax that is not dependent on tabs, line feeds, etc. For quite many reasons. And yet Python was using C/C++ heap for object allocations, UI objects lifecycle require compacting GC – objects created and destroyed frequently.
- Lua – pretty much for the same syntax reasons. But it was a good candidate. I even started creating JS syntax alike compiling front-end for its VM. But discovered in process that Lua’s object/class model is too rudimentary I would say.
- JavaScript – as a natural choice was always there. But its prototyping schema, “hackish” way of doing classes there and that famous “automatic semicolon injection” problem were stopping me each time I was trying to consider it. Only ECMAScript version 6 has started to appear solid enough. But that’s just recently.
Needless to say that my investigation ended up in creation of first C-SMILE and then TIScipt. TIScript is almost JavaScript (JavaScript++ if you wish) but with modular system (namespaces) and classes. It also got built-in persistence. And it inherits base syntax and runtime library from JavaScript.
HTMLayout combined with TIScript became Sciter as you see it now.
Oh, and in parallel with all this I was working as UI Architect and team lead at Top Producer Systems (move.com company) on various desktop UI, Web and mobile applications projects. And yet participated in HTML5 and CSS3 specification development as invited expert in W3C HTML Working Group.