301–310 of 326 posts
This is encouraging. An Electron competitor would be really nice. I'd be especially interested in an Electron-but-for-Python, along the lines of PythonWebkit: https://www.gnu.org/software/pythonwebkit/
Just write your application in Django and start the local browser. Use Web APIs to trigger interactions with native APIs from Python code.
Earlier quoted context omitted.
The rust electron competitor is already here https://tauri.studio/en/
Interesting project as they seem to be tackling the same problem as the Flutter team whom started with mobile and are steadily working their way up the stack. Though it should be said repurposing a desktop first framework for a mobile paradigm is much harder than the inverse. Cheers for this. Definitely keeping tabs on the project.
The problem is the ecosystem is small. If your use case doesn't fit their widgets, you have to do a lot of workaround stuff.
Although this app stands out as a success in my mind: https://fluffychat.im/en/
Earlier quoted context omitted.
The latter would be better, imo. Chromium won because it introduced a sane API before Mozilla's Gecko. That's why you see so many Electron apps. Seriously, we don't need to wrap a whole browser. Just the engine and a debugger would've been fine. The engine could be distributed as a lib and other frameworks could just bind it. Apps could be distributed without an 150MB behemoth just to have a chat client. Making the e…
I'm not sure what you mean by 'an engine', but people who choose Electron typically don't want a rendering engine like Servo, they want to write a web app and have it installed locally. They need a rendering engine, a JS runtime, a DOM handler, an HTTP client library, WebSockets support etc - they want a whole browser. Also, 150MB is not really that scary of a size in today's world. Also, a huge part of it is simply…
Earlier quoted context omitted.
So pocket in no way detracts from your privacy. It's an very useful feature to many people. It's fine if you don't like it, but to use the privacy argument against it is incredibly disingenuous. Edit: Also, you understand incorrectly about safe browsing. It does its checks locally.
I never claimed pocket detracted from privacy. I actually explained my problem with pocket... To add to that, it shouldn't be embedded in the browser. It's an extension and they have a marketplace for that. And even if Safe Browsing does do what you say, the other google stuff still does and did exist.
Even if you're backing down from that statement, why should it be an extension? why should they remove a popular feature and source of income just because you don't like it?
Yes Firefox will perform Google searches or location requests if you ask it to. It doesn't if you don't.
Earlier quoted context omitted.
Hmmm Well, I'm not in the business, but if the team was disbanded, then where's the knowledge gone and who will be the next paid team ? I ask because I guess Servo is not the kind of project you just commit some patch over the weekend...
Honestly the project has had >1000 contributors over the past 8 years and a lot of them did just that.
Edit: It's clear to me Servo is vaporware right now. The discussions in this thread and crawling servo.org make that abundantly clear. Original post: As an embedder, I just don't get the point. Servo is a nonstarter. The idea of Servo minus Rust is great, because most embedders don't use Rust. They use C, because C is easy to embed with, and the availability of FFIs across languages that interface with C is tremendou…
Servo is a WIP. Some components are mature, and have actually been merged into firefox. Embedding is a primary aim, but certainly requires a lot of wrapping at present to be as functional as more mature engines. No doubt it would be nice to have an easily portable lib - maybe with a compatible interface to other engines - but its certainly not there yet. I agree that the project could/should be a bit clearer on its c…
Earlier quoted context omitted.
Servo is a WIP. Some components are mature, and have actually been merged into firefox. Embedding is a primary aim, but certainly requires a lot of wrapping at present to be as functional as more mature engines. No doubt it would be nice to have an easily portable lib - maybe with a compatible interface to other engines - but its certainly not there yet. I agree that the project could/should be a bit clearer on its c…
Servo has been around for 8 years. If embedding was a primary aim, which it clearly isn’t, you’d start with that first, and enjoy spec compliance updates as they came.
I’m really not understanding your hate. Servo is a WIP. If you don’t have the time/skills to embed it in its current state, then don’t! But it’s still embeddable :)
I am confused. I thought it is the raison d'être of Mozilla to develop a browser. So how does it come that the brand new browser engine they developed is being given away? I mean, even if they need to cut costs, isn't Servo part of the team they should keep until the end?
A lot of people misunderstand what Servo was. It was for developing components that could be integrated into a browser. Firefox integrated most of those and continues to develop more code in Rust. Servo lost it's use.
By niche I mean the myriad of keyboard driven browsers. kiosks, QML, electron, etc.
Earlier quoted context omitted.
They aren't mutually exclusive. WebKit was originally based on KHTML, but Apple still founded WebKit and controls its source code. Even if WebKit was just Apple's name for their internal fork of KHTML, I don't see any reason they'd retire it. Blink was originally spun-out of WebKit too. Similarly, Google controls Blink, and the two have diverged significantly in the intervening years. I suspect patches for any of the…
> Apple still founded WebKit > Blink was originally spun-out of WebKit too Founded, spun out of, forked... What's in the name? I think one cannot "found" something that's largely based on a fork of something else.