9 ms·

This is definitely the way to go! The browser is not only good at network requests and sandboxing but comes with the most powerful layouting system and renderin

This is definitely the way to go! The browser is not only good at network requests and sandboxing but comes with the most powerful layouting system and rendering engine. So yes, leveraging browsers just for the front-end of a local-first app is such a good direction to go. Generally apps tend to bundle their own browser runtime to leverage this component. Even the lighter weight electron alternatives tend to either implement a part of the browser runtime themselves or at least need separate webview instances. But I already have a browser installed and why can't my local apps integrate with my installed browser to expose their functionality? This project looks like a good step into that direction.

troupo 3y ago
> but comes with the most powerful layouting system and rendering engine. It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.
- austin-cheney 3y ago
  I am not sure how you come to this conclusion. JS and the DOM are fast. Aside from arithmetic JS is just as fast as Java now and only 2-4x slower than C++. The two big limitations from a pure processing perspective are the garbage collector and massive repaints of large data on large layouts.
  - pjmlp 3y ago
    As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.
    - austin-cheney 3y ago
      Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - Xeamek 3y ago
        Synthetic benchmarks for some algorithms have little to do with actual performance of real life applications
        cuu508 3y ago
        What method do you propose to compare the performance of different programming languages?
        Xeamek 3y ago
        While still far from perfect, benchmarks comparing actual, practical usage, like the ammount of request served by webservers for example, are much better indicators imo. https://web-frameworks-benchmark.netlify.app/result https://web-frameworks-benchmark.netlify.app/result
        oldpersonintx 3y ago
        [dead]
        d3w4s9 3y ago
        Yeah everyone says that and stops there which is absolutely useless. Benchmarks are at least objective ways to measure something. And there are no "correct" benchmarks. Unless you have better metrics or another way to prove things, please stop repeating these meaningless words
        Xeamek 3y ago
        I've literally pasted benchmarks measuring actual job (webserver request per second) in a comment below. But besides, the critique isn't meaningless even without providing a better one; If your benchmark is measuring things that are trivial no matter the language (like stack-based operations), but ignores things that actually differ meaningfully (like handling of heap objects), then criticizing such aproach is perfectly fair and valid objection
    - oldpersonintx 3y ago
      [dead]
  - troupo 3y ago
    > I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great lengths to touch DOM as little as possible. A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s. It's a system designed to render a page of text with a couple of images in one rendering pass at the core, and no amount of hacks on top of it will make it a high-perfromant layout and rednering engine. > Aside from arithmetic JS is just as fast as Java now This has nothing to do with either layout or rendering > The two big limitations from a pure processing perspective are the garbage collector Has nothing to do with either layout or rendering > massive repaints of large data on large layouts. Where "large data" is measly thousands of elements. Massive repaints in DOM happen basiclly on any and all layouts and layout changes. And these changes are triggered by almost anything that happens in the DOM. There's a reason why any reasonable animation you can reliably do with DOM is to literally rip the element out of the layout context and render it independently because "the most powerful layout and re-rendering engine" cannot cope with re-calculating and re-rendering the layout for the entire page when you move elements around. Edit. Slightly more on this: - Rendering performance https://web.dev/articles/rendering-performance https://web.dev/articles/rendering-performance - Linked article, Stick to Compositor-Only Properties and Manage Layer Count https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count https://web.dev/articles/stick-to-compositor-only-properties... From the last article: there are only two properties that can be handled by the compositor alone, all others trigger either a re-flow+re-paint or a re-paint.
    - austin-cheney 3y ago
      Please, don't guess at performance. My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders. The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
  - croes 3y ago
    Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.
    - TuringTest 3y ago
      Native GUIs are fast, but they are not powerful. You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. The web browser gives you a full package with standardized commands to control all those aspects, which is also portable between different implementations. If your rendering needs are limited to a few buttons and a canvas on a fixed size, sure, go native GUI. But if you need to support multiple devices and resolutions, on-the-fly resizing, and layout of multiple complex screen sections, the browser is an unbeatable platform.
      - nvm0n2 3y ago
        Fixed resolution and size? Manual layout calculations? What was the last native GUI toolkit you used, Win32?
      - devbent 3y ago
        > You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. Even Java UIs supported dynamic layouts 20 years ago. C# had a flex box based layout (called flow layout) since 2006.
        h4x0rr 3y ago
        Worse developer experience and worse style options though
        bananaboy 3y ago
        I strongly disagree with that. WinForms is imho very easy to use.
