[HN Gopher] Web browser as GUI, with your preferred language in ...
___________________________________________________________________
Web browser as GUI, with your preferred language in the backend
Author : rguiscard
Score : 160 points
Date : 2024-01-01 09:30 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sph wrote:
| Off topic rant: can anyone explain why the syntax highlighting of
| Zig on Github turns every single word _brown_? I know they
| incorporated tree sitter, and for some reason the default syntax
| rules really dislike coloring identifiers in black.
|
| Look at the code example in this project README or its source.
|
| For a long time something bugged me about the language whenever I
| glanced at it, and it's all because Github and its stupid syntax
| coloring. I hate the rainbow vomit approach to syntax
| highlighting that's all the vogue these days. It should be a
| sprinkle on top, not the main course.
| naikrovek wrote:
| > every single word
|
| I'm not seeing that.
| LoganDark wrote:
| A better name for the color would probably be orange, at
| least in dark theme. Look at... variable names, field
| accesses, basically literally everything that is not a
| keyword or symbol. It's not _all_ supposed to be colored.
| There 's no plain white text anywhere!
| 38 wrote:
| yeah its awful. I fixed like this: /*
| ==userstyle== @name GitHub @namespace 3052
| @version 2023.10.27 ==/userstyle== */
| @-moz-document domain("github.com") { .pl-v {
| color: var(--color-fg-default) } }
| troupo wrote:
| Offtopic, but: why do people insist that Edge is a meaningfully
| different browser from Chrome?
|
| I'm not even going to ask about the table at the end that lists
| that it supports exactly two different browsers while listing 10.
| chrisco255 wrote:
| This is a good point. The only reason I can think of is that it
| is the default browser installed on Windows, which gives it
| automatic distribution.
| beardyw wrote:
| I would have thought at the browser level access to WebUI would
| not necessarily be a given as it seems that access is outside
| the browser engine. Glad to be corrected.
| pjmlp wrote:
| Mostly because what it does differently besides the rendering
| engine, but yeah it is still Chrome.
| lolinder wrote:
| In this case it's relevant because it means that your app will
| run on Windows even if the user hasn't installed anything else,
| since it can just pick up Edge.
| forgotpwd16 wrote:
| Project is part of the overall WebUI project making such bindings
| for a number of languages. Site* gives an example in C.
|
| *Which by the way needs a cert update.
| ahmedfromtunis wrote:
| Zig is just one of the many backend languages this project
| supports.
|
| This link is a better representation of the project as a whole:
| https://github.com/webui-dev/webui
| dang wrote:
| Ok, let's change the URL to that from https://github.com/webui-
| dev/zig-webui above. Thanks!
| lewisjoe wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| As fast as Java?!? Better tell Google to dump Android and
| focus on ChromeOS then.
| austin-cheney wrote:
| Yes. This has been the case for at least the last 5
| years.
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| Xeamek wrote:
| Synthetic benchmarks for some algorithms have little to
| do with actual performance of real life applications
| cuu508 wrote:
| What method do you propose to compare the performance of
| different programming languages?
| Xeamek wrote:
| 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
| d3w4s9 wrote:
| 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 wrote:
| 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
| trust_bt_verify wrote:
| These benchmarks include startup time _and_ processing
| time when comparing languages. I don't believe that is
| telling a very compelling story given JS is still
| slightly slower than most of the Java metrics unless you
| are looking for a new language to write your lambdas.
| pjmlp wrote:
| I only see random Java in synthetic benchmarks, without
| testing all variations of JIT and AOT compilers available
| throughout the ecosystem.
|
| OpenJDK, GraalVM, OpenJ9, Azul, PTC, Aicas, ART,
| JikesRVM,....
|
| Not to mention the optimizations that a dynamic language
| like JavaScript will never be able to take advantage of.
| igouy wrote:
| ?
|
| openjdk, GraalVM, Corretto
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| pjmlp wrote:
| Correcto is OpenJDK with Amazon branding, I left it out
| on purpose.
|
| Still, a dynamic language winning out a strongly typed
| one, only for those that don't have a clue about how
| compilers work, or how to write winning micro benchmarks.
| troupo wrote:
| > 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
|
| - Linked article, _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 wrote:
| 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/#b39045cacae8d8c4a3ec044e538533
| dc
| troupo wrote:
| > Please, don't guess at performance.
|
| I don't.
|
| > My biggest learning about performance is that
| developers don't know how to measure it.
|
| So have you measured it and compared it to anything else?
| Judging by the fact that you think that "JS is fast" has
| something to do with rendering and layout, my guess is
| that you haven't.
|
| > The DOM is an in-memory object accessed via a standard
| API.
|
| This has nothing to do with rendering, layout, and
| doesn't make it fast (compared to other ways of doing
| UIs) in the general case.
|
| > string parsing mechanisms, like query selectors, is
| several times faster than it used to be.
|
| Again. This has literally nothing to do with either
| layout or rendering.
|
| > To run your own tests see this micro-benchmark test:
|
| I said it: "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."
|
| > To run your own tests see this micro-benchmark test: ht
| tps://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
|
| Oh wow, you can select elements quickly. What does this
| have to do with the actual performance of things that
| matter? Or with the rest of your claim about rendering
| and layout?
|
| It's funny that you claim something about people
| guessing, and then use and talk about things that are
| completely irrelevant to your claims.
| d3w4s9 wrote:
| You comment shows that you have no practical knowledge of
| the web ecosystem, and everything you know about it comes
| from all the blog articles that contributes nothing
| that's useful in real world use. The reality is that web
| is fast _enough_ (even with all the tweaks and different
| approaches of frameworks, libraries etc), and it is the
| first choice for building a new cross-platform product
| and for migrating legacy projects. It makes all the
| business sense as well. Your pedantic arguments are not
| going to reverse that trend.
| troupo wrote:
| > You comment shows that you have no practical knowledge
| of the web ecosystem
|
| You're talking to a person with 20 years of frontend
| development experience. But sure, do go on with your
| assumptions.
|
| Also, no idea what "web ecosystem" has to do with the
| patently false claim of " the most powerful layouting
| system and rendering engine.", but do go on
|
| > The reality is that web is fast enough
|
| I never claimed it wasn't. But, again, without
| clarification of what fast is, or what enough is, it's
| again nebulous, and wrong for a very wide variety of use
| cases.
|
| > it is the first choice for building a new cross-
| platform product and for migrating legacy projects.
|
| I have no idea what this has to do with any of the things
| in this discussion.
|
| > Your pedantic arguments are not going to reverse that
| trend.
|
| Java applets and ActiveX also where the bee's knees and
| the best thing since sliced bread, and drove businesses
| and brought in billions of dollars in revenue.
|
| All this has literally nothing to do with the technology
| and how bad or good it is.
| austin-cheney wrote:
| I have also been writing for the web for over 20 years.
| This doesn't really mean anything though. That is why
| measures are all that matters. Bad measures are still
| monumentally better than no measures at all.
|
| The sad reality is that most people writing for the web
| today cannot do so without a framework. They have no idea
| how the layers underneath actually work. If you want to
| understand performance you must measure for it in
| multiple different ways and have something meaningful to
| compare it to. All modern browsers provide fantastic
| performance measuring tools in their developer tools. Its
| how I got my OS GUI (in a browser) to execute as fast as
| within 60ms of page load.
| troupo wrote:
| I couldn't agree with you more.
|
| Sadly enough the supercomputers we have still let us get
| away with the worst of the worst of performances with
| little penalties
| Xeamek wrote:
| >The reality is that web is fast enough
|
| No its fuckin not. We have devices running literally
| billions operations per second, orders of magnitude
| faster then what we had just few years ago, yet they
| struggle with rendering websites which comes down to
| presenting some good looking text. It's insane how my pc
| can compute entire 3d world with millions of triangles,
| 120 times a second, but it lags when I open few websites
| because some front dev crambed some 'cool' paralax effect
| onto it, or because facebook, (who literally invented
| react) can't handle it well enough to not make memory
| leaks everywhere.
|
| Did Usability of the web moved forward since few years
| ago? Sure. But compared to what computers can _actually
| do_ , it's insane how bad things are nowadays
| austin-cheney wrote:
| With a modern CPU and DDR5 memory you should be capable
| of running no slower than 10 billion DOM operations per
| second in Firefox. Usability is not performance.
| Xeamek wrote:
| 10 billions is a bit much, but yes
| Turing_Machine wrote:
| > et they struggle with rendering websites which comes
| down to presenting some good looking text.
|
| Umm... you're putting the blame on the wrong thing here,
| dude.
|
| > because some front dev crambed some 'cool' paralax
| effect onto it,
|
| As I said.
| Xeamek wrote:
| You mean that the fornt end devs aren't actually
| responsible for the rendering, but the browser devs are?
|
| Would you apply the same logic to game optimization?
| That's it's not the responsibility of game devs, and
| instead we can shift all the blame to the gpu sdk team?
| Turing_Machine wrote:
| > You mean that the fornt end devs aren't actually
| responsible for the rendering, but the browser devs are?
|
| Not at all. Quite the opposite, in fact. My position is
| that the browser is fast enough, and that any slowness is
| _exactly_ the fault of the site devs. You said the
| browser _wasn 't_ fast enough.
|
| Previous poster: The reality is that web is fast enough
|
| You: No its fuckin not.
| Xeamek wrote:
| Fair.
|
| I took 'web is fast enough' as in 'current state of web
| is fast enough'. But if we are still sticking to the
| actual internals of web browsers, i don't doubt they are
| quite 'state of the art'. It's just the outcome for the
| end user sucks
| troupo wrote:
| > You said the browser wasn't fast enough.
|
| It isn't. Not or what people are trying to make with it.
|
| Case in point: https://krausest.github.io/js-framework-
| benchmark/2023/table...
|
| The benchmark creates 1000 rows that look like this:
| <tr> <td><a onclick={select this row}>random
| short text</a></td> <td><a onclick={remove this
| row}><span /></a></td> <td></td> </tr>
|
| So, less than a 10k elements in total.
|
| The fastest of the fastest attempts to do this takes 36
| milliseconds to render. For what is essentially static
| markup with zero complex logic or complex interactions.
|
| In comparison: 1000 actors with complex interaction and
| behaviour, complex animations and lighting takes _4
| milliseconds to render_ (in total, significanly more than
| the measley 5-6k static elements on the page):
| https://youtu.be/kXd0VDZDSks?si=SswSZLNFlRd7adsM&t=586
| (at 9:46)
|
| I'm not saying everything should be Unreal Engine. But
| the web is on the lowest of the lowest end of the
| spectrum when it comes to performance.
| kaba0 wrote:
| It's almost like 3d rendering is vertices and shading is
| an embarrassingly parallel problem which is quite trivial
| to make faster by throwing more hardware at it.
|
| General layouting/text rendering, etc are not like that,
| and there is not even a "free" improvement anymore with
| single-threaded CPU speeds plateauing.
| Xeamek wrote:
| Yes, modern computers are just too slow to handle
| layouting a facebook page, nothing can be done.
| kaba0 wrote:
| Do you have _any_ form of proof that layouting is a
| bottleneck anywhere?
| Xeamek wrote:
| You were the one who said that layouting is much harder
| problem then 3d rendering...
| kaba0 wrote:
| It is a much harder problem, but it is working just fine
| on even low-end mobile phones with the majority of
| websites.
| Turing_Machine wrote:
| > The reality is that web is fast enough
|
| This. So much this.
|
| Yes, there are contrived examples where DOM rendering
| speed makes a difference, and also a fair amount of real-
| world crapware (much of it written by companies that
| should know better) where shitty code continues to hit
| the DOM unnecessarily hundreds or thousands of times even
| after the page is allegedly "loaded", but that is not the
| fault of the DOM.
| troupo wrote:
| > hit the DOM unnecessarily hundreds or thousands of
| times even after the page is allegedly "loaded", but that
| is not the fault of the DOM.
|
| If DOM was actually performant, this wouldn't be a
| problem.
| austin-cheney wrote:
| I think the misunderstanding is how to hit the DOM. If
| using static methods the performance cost is a memory
| cycle, so there can be many wasted steps and it's still
| negligible. If access is via query selector then there is
| a string parse operation which is a few orders of
| magnitude slower. That does not mean the DOM is slow.
| Even Lamborghinis are incredibly slow if you never move
| out of first gear.
| croes wrote:
| Could it be you forgot how fast native GUIs are?
|
| Every WebGUI I used lacks the snappiness of old school
| native ones.
| TuringTest wrote:
| 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 wrote:
| Fixed resolution and size? Manual layout calculations?
| What was the last native GUI toolkit you used, Win32?
| devbent wrote:
| > 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 wrote:
| Worse developer experience and worse style options though
| bananaboy wrote:
| I strongly disagree with that. WinForms is imho very easy
| to use.
| austin-cheney wrote:
| Yeah... JS and the DOM are incredibly fast, but that does
| not applications written for that platform are fast. Many
| JS developers have absolutely no idea how these
| technologies work and are reliant upon several layers of
| abstractions that are each progressively slower than the
| next.
|
| As an analogy crypto coin in theory is a good idea, but
| its rife with fraud because most people playing with
| crypto are speculators that have no idea what they are
| doing.
| flohofwoe wrote:
| > 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.
| diggan wrote:
| > 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 wrote:
| 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
|
| 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?
| diggan wrote:
| Which popular frontend framework advertise their DOM
| mutation speed on their frontpage exactly? Most frontend
| frameworks I come across nowadays advertise their
| developer experience and their features, not their DOM
| mutation speed.
|
| And when I say state manipulation I'm not talking about
| performance, I'm talking about the architecture and
| people working with the codebase. No one cares about
| state manipulation performance because as you said, it's
| a solved problem.
| troupo wrote:
| What do you think words like "performant framework for
| building web user interfaces" (Vue), "rendering is
| blazing fast, because Lit touches only the dynamic parts
| of your UI" (lit) and similar mean?
|
| No, they don't mean "our architecture and state
| manipulation".
|
| > No one cares about state manipulation performance
| because as you said, it's a solved problem.
|
| Indeed. That's way in any modern _all_ modern frameworks,
| without an exception, the main focus is how to touch the
| DOM as little as possible because it 's slow as molasses.
| diggan wrote:
| From your own example, here is the text from
| https://vuejs.org/ as of today:
|
| > The Progressive JavaScript Framework
|
| > An approachable, performant and versatile framework for
| building web user interfaces.
|
| > Approachable - Builds on top of standard HTML, CSS and
| JavaScript with intuitive API and world-class
| documentation.
|
| > Performant - Truly reactive, compiler-optimized
| rendering system that rarely requires manual
| optimization.
|
| > Versatile - A rich, incrementally adoptable ecosystem
| that scales between a library and a full-featured
| framework.
|
| Yes, performance is mentioned. But it's hardly the main
| selling point, and they don't even mention DOM
| manipulation, they're talking about the rendering in
| general.
|
| Lit isn't even a framework, it's a "web components
| library".
|
| > all modern frameworks
|
| Yeah, "all modern frameworks" being one framework + one
| library?
| troupo wrote:
| What do you think "performant UI" is in the context of
| the web?
|
| What do you think all frontend libraries have been
| optimizing for for the past decade?
|
| Why do you think they measure their performance by this
| benchmark: https://krausest.github.io/js-framework-
| benchmark/current.ht...?
|
| Or, as most people in the frontend space [1], you only
| understand the absolute surface level of the technologies
| you use? And unless it's spelled out in the exact words
| you expect, you don't understand the concepts?
|
| [1] I'm a frontender myself, and the amount of people I
| meet who don't even have the most basic understanding of
| the tools and technologies they use is mind-boggling.
| bobthepanda wrote:
| The issue most javascript frameworks try to fix with the DOM
| is the fact that it is not a language and does not have very
| good templating support. (Even web components in their plain
| form are pretty bad; no one wants to write
| document.appendChild everywhere)
|
| But no one has dethroned HTML and CSS as a fully baked cross
| platform engine, because it has been battle tested and
| optimized to death. And not really for lack of trying; UI is
| just actually very complicated.
| huijzer wrote:
| SABnzbd agrees since 2016.
| chrnola wrote:
| Hmmm I thought it ran its own web server instead.
| samstave wrote:
| 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 wrote:
| 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
| zamadatix wrote:
| 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 wrote:
| For old features yes, for new ones it depends.
|
| https://github.com/philipwalton/flexbugs
|
| And there could be changes because of security concerns
| like with alert (), prompt() and confirm().
| bobthepanda wrote:
| 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 wrote:
| 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
|
| 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
| cortesoft wrote:
| This is how Plex works
| Yaina wrote:
| Is it just me or does their logo look very similar to the
| Waterfox logo?
| jnrk wrote:
| No you're right. It's the same logo with a color shift and
| droplets removed:
|
| https://commons.wikimedia.org/wiki/File:Waterfox_logo_2019.p...
| lolinder wrote:
| Looks like it is--they started out with the same color scheme
| just without the splashes [0], then changed the colors when
| someone recognized it. From the thread it sounds like an honest
| mistake (though one that probably warranted stronger corrective
| action than just changing the colors). They seem to have
| assumed that everything on icons8 [1] was up for grabs, when in
| fact a lot of trademarks are on there.
|
| [0] https://github.com/webui-
| dev/webui/issues/100#issuecomment-1...
|
| [1] https://icons8.com/
| shellcoders wrote:
| This is funny =)
| Xeamek wrote:
| Is this basically Tauri, but with zig instead of Rust? Or are
| there some bigger, inherent differences? (Besides tauri being
| more mature, that is).
|
| Pretty cool
| diggan wrote:
| Kind of but also not. Tauri uses the default on the platform it
| runs on, this zig-webui project seems to be able to use every
| major browser and every major platform. For example, Firefox,
| Chrome and Edge all seem to be available for Windows, Linux and
| macOS in zig-webui, while Tauri would use a specific engine for
| a specific platform (by default at least).
| twen_ty wrote:
| Tauri can use a separate browser runtime if required. The use
| default is a space saving mechanism.
| diggan wrote:
| Is this described somewhere? I couldn't find anything in
| the configuration (https://tauri.app/v1/api/config &
| https://beta.tauri.app/references/v2/config/) about it,
| maybe I scanned through it too quickly?
|
| Unless you're referring to using tao and wry as libraries
| in your own application, but I guess that would be kind of
| cheating as it's not really a part of Tauri per-se in that
| case.
| zija wrote:
| They are working on servo implementation, but it's long
| time to go.
|
| Tauri has problem on Linux, webkit2gtk has lower
| performance etc. I know I have problems with three.js,
| others with svg
|
| Additionaly communication speed between backend and
| frontend is bottleneck (serialisation to string) and you
| must use custom protocols to effectively communicate/send
| large data, zero copy binary protocol isn't possible at the
| moment
| ksec wrote:
| >Is this basically Tauri, but with zig instead of Rust?
|
| WebUI is language agnostic so I guess Tauri but not limited to
| Rust would be a better description.
| petabyt wrote:
| Very different. Tauri directly embeds/links to the web view
| runtime, and calls the APIs directly to setup the window. WebUI
| finds a browser installed or already running, and launches it
| to a localhost server hosting custom content.
| lloydjones wrote:
| FYI: The website (webui.me) has a TLS / certificate issue and can
| only be viewed in Chrome (iPhone) after accepting the unsafe
| warning.
| hdaz0017 wrote:
| Cert expired -- Sunday, 24 December 2023 at 23:07:23
| sdkgames wrote:
| If I understand correctly, it's WebSocket on top of Embedded
| C/C++ web server (civetweb).
|
| Also, the application must find and launch the installed browser.
| In my opinion, this part is very fragile. On my system, this
| function (webui/src/webui.c) : static bool
| _webui_browser_exist(_webui_window_t * win, size_t browser);
|
| cannot find my browser.
| TheRealPomax wrote:
| Do you have "open URLs with a browswer" turned off in your OS?
| Because that's the universal way to open "whatever the user has
| set as their default browser".
| Gys wrote:
| The default browser on MacOS is often safari, which is not
| supported (yet) according to the docs.
| sdkgames wrote:
| > Do you have "open URLs with a browswer" turned off in your
| OS?
|
| But the application works differently. It needs the browser
| in kiosk mode, which means it should be able to run the
| browser binary with specific arguments.
| synergy20 wrote:
| civetweb will run cross platform as a http server.
|
| the issue is when you need write code on each OS, e.g. a cgi
| for windows/macos/linux/bsd, you will have to know the native
| API for each OS and use them, which could be hard to maintain
| if cross-platform is a must.
|
| I wish there is something lower level that is truly cross
| platform, e.g. a C library runs on each OS and let me do
| filesystem/network/etc, it does not seem exist.
| d3w4s9 wrote:
| Once your application is complex and reactive enough, has a
| certain amount of JavaScript code and gets used by enough people,
| you will inevitably run into compatibility issues. Then you
| realize you cannot just rely on a random browser version on any
| platform and think a minimum wrapper works well. That's why
| Electron bundles a browser and people create applications
| targeting specific Electron versions.
| synergy20 wrote:
| very true, which is why Electronjs still prevails in practice.
|
| In the meantime if your WEBUI is not complex, and you just use
| the common features that all browsers have, this approach might
| work fine.
| Xeamek wrote:
| I've never worked on big enough project to hit such issues.
|
| Could you provide some examples?
|
| Not that I doubt your claims, just curious
| codelikeawolf wrote:
| I can provide an example. I work on spaceflight mission
| planning software that runs in Electron. We're using a lot of
| cutting edge Web APIs like WebGPU, SharedWorker,
| OffscreenCanvas, and Atomics. There's no way we would be able
| to ship something that would reliably work cross-platform if
| we used the OS's webview or whichever browser they prefer.
|
| There's other considerations as well. The biggest advantage
| Electron provides over other libs that use OS webview (e.g.
| Tauri) is I can use whichever newer features I want (e.g. CSS
| nesting) as long as they're supported by whichever version of
| Chrome Electron ships with.
|
| That being said, I get why Electron gets a lot of hate. I've
| been developing Electron apps professionally for the last 4
| years. I can't use VS Code because I'm _accutely_ aware that
| it's Electron. I think 80% of Electron apps in the wild
| should probably just run in the browser. If you don't need to
| do stuff like access the filesystem, spawn processes, or
| interact with the OS in a way that the browser doesn't
| provide, you should probably just stick with the web app.
| Xeamek wrote:
| Fair example, although from what You are saying it looks
| more like its about using features that might not _yet_ be
| available in os webview.
|
| But the parent post, as well as 'other stories' I see
| sometimes talk about using certain, 'frozen', older version
| to ensure compatibility, essentially stating that new
| releases break some stuff. So i was more asking about such
| cases
| shellcoders wrote:
| I don't think the difference between Electron and Webui is
| the JavaScript thing you are talking about because Electron
| uses a bounded Chromium browser. Webui uses any installed
| web browser, so both are the same.
|
| True differences:
|
| 1 - The big difference is that the Electron backend is ONLY
| JavaScript, while Webui can be used with any language, C,
| C++, JavaScript, Zig, Nim, V, Python, Go...
|
| 2 - Electron is big, yes, +100MB, but gives you complete
| control of the window, while Webui is 200Kb, but all it
| does is run a web browser for you and sends you click
| events, so you have no control over the window because the
| browser owns it, not your application. So, Webui is
| suitable only for quick software development, while "big"
| projects should use Electron.
|
| 3 - Any suggestions?
| StevePerkins wrote:
| > _I work on spaceflight mission planning software..._
|
| Yeahhhhhh. The thing is, though, I see two classes of
| desktop GUI applications:
|
| 1. The kind that are simple and casual enough to build
| around a web-based framework. In which case, I'd rather
| rely on the system native browser rather than ship my own
| entire browser in my distributable. Because I'm not doing
| anything complex enough to worry about cross-compatibility
| issues, and I'm not concerned about people running my
| executable 10 years in the future with zero updates.
|
| 2. The kind which don't fit the criteria above, and
| therefore really just ought to be honest-to-God native
| desktop GUI applications. I'm rather astounded that
| spaceflight mission planning software doesn't fall under
| this category. Do you REALLY care about supporting Windows,
| Mac, and Linux targets? If so, then... why? I would assume
| that spaceflight would be dramatically more locked-down and
| spec-targeted. If you do not care about cross-plat, then
| what's the point of eschewing native frameworks since
| that's the main reason people go with web-based?
| Fire-Dragon-DoL wrote:
| Most of electron apps have compatible website version.
|
| A website has the same problem as non electron: the browser is
| always different, so this doesn't seem that dramatic as a
| downside
| TheRealPomax wrote:
| It's not confidence-inspiring that https://webui.me throws
| security warnings. I'd want folks to make applications "that make
| applications" to take security a little more seriously.
| shellcoders wrote:
| Yesterday the website was down, now is up !!
| Fire-Dragon-DoL wrote:
| This seems amazing, there is another similar project called tauri
| but it uses webgtk, which has its rough edges. Something
| integrated in the user preferred browser sounds amazing.
|
| Is there any plan for mobile?
|
| Does it open the user default browser with all extensions loaded?
| rco8786 wrote:
| What am I missing here? Web browsers are already GUIs, and any
| backend with an api supports it.
| windmark wrote:
| Reading the "How Does it Work?" section of the readme, I
| interpret it as WebUI being a way of embedding a web view into
| your existing program, being a sort of proxy for the existing
| browser of the system.
|
| https://github.com/webui-dev/webui#how-does-it-work
| samspenc wrote:
| Don't frameworks like Electron (and Tauri) already allow us
| to do this today?
|
| I couldn't tell from their docs what makes their project
| unique compared to these existing and more popular solutions.
| Turing_Machine wrote:
| Electron bundles a full installation of Chrome into _every
| application_.
|
| WebUI uses whatever browser (or browser component) is
| already present on your system.
|
| That's a big difference!
| orenlindsey wrote:
| This seems like way too much work when people have been doing
| things like this in different ways for years (just look at
| Replit, it runs a full IDE and runs on 4gb Chromebooks).
|
| Maybe I'm misunderstanding this project, but you don't have to
| reinvent the wheel.
| maybeezuuuyy wrote:
| Can't wait for someone to reinvent java applets or flash and we
| will have gone full circle.
| apatheticonion wrote:
| I wish that Apple and Microsoft would work together towards
| making it easier for people to make cross platform desktop
| applications.
|
| It's largely uneconomical for most companies to develop and
| maintain separate apps using two different teams with minimally
| interchangeable skills.
|
| Tools like Electron are, essentially, not a choice
|
| I also wish that wasm would come sooner so we could have more
| memory and CPU efficient (threaded, statically compiled) web
| applications (for apps like Slack, messengers, Jira and so
| forth).
|
| I know people keep saying "wasm is not a replacement for
| JavaScript" - but perhaps it could be an alternative. I know I'd
| like to write a web application in Rust but as it stands now
| there is little advantage to that, particularly without threads
| and DOM access.
| 38 wrote:
| > Tools like Electron are, essentially, not a choice
|
| yeah, they really are. people seem to forget that you can
| simply start a local web server, and direct the user to visit
| http://localhost:8080. here is one in Go, literally 8 lines of
| code: package main import "net/http"
| func main() { http.HandleFunc("/", func(w
| http.ResponseWriter, _ *http.Request) {
| w.Write([]byte("hello world")) })
| http.ListenAndServe(":8080", nil) }
| blululu wrote:
| This is serious? Generally your app should aspire to having a
| better user experience than a low end phishing scam. Normal
| people really don't want to copy/paste a series of random
| looking computery numbers from one application into their web
| browser. At best it feels broken and more likely it feels
| like you are about to get hacked.
| hit8run wrote:
| Isn't that what Flutter is solving?
| nanaian wrote:
| Wasm threads via SharedArrayBuffer have been a thing for like 5
| years. In Rust you can use wasm-bindgen-rayon, for instance.
| DOM access is and has always been easily achieved through
| imports. It's performant, too: https://youtu.be/4KtotxNAwME
| apatheticonion wrote:
| It's __doable__ but I can't yet in earnest recommend it for a
| serious project (outside of canvas controlled GUIs).
|
| The SharedArrayBuffer implementation requires spawning the
| same wasm module multiple times and passing the SAB to each
| instance. This works but is no replacement for thread
| management by the module/process itself.
|
| It also requires restrictive "Cross-Origin-Opener-Policy" and
| "Cross-Origin-Embedder-Policy" headers - making it largely
| impossible for applications with multiple subdomains (for
| instance apps that have their API on api.myapp.com, or assets
| on cdn.myapp.com). Not an easy change for an established
| enterprise application.
|
| Glue code might be performant but I really just want to go
|
| > cargo build --target wasm
|
| and
|
| > <script src="app.wasm" type="application/wasm"></script>
| armchairhacker wrote:
| We have good cross-platform desktop UI solutions: Java
| Swing/JavaFX, C++ GTK/Qt/wxWidgets, Rust egui/iced/Slint, and
| of course HTML/CSS/JS Electron/Sciter.
|
| The problem is that cross-platform UI will never look as well
| as native UI because it's not native UI: control sizes are
| different, colors and elements don't blend the same way, and
| some things (like menu bars) are completely different in mac,
| Windows, and Linux. It's not a slowness issue (if your UI isn't
| responsive on today's computers, you're doing something very
| wrong), it's not a usability issue, it's not even an appearance
| issue (even Java UI can be made to look OK fairly easily in
| embedded systems). It's an "I'm accustomed to native UIs and
| everything else is native UI, so any non-native UI looks out of
| place" issue.
| squarefoot wrote:
| Technically interesting, but no thanks. Imagine a Firefox user
| downloading the latest LibreOffice and being greeted with the
| warning "Better run through Chrome", or writing a dashboard on a
| small embedded system, and the memory footprint goes like 20x
| because now you need a browser in between in place of native
| controls. The idea is interesting but there are so many caveats,
| and the industry is famous for choosing the simplest and cheapest
| development methods rather than the most efficient ones.
| petabyt wrote:
| This is a replacement for electron/tauri, and should be able to
| use much less RAM
| petabyt wrote:
| I did a basic C demo where I compared this to Tauri/webview:
| https://github.com/petabyt/webui-demo I'm not planning to make
| any apps in HTML/CSS, but if I had to, WebUI would be my choice.
___________________________________________________________________
(page generated 2024-01-01 23:00 UTC)