41–50 of 187 posts
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);
Earlier quoted context omitted.
What method do you propose to compare the performance of different programming languages?
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
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.
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 i…
Earlier quoted context omitted.
Synthetic benchmarks for some algorithms have little to do with actual performance of real life applications
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
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
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.
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.
Earlier quoted context omitted.
> 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…
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 proj…
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.
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.
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.