flohofwoe 3y ago
> but comes with the most powerful layouting system and rendering engine If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM. The DOM was originally created to render static text-heavy documents, baking such a limited document-layout system into browsers was a mistake in hindsight. These days, the DOM should be "just another" on-demand loaded Javascript UI framework sitting on top of a handful lower level rendering APIs.
- immibis 3y ago
  I thought flexbox solved this.
- diggan 3y ago
  > If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore). The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state. People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases. Well, except when it's chosen by cargocult, which is probably most of the cases.
  - troupo 3y ago
    Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation. And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?
huijzer 3y ago
SABnzbd agrees since 2016.
- chrnola 3y ago
  Hmmm I thought it ran its own web server instead.
  - huijzer 3y ago
    Ah okay I didn't know that you could avoid that. "Think of WebUI like a WebView controller" the README says.
samstave 3y ago
It will be interesting if one could have one's webapp also be able to accept browser extensions as add-ons to functionality to the app - such that users can create their own 'packages' for your webapp just as anyone would do browser extensions? or does this sound stupid (obviously the biggest risk here is malevolent extensions (dont make medical apps out of this :-)
croes 3y ago
Good luck running you GUI from know in a browser in ten years or maybe even five. Not to mention that WebGUIs are slow compared to native ones. https://news.ycombinator.com/item?id=36446933 https://news.ycombinator.com/item?id=36446933
- zamadatix 3y ago
  Browsers have extremely good backwards compatibility, five or ten years should really not net you any problems. They do carry quite a bit of bloat however, though so do most native toolkits these days.
  - croes 3y ago
    For old features yes, for new ones it depends. https://github.com/philipwalton/flexbugs https://github.com/philipwalton/flexbugs And there could be changes because of security concerns like with alert (), prompt() and confirm().
    - c-hendricks 3y ago
      Just FYI, most (all?) of those are in years-old versions of evergreen browsers, no affected versions listed are supported I don't think.
- bobthepanda 3y ago
  The problem with native has always been that * Users expect consistency within their apps, and will complain loudly if platform A has something that platform B has not * the native platforms’ rendering technologies are so different that you basically need a developer or team dedicated to each platform, with their own test infrastructure, etc. * even if you can afford to do the above, herding four teams using different technologies to do a coordinated feature release schedule is like herding cats In any case the native platforms hardly do much better. There are plenty of Windows, Mac, Android, iOS applications from ten years ago that don’t work well today, for instance.
keepamovin 3y ago
This is very polished and cool-looking. Inspiring. I find this project's level of polish very inspiring. It's lovely to see someone has captured this idea and expressed it in the right way to make it interesting to many people. I really hope this mode of desktop apps can take off, at least to the level where the community has something to explore for a while to see if it works. I made something like this for Chrome browsers a while ago: nodejs backends, vanilla front-ends, built-in packaging using pkg. It's just a nice approach: https://github.com/dosyago/graderjs https://github.com/dosyago/graderjs And I made a demo using the venerable MS Paint clone JS Paint^0. The dev experience was great, I literally just dropped in the front-end code to the right folder, compiled it and wham, "desktop JS Paint" on 3 platforms, haha. Using the ubiquitous local browser as the rendering / API engine for desktop just seems smart. And it's technically interesting, because you get to think in terms of how can you step back from the browser, the platform, the front-end and the back-end and come up with a general API that addresses all of it, which is kinda cool. 0: https://github.com/00000o1/jspaint.exe https://github.com/00000o1/jspaint.exe
cortesoft 3y ago
This is how Plex works
- retrochameleon 3y ago
  Wow I had no idea and I'm a web dev. Have they published about that anywhere?
