Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
c-smile
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
41 ms
·
421.
▲
by
c-smile
6y ago
Shadow DOM does not solve any real life problem. sDOM is spherical horse in a vacuum, my pardon.
422.
▲
by
c-smile
6y ago
The good thing about this mechanism is that you just need CSS in order to declare your components. The script will run only if you have elements with matching selectors. So you may have component libraries. Browser will instantiate only use
423.
▲
by
c-smile
6y ago
> Can we fix this? Sure, by returning to basics. Let's assume that Web Component is a DOM element with a code associated with it + lifecycle events. Here is how Components are done in Sciter ( https://sciter.com ) 1. CSS
424.
▲
by
c-smile
6y ago
> you can't have an encapsulated component that combines user input with validation that comes from the business logic. Why not? On UI layer I can always do: var response = bl.sendMessage("account.validate", accountD
425.
▲
by
c-smile
6y ago
Being a creator of Sciter ( https://sciter.com ), I would insist it is good in the sense: 0. Really cross platform: Win, Mac, Linux, Mobiles, IoT. 1. Uses stable (10+ years) and compact API - 30 functions really 2. Uses well known
426.
▲
by
c-smile
6y ago
UI and BL (business logic layer) can interact by messages. Think about Protocol Buffers ( https://developers.google.com/protocol-buffers ) or JSON/BSON as a core of communication protocol // App side:
427.
▲
by
c-smile
6y ago
Something tells me that you will end up in HTML/CSS/DOM and bubbling/sinking event propagation schema (used in browsers) as the most flexible one, see: https://en.wikipedia.org/wiki/Event_bubbling I did
428.
▲
by
c-smile
6y ago
Try to consider other way around. Native application is: 1. HTML - declaration of UI structure (think about accessibility here to). 2. CSS - declaration of how that UI structure shall be presented to the user. 3. script - declaration (t
429.
▲
by
c-smile
6y ago
Good GUI layer should be language agnostic. Reasons: 1. GUI is non-trivial. That is not just about problems of CPU/GPU rasterization (30...40% of all GUI problems). There are others that we usually forget about: accessibility, customiz
430.
▲
by
c-smile
6y ago
We just need to add one method to Web API: document.mutate(function(mutator) { mutator.changeAttributes(el,{...}); mutator.appendNodes(el,...); ... }); The mutate will do transactional update as fast as possib
431.
▲
by
c-smile
6y ago
"Because DOM is slow" DOM is not slow, in principle. What makes updates slow is the fact that each mutating DOM function must left the DOM in consistent state - rendering trees invalidated, etc. This creates significant overhead o
432.
▲
by
c-smile
6y ago
Just this https://www.youtube.com/watch?v=6uXiAe7Oc-I if someone in doubts.
433.
▲
by
c-smile
6y ago
Sciter's author here. Please ask me any questions about the Sciter and the campaign.
434.
▲
by
c-smile
6y ago
I did not realize that Hacker News is that old ...
435.
▲
by
c-smile
6y ago
Quite a lot actually. And even new software is designed these days to ride those dinosauri. Screenshot of one of Sciter's customers who develop software for Windows 2000, Solaris 10, HPUX 11, AIX 5, etc : https://sciter.com&
436.
▲
by
c-smile
6y ago
> Why is wasm necessarily slower Usually wasm is twice slower than native code: https://www.usenix.org/conference/atc19/presentation/jangda WebAssembly is essentially a bytecode that needs to be JITted bef
437.
▲
by
c-smile
6y ago
I do not see any significant difference (other than different system fonts): Here is MacOS rendering https://sciter.com/wp-content/uploads/2020/09/mac-os-front.p...
438.
▲
by
c-smile
6y ago
If by "on different platforms" you mean "on different server platforms" then result will be different but close enough. On Windows, for example, Skia will render text closer to Direct2D/DirectWrite. On MacOS to Core
439.
▲
by
c-smile
6y ago
Sciter works just fine in games. Sciter.Lite (windowless engine) was designed exactly for that. Here it runs in Unreal Engine: https://sciter.com/see-sciter-lite-unreal-engine-in-theaters... - HTML/CSS primitives are
440.
▲
by
c-smile
6y ago
You can use native platform widgets with Sciter. If you will find one suitable. It is just that there are absolutely no standard platform widgets (at least on Windows) for this UI. https://notes.sciter.com/wp-content/up
441.
▲
by
c-smile
6y ago
What is your estimation of creating something like this: https://notes.sciter.com/ ? UI, application logic and data storage. QML is far not enough for this I think. It took me 3.5 months ( https://notes.sciter.co
442.
▲
by
c-smile
6y ago
Just to get a feeling, see screenshots of Sciter Notes application on major desktop platforms: https://notes.sciter.com/ The application uses exactly same code on all platforms: https://github.com/c-smile&#x
443.
▲
by
c-smile
6y ago
> but none about security so far. 97% of users don't care about security issues that Rust can solve in principle.
444.
▲
by
c-smile
6y ago
Why "in theory"? Here are real life applications: https://sciter.com/#customers
445.
▲
by
c-smile
6y ago
> to find a no frills rendering engine that I could package up like an Electron Here it is: Sciter ( https://sciter.com ) and Sciter.Quark ( https://quark.sciter.com ) in particular.
446.
▲
by
c-smile
6y ago
> would work with regular js as well In principle JS may work but it is too slow for that. Function calls are too pricey, no integer arithmetic, etc. At least in my Sciter ( https://sciter.com ) element's layout controller
447.
▲
by
c-smile
6y ago
Let's imagine a browser (UA) that supports basics of HTML (language portion of HTML5) and CSS (e.g. v 2.1). Yet it has WebVM instead of JS. WebVM is a virtual machine similar to JavaVM but with DOM, CSSOM and layout APIs exposed in it
448.
▲
by
c-smile
6y ago
Browser (shall I say the browser?), from "thin client on top of OS" became "web client on top of thin OS that just needed to run the thing". And indeed, zipped Chromium sources are of 1.4 Gb and Linux kernel is of 0.2 Gb
449.
▲
by
c-smile
6y ago
"extremely optimized V8" JS code is always slower than native html parsing code. No matter what. "10000 rows in a table" This: element.html = 10000 times "<tr>...</tr>"; is by order of
450.
▲
by
c-smile
6y ago
You'd be surprised but in general this element.html = "..."; is faster then ReactDOM.render(vdom,dom); at least for initial DOM tree population. There are many reasons for that. `element.html =` is implement
More ›