So, Blitz should be a pretty ideal fit for that, right? Can it run in headless mode and save a screenshot currently?
Its happy path is typesetting via HTML/CSS, but it may fit your use case as well.
HTML feels quite complicated, and also it was not designed for dynamic rendering.
I like lean and kiss, and html doesn't feel like it's lean or simple enough for me.
*gestures vaguely at Gemini*
(serious question, because I too want that simpler, lighter version of the web).
In fact, if I was trying to build "markdown over http" I'd start with the JS library. Skip the native browser application entirely.
Web Assembly, for example, is pretty pointless if browsers don’t support it. Browsers now support it, so it can be used, and that’s slowly happening.
It seems like the new document standard would need to be written, the benefits would need to be demonstrated, to the point support is integrated into the mainstream browsers, and then people who see benefit from the (I assume) easier/faster/better development, can start using it for new projects or integrating it into existing projects.
Trying to make an entirely new internet based on a new document standard would be rough. At this point, I don’t see that as a way forward, unless it brings something extremely compelling that users want and go crazy for, which can’t be duplicated with existing technology. I’m thinking Napster levels of hype and consumer desire.
How feasible this is in practice remains to be. I'd be interested to see/hear what your vision would look like.
https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
If the web primatives where WebHID + WebGPU every site would lack any of these.
Of course this would come from the Flutter people who don't seem to care about this. Flutter on web is completely unusable and often Android and desktop versions are barely tolerable.
> The parts of the web that have actually delivered are the ephemerality and the security model, the indexability (but only for content, not apps), deep linkability, and the platform-independence. We can keep all those, and throw out the decades of legacy that's holding us back, and we will lose nothing, we will only gain as we unleash the kinds of amazing interfaces that developers can build when you give them the raw bedrock APIs that other platforms already give their developers.
I also have to admit I simply don’t—can’t—trust a proposal to make the (path of least resistance of the) Web less inspectable when it comes from the general direction of Google, even when it’s honest-to-goodness Hixie writing one upon evidently deep reflection; the same way I don’t trust a proposal to make a compiler toolchain collect user data by default when it comes from that direction, even when it’s honest-to-goodness Russ Cox writing one upon evidently deep reflection.
(In the case of Go telemetry, I still remember how Cox responded to a privacy-related question I raised on HN—but don’t even remember now—by proposing the organization maintain an anonymizing proxy for its many employees. Which was a fairly satisfactory solution, if you’re an organization and have many employees. And it seemed clear his mind had no other cases in its working set. Maybe it’s just something in the air there.)
I don’t mean to pass judgment here, to be clear. Hixie in particular has done more to improve the open Web than most people whose explicit job it was to improve the open Web, let alone web programmers, let alone programmers in general (the only cohort of those to which I can lay even a vague claim of membership). I don’t even mean that my upfront bias here is correct or should be emulated by anybody.
I only mean to warn you that I’m just unable to engage with the proposal without considering its source, most of all emotionally, so you should keep that in mind when I say it and its apparent excitement feel bleak, like a coat of bright paint on a rusty playground slide in the midst of a concrete Constructivist slum.
He also left Google yet still maintains his stance in the article, to my knowledge, if that's any consolation to you that he's not necessarily thinking about the topic from a Google lens, at least, not anymore.
It's an entirely new stack for apps unlike what the web is. Maybe that can be good for developers, maybe, perhaps, but gee it sure seems like a really bad bargain for users, user agency, and the technical legibility of our online world.
The HTML/CSS web isn't some panacea for extensions. The code is minimized to the point of being obfuscated, and JavaScript engines provide almost no introspection into frames or closures. After-the-fact extending these apps is hard.
I would very honestly rather be sitting around in someone else's Flutter app with the goal of making some extension modification to the behavior than in someone's crazy DOM-based app, as at least the rules are clearer.
As it stands, though, HTML/CSS are just too complex. I could--probably alone, but certainly with a small team--build a browser that worked fully if the spec were something like WebAssembly connected directly to something like WebGPU.
The idea of a monopoly on browsers at that point would be laughable: we'd have a hundred of them, made by every company of any decent size, embedded into everything, and that spec would be both stable and would matter.
As it stands, we have like 2.5 web browsers at best, and I'm betting we are going to be down to 1.75 or so in the not-so-distant future. And yet, we continue to make the web MORE complicated to implement, which is simply demoralizing.
We can't even build a partial / limited browser renderer anymore, as progressive enhancement is dead now: if you don't support the full set of features then you'll run into modern React sites just giving up and showing a blank screen: even a browser that was fully capable just a few years ago is now dead in the water as it won't have all the crazy new CSS and JavaScript features you need.
And, why are we making this so hard? Because we think that the web is somehow more transparent than even a native app? It really isn't. There is a reason why we had tons of really invasive app behavior extensions for iOS and you almost never see anything integrated when it comes to web extensions: it is because the web's programming model is actually much more difficult to introspect and modify for anything other than superficial styling or wedged-in buttons that add mostly tacked-on behaviors.
There was someone recently on HN who went and added some feature to Gmail as an extension, and they seriously just bring up their own pane and require the user to have Oauth tokens for Gmail from their app, and the reason was because it is just too difficult to reach into Gmail and massively modify its behavior... but we would do that sort of thing on iOS all the time and it was not just easy, it was fun! Maybe a browser could be built that would give users the same kind of extension ability for the web--by ripping through all of the layers of JavaScript scope optimizations--but no one is going to ever build that as building a browser at all is an impossible task :/.
The documents are already out there
You can probably carve out a subset of CSS that's relevant - greatly simplifying your life
da fuq
2. We hope that by building a modular solution we might be able to lower the barrier to entry for building browser-like software.
3. We're a lot smaller. Servo is 100mb+. Blitz is 20mb out of the box. Potentially as small as 3.5 mb with optimizations.
4. We want to be a lot more customizable. Want to add your own layout algorithms? Image formats? Build your own native widgets with custom painting and accessibility? Fit into your existing render backend? Then we want that to be possible. Don't want SVG support? or AVIF support? Or network support? Or Float support? Then you should be able to disable it and not pay the cost for it.
5. We want our components to be usable in other contexts. For example Taffy, our layout library is used in several GUI frameworks. Many of our other dependencies are also generally usable.
We looked at using Servo's layout support. But it isn't really designed to be used standalone (although it could be if that was prioritized!). And we'll probably add a Webrender rendering backend at some point (Blitz is designed to have pluggable renderers).
There will always be exceptions like your case. However it is clearly the case that there aren’t hundreds of different types of gut fungi which grow out of control over a dysbiosis occurs in the guts microbiome. There is generally one type and it is called Candida. The problem is called a Candida overgrowth. Candida generally eats carbohydrates and sugar. A carnivore diet will generally starve it and cause a die off. The Candida generally released toxins that cause auto immune disorders.
Now I’m speaking in the cases of most not all people who experience auto immune disorders and where those disorders are caused by the guts microbiome.
There are also the cases where the gut has been damaged by gluten and other plant materials and is leaking food into the blood.
As far as I’m aware no animal flesh of any type does such damage to the gut. No fungi eats animal flesh.
You seem to think gut dysbiosis is one bacteria dominating others. No. It is a fungus in most cases. A single called yeast that rapidly duplicates called Candida and eats plants.
Unscientific only because the science is behind
We're building upon https://github.com/AccessKit/accesskit which provides a cross-platform abstraction over the OS accessibility APIs.
It's kind like most CLI programs nowadays don't come with a man page (nor an info page) and think that an autogenerated `--help` is enough. Except that nobody is excluded from using your application just because it doesn't come with proper documentation
Personally I am interested in how engines like Blitz, Servo, et al could be built in the future using formal methods practices. For example, start with definitions and generate part of the system. Nowadays, this includes LLM but I see them more like great tools than AI systems. Also things like Z3 comes to my mind.
BTW, some of my companies has a research branch on things like this.
I build Wootzapp (https://github.com/wootzapp/wootz-browser) - we are kind of like Robinhood for data labeling. people can spend time labeling web data/images, etc in the browser and earn. Right now we are based on Chromium. Wondering if Blitz is looking to be the pluggable renderer for other browsers.
P.S. we are on the mobile (android today and ios tomorrow).
- Application UIs
- High-fidelity markdown previewing
- Perhaps PDF rendering, etc.
- Embedding web content within a wider system in an integrated way.
Etc.
It would be very cool if someone wanted to add actual JS scripting and DOM APis on top though.
For a UI engine for native applications, it seems like a sensible strategy: use a layout language that developers are likely to already be familiar with.
Hopefully, in the longer term, there will also be a Blitz-TML library with higher-level UI components as well.
Good luck with this. It looks interesting.
One thing to note is it's not quite ready yet:
- The text input and focus system are pretty basic
- We don't support scrolling (other than the root viewport)
- Complex CSS selectors like nth-child and :has aren't working correctly yet.
- Event handling integration with Dioxus (the React-like framework that sits on top of Blitz) isn't robust or fleshed out yet (only clicks work, there is no preventDefault)
- The currently networking is super-dumb and does synchronous requests on the main thread. We need proper async and/or multithreaded networking.
- We have put very little work into performance - we're currently recomputing style/layout/paint every frame.
- Relatedly: We have few dumb memory leaks where nodes are not cleaned up. We know where these are, we just haven't fixed them yet.
- Less critical, but things like shadows, web fonts, calc, float layout, and form controls other than text input are missing (see README for more).
All of these are basically a case of "building a webview is a big task, and we haven't gotten around to that yet". We're hoping to have something a bit more complete in 2-3 months time.
There are some more screenshots here:
https://github.com/DioxusLabs/blitz/issues/23