skrowl 3y ago
[dead]

troupo 3y ago

> but comes with the most powerful layouting system and rendering engine. It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.

austin-cheney 3y ago
I am not sure how you come to this conclusion. JS and the DOM are fast. Aside from arithmetic JS is just as fast as Java now and only 2-4x slower than C++. The two big limitations from a pure processing perspective are the garbage collector and massive repaints of large data on large layouts.
- pjmlp 3y ago
  As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.
  - austin-cheney 3y ago
    Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - Xeamek 3y ago
      Synthetic benchmarks for some algorithms have little to do with actual performance of real life applications
      - cuu508 3y ago
        What method do you propose to compare the performance of different programming languages?
        Xeamek 3y ago
        While still far from perfect, benchmarks comparing actual, practical usage, like the ammount of request served by webservers for example, are much better indicators imo. https://web-frameworks-benchmark.netlify.app/result https://web-frameworks-benchmark.netlify.app/result
        oldpersonintx 3y ago
        [dead]
      - d3w4s9 3y ago
        Yeah everyone says that and stops there which is absolutely useless. Benchmarks are at least objective ways to measure something. And there are no "correct" benchmarks. Unless you have better metrics or another way to prove things, please stop repeating these meaningless words
        Xeamek 3y ago
        I've literally pasted benchmarks measuring actual job (webserver request per second) in a comment below. But besides, the critique isn't meaningless even without providing a better one; If your benchmark is measuring things that are trivial no matter the language (like stack-based operations), but ignores things that actually differ meaningfully (like handling of heap objects), then criticizing such aproach is perfectly fair and valid objection
  - oldpersonintx 3y ago
    [dead]
- troupo 3y ago
  > I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great lengths to touch DOM as little as possible. A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s. It's a system designed to render a page of text with a couple of images in one rendering pass at the core, and no amount of hacks on top of it will make it a high-perfromant layout and rednering engine. > Aside from arithmetic JS is just as fast as Java now This has nothing to do with either layout or rendering > The two big limitations from a pure processing perspective are the garbage collector Has nothing to do with either layout or rendering > massive repaints of large data on large layouts. Where "large data" is measly thousands of elements. Massive repaints in DOM happen basiclly on any and all layouts and layout changes. And these changes are triggered by almost anything that happens in the DOM. There's a reason why any reasonable animation you can reliably do with DOM is to literally rip the element out of the layout context and render it independently because "the most powerful layout and re-rendering engine" cannot cope with re-calculating and re-rendering the layout for the entire page when you move elements around. Edit. Slightly more on this: - Rendering performance https://web.dev/articles/rendering-performance https://web.dev/articles/rendering-performance - Linked article, Stick to Compositor-Only Properties and Manage Layer Count https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count https://web.dev/articles/stick-to-compositor-only-properties... From the last article: there are only two properties that can be handled by the compositor alone, all others trigger either a re-flow+re-paint or a re-paint.
  - austin-cheney 3y ago
    Please, don't guess at performance. My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders. The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
- croes 3y ago
  Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.
  - TuringTest 3y ago
    Native GUIs are fast, but they are not powerful. You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. The web browser gives you a full package with standardized commands to control all those aspects, which is also portable between different implementations. If your rendering needs are limited to a few buttons and a canvas on a fixed size, sure, go native GUI. But if you need to support multiple devices and resolutions, on-the-fly resizing, and layout of multiple complex screen sections, the browser is an unbeatable platform.
    - nvm0n2 3y ago
      Fixed resolution and size? Manual layout calculations? What was the last native GUI toolkit you used, Win32?
    - devbent 3y ago
      > You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. Even Java UIs supported dynamic layouts 20 years ago. C# had a flex box based layout (called flow layout) since 2006.
      - h4x0rr 3y ago
        Worse developer experience and worse style options though
        bananaboy 3y ago
        I strongly disagree with that. WinForms is imho very easy to use.

