6 ms·

Sciter then (https://sciter.com https://sciter.com): - multiple platforms... Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles.

Sciter then (https://sciter.com https://sciter.com): - multiple platforms... Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles. - multiple windows - Yes. Multiple desktop windows and you can even render separate DOM elements in popup windows. - rendering to a window that isn't owned by the UI being rendered Yes, you can render it on top DirectX, OpenGL, Vulkan (coming) or in child window/nsview/gtkwidget. There is also Sciter.Lite that allows to render UI without any DWM - on frame buffer / video memory directly. Check : https://sciter.com/sciter-and-directx/ https://sciter.com/sciter-and-directx/ - don't need to bring up electron. Not Electron. All this in monolithic dll/so (5..9mb) that even can be linked in statically. - consistent rendering across multiple platforms. Check screenshots of https://notes.sciter.com/ https://notes.sciter.com/ , are they consistent enough? - ... for React React (Reactor in Sciter terms) is implemented natively. JSX (SSX in Sciter) is a part of language/runtime - no need for additional compilers, etc. - I'd love to abandon my C/C++ ... No need to. You can still manage (update, handle events) UI directly from C++ if needed. You can even create custom native DOM elements that can even draw themselves by native code.

qppo 6y ago
Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the ground in your framework than using my existing codebase and frameworks with larger ecosystems. I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite. Some bencharks comparing engine performance to V8 would also be much appreciated.
- c-smile 6y ago
  1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases. 2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sciter-sqlite.h https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci... 3. "it has a larger community..." I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed. "Some bencharks comparing engine performance to V8" Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.
  - qppo 6y ago
    Very interesting work. I need to re-evaluate in the future.
Sophistifunk 6y ago
HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text documents. What we need is a cross platform well-thought-out scene graph like Flash had or Flutter (kinda) has.
- deleted 6y ago
  [deleted]
- c-smile 6y ago
  > the DOM is just fundamentally unsuited for app UI rendering... Consider the following: Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these. HTML/DOM UI: Same as above, just replace "widget" by "element". Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?
  - Sophistifunk 6y ago
    The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component without throwing away all the good things about HTML like accessibility; the things going on inside Visual Studio Code required to produce even an experience as good as that must haunt the team that builds it. The disconnect in process between "building something out of built-in components" against "build and using a new component", the list goes on. And just about all of these things are made worse by both the cascade rules and complicated precedence system of CSS.
    - c-smile 6y ago
      > The most glaring is the ability to measure things (including text) in order to lay them out ... This has nothing with the DOM (or HTML or CSS for that matter). Yes, sometimes in desktop UI you will need to know exact element position/dimensions. That's why in Sciter I've added: 1. element.update(); method, it will force dimensions to be calculated at this moment. 2. element.onSize = function() {...} called when dimensions of the element change. 3. element.paintContent = function(graphics) {} called to paint the element on graphics. Dimensions and position of the element is known at this moment. 4. There is a Graphics.Text object that allows to calculate (not just render) text and glyph positions. My main point with all this: it is a matter of API provided and has nothing with HTML/CSS per se. For that matter, Flutter also uses DOM (tree of widgets, etc.). It is just that its style system is not declarative and misses cascading - for some reasons they decided to use WPF/XAML way of doing business. But we've already sang "Sic transit gloria mundi" to WPF ... For the text editing... check html-notepad : https://html-notepad.com/ https://html-notepad.com/ . Left sidebar (structure outline) is computed and painted in immediate rendering painting mode - when paintContent of the document is invoked.
airstrike 6y ago
This is actually amazing. Thanks for sharing. I see someone actually submitted the homepage 40 mins ago so I upvoted it for awareness. This is so feature complete I'm frankly surprised it hasn't hit the front page before. https://news.ycombinator.com/item?id=23163320 https://news.ycombinator.com/item?id=23163320

qppo 6y ago

Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the ground in your framework than using my existing codebase and frameworks with larger ecosystems. I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite. Some bencharks comparing engine performance to V8 would also be much appreciated.

c-smile 6y ago
1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases. 2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sciter-sqlite.h https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci... 3. "it has a larger community..." I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed. "Some bencharks comparing engine performance to V8" Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.
- qppo 6y ago
  Very interesting work. I need to re-evaluate in the future.

Sophistifunk 6y ago

HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text documents. What we need is a cross platform well-thought-out scene graph like Flash had or Flutter (kinda) has.

deleted 6y ago
[deleted]
c-smile 6y ago
> the DOM is just fundamentally unsuited for app UI rendering... Consider the following: Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these. HTML/DOM UI: Same as above, just replace "widget" by "element". Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?
- Sophistifunk 6y ago
  The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component without throwing away all the good things about HTML like accessibility; the things going on inside Visual Studio Code required to produce even an experience as good as that must haunt the team that builds it. The disconnect in process between "building something out of built-in components" against "build and using a new component", the list goes on. And just about all of these things are made worse by both the cascade rules and complicated precedence system of CSS.
  - c-smile 6y ago
    > The most glaring is the ability to measure things (including text) in order to lay them out ... This has nothing with the DOM (or HTML or CSS for that matter). Yes, sometimes in desktop UI you will need to know exact element position/dimensions. That's why in Sciter I've added: 1. element.update(); method, it will force dimensions to be calculated at this moment. 2. element.onSize = function() {...} called when dimensions of the element change. 3. element.paintContent = function(graphics) {} called to paint the element on graphics. Dimensions and position of the element is known at this moment. 4. There is a Graphics.Text object that allows to calculate (not just render) text and glyph positions. My main point with all this: it is a matter of API provided and has nothing with HTML/CSS per se. For that matter, Flutter also uses DOM (tree of widgets, etc.). It is just that its style system is not declarative and misses cascading - for some reasons they decided to use WPF/XAML way of doing business. But we've already sang "Sic transit gloria mundi" to WPF ... For the text editing... check html-notepad : https://html-notepad.com/ https://html-notepad.com/ . Left sidebar (structure outline) is computed and painted in immediate rendering painting mode - when paintContent of the document is invoked.

airstrike 6y ago

This is actually amazing. Thanks for sharing. I see someone actually submitted the homepage 40 mins ago so I upvoted it for awareness. This is so feature complete I'm frankly surprised it hasn't hit the front page before. https://news.ycombinator.com/item?id=23163320 https://news.ycombinator.com/item?id=23163320