Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

sciter.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#71

Post by c-smile »

cosmotic wrote: post #62
c-smile wrote: post #46

Earlier quoted context omitted.

Sciter's author here. > HTML/CSS based native interfaces are some of the hardest to use, least reliable, least accessible, least robust interfaces I encounter This has nothing with HTML/CSS per se but rather questions to particular products. Same complain may apply to any UI. > The best native apps look and behave natively; "Native app" term these days is something almost non existent. In these terms Microsoft Office…

UWP are an interesting example. They are the most 'native' (at least looking) kind of application on windows 10 but I realize they aren't using win32 (which I think is what we both mean when we refer to native). Regardless, UWP are terrible; they are very hard to use and look awful, if not flat and uncluttered. Office is a bad example as well; that team is notorious for choosing new/different interface controls just…

> drab boring win32 applications

For example?

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#72

Post by c-smile »

mratsim wrote: post #8

Assuming you want a very lightweight HTML/CSS UI engine, I think you can get 80% of the way by using webview[1]. It's very tiny (1200 lines single-header file). I actually wouldn't be surprised if it used webview internally. [1]: https://github.com/zserge/webview

Sciter does not use webview or any other existing browser engine implementation. I did HTML/CSS and script engines by myself.

The only place where I intersected with WebKit and Gecko teams is at WHATWG and then HTML WG at W3C in design of HTML5 specification and portions of CSS3.

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#73

Post by c-smile »

paulryanrogers wrote: post #69
c-smile wrote: post #55

Earlier quoted context omitted.

> orthogonal to reasons That's my impression too. I suspect that those "gray boxes" talks (a.k.a. buttons a la turrets of Panzerkampfwagen VI Tiger) are orthogonal to GUI in general. Yet "memory and CPU usage" is also orthogonal to HTML/CSS per se. One of strict requirements of AntiVirus applications is to to consume as low memory and CPU as possible. And most of AVs are using HTML/CSS UI these days. And so Sciter co…

> And most of AVs are using HTML/CSS UI these days. If AV background and scanner processes use those then that's yet another reason to drop them like a bad habit. (The other reason being they increase the attack surface area.)

No, AV scanning has nothing with UI layer other than posting events "something found - here are details". Even more, usually scans are done in separate processes/daemons.

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#74

Post by tomku »

LockAndLol wrote: post #64

So did they write their own layout and JS engine? Or does this use Blink / another dependency under the hood? I found this https://sciter.com/developers/engine-architecture/ but it doesn't say if it's all written from scratch or using other libs.

It's completely written from scratch, and does not aim for compliance with web standards.

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#75

Post by erinaceousjones »

realharo wrote: post #50
vijaybritto wrote: post #47

Earlier quoted context omitted.

I'm talking about RAM not SSD. And no I don't have multiple computers in my house. A single laptop with 16G of RAM is all I have. I have to use it for work. We all know about music apps playing music while using less than 50M at any given time. If its in the background then even less. I know the dev experience is far greater in electron but its simply not performant. But if I were to launch a product on all platforms…

RAM's about the same, hovering slightly below 200MB (Windows shows a sum of all the different Chromium processes). Which for me is firmly in the "who cares" territory. Lightweight music apps don't have the online playlists, discovery mechanisms (Discover Weekly, etc.) and all that other stuff.

They could do though. All the smarts of Spotify comes from their APIs. There's been a bunch of third party low-resource clients / integrations for spotify; despotify, mopidy, recently this thing: https://github.com/hrkfdn/ncspot

Unfortunately iirc the neat dynamically generated playlist stuff isn't supported because it's not exposed properly through their APIs. Certainly when I tried to use Spotify's own libspotify its functionality was crippled to static playlist management, searching for stuff, and playback. despotify was in a similar state at the time.

Also - Spotify sucks HARD at doing all the stuff it does, and I blame this entirely on the UI implementation. The service, I love. The apps, I have become to loathe. They used to be nice and quick and responsive. Now? It can't even get shuffle right!! My mid tier smartphone takes 10 minutes to load search results or my own playlists sometimes; something i've encountered across multiple devices. The desktop app crawls on my 24gb 8-core workstation.

Conversely, I can have a 200gb library of music loaded into mpd or foobar2000 or vlc in all sorts of exotic (and higher bitrate) formats and from weird and wonderful local and remote storage and play it all on shuffle and have all the albumart showing and it organised neatly into a searchable library via the id3 tags and have volume normalized with replaygain and it'll do it in under 20mb and has been doing so for a decade.........

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#76

Post by jcelerier »

doteka wrote: post #57
xthetrfd wrote: post #17

Earlier quoted context omitted.

It seems to me at this point that UI/UX developers just refuse to learn low level languages. Qt applications for example are extremely fast and cross platform.

It seems to me that wanting UI developers to learn systems languages is bizarre. We don’t expect Linux kernel developers to learn UI/UX, why would the opposite be the case? They are working on a vastly different abstraction level. Also, yeah, Qt is indeed fast and cross platform. But somehow every single mainstream Qt application tends to look visually terrible and not any more native than Electron. E.g. Ripcord post…

> Finally, Qt’s weird and deceiving licensing is a major reason I would never touch it with a 10 foot pole. I am not a copyright lawyer and have no desire to figure out how I can comply with LGPL, when Electron is MIT.

you know that Electron uses Blink which is LGPL right ? It also ships by default with ffmpeg which is used by chromium for video rendering, which is also LGPL (https://source.chromium.org/chromium/chromium/src/+/master:t...).

See https://lists.gnu.org/archive/html/directory-discuss/2017-12... - and some LGPL-prefixed files from Blink's source code if you don't believe :-)

https://chromium.googlesource.com/chromium/blink/+/master/So...

I'll let you note the large irony of WebKit & thus Blink & Electron originally coming from KHTML, that is, a KDE project originally built with Qt - Lars Knoll at the top of that copyright header is currently CTO of The Qt Company.

Re: Sciter – Multiplatform HTML/CSS UI Engine for Desktop and Mobile Applications

#77

Post by nickpsecurity »

c-smile wrote: post #58
sgerenser wrote: post #41

Earlier quoted context omitted.

Skins like that don’t scale. Fine if you’re still using a 1366*768 laptop, but even 1080p let alone 4K makes everything tiny or blown up and blurry. Doesn’t mean you need electron to fix it, it can be done with a native UI. But bitmapped skins are generally not used anymore for a reason.

> it can be done with a native UI. Yes, but with what price? We (people outside of Microsoft, Apple and Google) cannot afford UIs nailed down to pixel grids and particular trends. Years ago it was Skeumorphism, then it was flat UI as Metro, today people started speaking about Skeumorphism again. CSS is just a convenient tool to follow the trends. And "yes" it "doesn’t mean you need electron" as there are other option…

You're taking a lot of crap here. I just wanted to chime in to say I thank you for trying to build something like Electron that's still lean and efficient. On top of it, I always use your licensing plans as a positive example in discussions about beneficial, but sustainable, licensing strategies. licensezero.com comes to mind. Keep up the good work.
Post reply on HN