flohofwoe 3y ago

> but comes with the most powerful layouting system and rendering engine If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM. The DOM was originally created to render static text-heavy documents, baking such a limited document-layout system into browsers was a mistake in hindsight. These days, the DOM should be "just another" on-demand loaded Javascript UI framework sitting on top of a handful lower level rendering APIs.

immibis 3y ago
I thought flexbox solved this.
diggan 3y ago
> If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore). The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state. People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases. Well, except when it's chosen by cargocult, which is probably most of the cases.
- troupo 3y ago
  Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark https://github.com/krausest/js-framework-benchmark Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation. And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?

huijzer 3y ago

SABnzbd agrees since 2016.

chrnola 3y ago
Hmmm I thought it ran its own web server instead.
- huijzer 3y ago
  Ah okay I didn't know that you could avoid that. "Think of WebUI like a WebView controller" the README says.

samstave 3y ago

It will be interesting if one could have one's webapp also be able to accept browser extensions as add-ons to functionality to the app - such that users can create their own 'packages' for your webapp just as anyone would do browser extensions? or does this sound stupid (obviously the biggest risk here is malevolent extensions (dont make medical apps out of this :-)

croes 3y ago

Good luck running you GUI from know in a browser in ten years or maybe even five. Not to mention that WebGUIs are slow compared to native ones. https://news.ycombinator.com/item?id=36446933 https://news.ycombinator.com/item?id=36446933

zamadatix 3y ago
Browsers have extremely good backwards compatibility, five or ten years should really not net you any problems. They do carry quite a bit of bloat however, though so do most native toolkits these days.
- croes 3y ago
  For old features yes, for new ones it depends. https://github.com/philipwalton/flexbugs https://github.com/philipwalton/flexbugs And there could be changes because of security concerns like with alert (), prompt() and confirm().
  - c-hendricks 3y ago
    Just FYI, most (all?) of those are in years-old versions of evergreen browsers, no affected versions listed are supported I don't think.
bobthepanda 3y ago
The problem with native has always been that * Users expect consistency within their apps, and will complain loudly if platform A has something that platform B has not * the native platforms’ rendering technologies are so different that you basically need a developer or team dedicated to each platform, with their own test infrastructure, etc. * even if you can afford to do the above, herding four teams using different technologies to do a coordinated feature release schedule is like herding cats In any case the native platforms hardly do much better. There are plenty of Windows, Mac, Android, iOS applications from ten years ago that don’t work well today, for instance.

keepamovin 3y ago

This is very polished and cool-looking. Inspiring. I find this project's level of polish very inspiring. It's lovely to see someone has captured this idea and expressed it in the right way to make it interesting to many people. I really hope this mode of desktop apps can take off, at least to the level where the community has something to explore for a while to see if it works. I made something like this for Chrome browsers a while ago: nodejs backends, vanilla front-ends, built-in packaging using pkg. It's just a nice approach: https://github.com/dosyago/graderjs https://github.com/dosyago/graderjs And I made a demo using the venerable MS Paint clone JS Paint^0. The dev experience was great, I literally just dropped in the front-end code to the right folder, compiled it and wham, "desktop JS Paint" on 3 platforms, haha. Using the ubiquitous local browser as the rendering / API engine for desktop just seems smart. And it's technically interesting, because you get to think in terms of how can you step back from the browser, the platform, the front-end and the back-end and come up with a general API that addresses all of it, which is kinda cool. 0: https://github.com/00000o1/jspaint.exe https://github.com/00000o1/jspaint.exe

cortesoft 3y ago

This is how Plex works

retrochameleon 3y ago
Wow I had no idea and I'm a web dev. Have they published about that anywhere?

skrowl 3y ago

[dead]