Earlier quoted context omitted.
I'm currently suffering the pains of developing a Tauri app that relies on the system WebView (which is the default for Tauri). It's unreliable (especially on Windows where people love to mess around and run "debloat" scripts), and causes slight differences on each platform. Tauri lets you bundle the WebView, but this causes the installer to grow like 150 MB. I presume this alternative would be a lot smaller.
After messing around with various cross platform desktop toolkits, including a big Electron app and some smaller Tauri apps, I've settled on Flutter. It's not perfect but the results I'm getting are so far much better than anything I was able to achieve using repurposed web tech.
Mozilla's abandoned web engine 'Servo' project is getting a reboot
101–110 of 140 posts
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#102Earlier quoted context omitted.
I can built a basic app with html, javascript, etc that supports many platforms in an evening. How long do you think it would take to support windows, macos, ios, android, xbox, linux, etc, etc? Much more than 50x the time even if you already are familiar with development on all the plaforms.
Qt covers 5 of the 6 platforms you named, and many more "etc". Yes it takes a bit more than a boot camp graduate to code that, and might take a bit more time still.
Your solution requires more dev time and skill - which makes it way more expensive. Basic economics.
The main requirement most devs and users have for an app - that it runs and works reliable. Not that it is the most efficient solution.
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#103Servo is a waste of time. If we want a fast rendering engine, Mozilla already has it. If we want a secure rendering engine we could leverage code checks. It's all there. The meme of Rust equals safety (or C equals I safety) has to go away.
Servo was about parallelism. Mozilla tried multiple times to parallelize CSS style calculation in Gecko which is written in C++, and failed all of them. When they tried again in Servo with Rust, they succeeded first time. They integrated Rust-written parallel CSS style calculation to Gecko. As a result, to this day, Firefox is the only web browser which can parallelize CSS style calculation, and beats every other bro…
So I think that the programming language as an underlying reason is most likely a wrong premise to start with. IMO there's a huge difference between "here's several MLOC with all of its 20-years legacy/baggage, and now make N% of that non-trivial work to run faster" and "here's a greenfield project with 0 LOC, no legacy and no baggage, no code to learn, and now please write the algorithm from the ground up". I think this is much more likely to be closer to the truth.
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#104Earlier quoted context omitted.
Qt covers 5 of the 6 platforms you named, and many more "etc". Yes it takes a bit more than a boot camp graduate to code that, and might take a bit more time still.
See? Your solution requires more dev time and skill - which makes it way more expensive. Basic economics. The main requirement most devs and users have for an app - that it runs and works reliable. Not that it is the most efficient solution.
It is everyone's responsibility to not make shit software.
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#105Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#106Earlier quoted context omitted.
Servo was about parallelism. Mozilla tried multiple times to parallelize CSS style calculation in Gecko which is written in C++, and failed all of them. When they tried again in Servo with Rust, they succeeded first time. They integrated Rust-written parallel CSS style calculation to Gecko. As a result, to this day, Firefox is the only web browser which can parallelize CSS style calculation, and beats every other bro…
I don't think this has anything to do with the language itself. If anything, you could claim the same for C++ since "easier to parallelize in Rust" is derived from the fact that Rust models pretty much everything as a shared-ptr so many gotchas you would normally have in multithreaded (but not concurrent) code disappear. Since you have the shared-ptrs in C++, you can achieve pretty much the same and also quite easily…
I agree that starting from scratch can make a huge difference, but if you're starting from scratch anyway why not use the language that will prevent you from making mistakes in your design?
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#107Earlier quoted context omitted.
I don't think this has anything to do with the language itself. If anything, you could claim the same for C++ since "easier to parallelize in Rust" is derived from the fact that Rust models pretty much everything as a shared-ptr so many gotchas you would normally have in multithreaded (but not concurrent) code disappear. Since you have the shared-ptrs in C++, you can achieve pretty much the same and also quite easily…
Rust doesn't model everything as a shared_ptr, it gives you a choice of tools that fit different use cases - just like C++ does. The difference is if you mess up, it is massively more likely to detect it at compile time. I agree that starting from scratch can make a huge difference, but if you're starting from scratch anyway why not use the language that will prevent you from making mistakes in your design?
Since those same mechanisms are available in C++, and other languages too, making an argument that some specific XYZ algorithm re-implementation from scratch was more successful only because it was written in Rust, doesn't hold water. It was successful, for the arbitrary definition of success, in its major part because it was a greenfield project.
I believe that suggesting otherwise is plain wrong and misleading.
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#108Earlier quoted context omitted.
Rust doesn't model everything as a shared_ptr, it gives you a choice of tools that fit different use cases - just like C++ does. The difference is if you mess up, it is massively more likely to detect it at compile time. I agree that starting from scratch can make a huge difference, but if you're starting from scratch anyway why not use the language that will prevent you from making mistakes in your design?
I did not mean "everything" in the broader context but in the context when it comes to writing "easy" multithreaded programs. Pretty much everything in that case becomes modeled through a shared-ownership or message-passing semantics. Since those same mechanisms are available in C++, and other languages too, making an argument that some specific XYZ algorithm re-implementation from scratch was more successful only be…
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#109Earlier quoted context omitted.
> Because your average Joe doesn't know the difference and the race to the bottom affects everyone. Would it be possible that the average Joe is more familiar with a web stack vs a native or cross platform desktop stack? Is it not possible that the difference therefore might be between: - having a questionably performing app built on web technologies - vs a buggy one that's built on a native/cross-platform stack, or…
Your notion that browser-based apps are somehow bug-free is absurd. Skype on Linux, for one, keeps the microphone open after a call, forever. The issue has been known for more than 2 years. I'd say Electron adds no value with respect to fighting bugs other than containing the consequences in the browser sandbox.
My notion is that more people are familiar with using the web stack, than any other alternative.
Out of curiosity, I perused some local job boards: out of about 50 technical role ads that I looked through, 4 were embedded or desktop development, there were some DevOps and ML related roles in the middle, but the majority were web development.
If that's the set of technologies and the languages that people are familiar with (high abstraction level, no manual memory management), then attempting to use these "performant" options obviously wouldn't turn out well, due to a lack of skill, familiarity and/or user experience of that tooling.
I mean, in an ideal world, GUI software would be even easier to create than using Lazarus was back in the day (the RAD approach), but sadly the greatness that was lcl is mostly lost to time because nobody cares: https://en.wikipedia.org/wiki/Lazarus_Component_Library
Re: Mozilla's abandoned web engine 'Servo' project is getting a reboot
#110Earlier quoted context omitted.
I did not mean "everything" in the broader context but in the context when it comes to writing "easy" multithreaded programs. Pretty much everything in that case becomes modeled through a shared-ownership or message-passing semantics. Since those same mechanisms are available in C++, and other languages too, making an argument that some specific XYZ algorithm re-implementation from scratch was more successful only be…
You might be right, but you're stating this without any evidence, so I don't think it's clearly "wrong or misleading". There are many cases of software rewrites failing, so I'm not sure you can take for granted that "greenfield project" implies higher success rate, and even if you did, I don't see how you can judge how much of this was due to it being rewritten from scratch vs that it was in Rust to claim "major part…