- nicoburnsIt's syntactically free, but it can cause borrow-checker errors thst cause your code to outright fail to compile.
- They are indeed just a subset of WPT. Although the way subtests are weighted in the score calcustion is slightly different for the "interop" score.
- Apple's Preview is my favourite. It uses AI to allow you to copy text from images. And that's it.
- If you don't trust the AI generated code yourself, then you wont benefit from it. And in fact all it does is take resources from the project that you work on, the one that's generating all the value in the first place.
There are strong parallels to the image generation models that generate images in the style of studio ghibli films. Does that benefit studio ghibli? I'd argue not. And if we're not careful, it will to undermine the business model that produced the artwork in the first place (which the AI is not currently capable of doing).
- It does, but it's mostly for coordinating development rather than a consumer facing product. Personally I'm not convinced Mozilla IM would make sense though. It's a crowded msrket with lots of other options.
- Isnt the actual proof checking what your traditional formal verification tool does? I would have thought that 99% of the work of formal verification would be writing the spec and verifying that it correctly models the problem you are trying to model.
- Are you talking about https://flow-browser.com ? I wasn't aware of this project before, but it appears to a new chromium based browser.
The Flow people are talking about when they talk about Ladybird and Servo is https://www.ekioh.com/flow-browser/ which does have it's own engine. It has a similar level of standards compliance to Servo and Ladybird, although it's not open source which puts it in a somewhat different category.
- Not sure about python, but https://docs.rs/usvg in Rust is pretty good
- OpenStreetMap-based maps tend to be much better in this regard. Although this is counterbalanced by the fact that they tend to have less data on businesses in general.
- On the other hand, I would never ever consider a traditional motocycle (partly becuase they are so noisy). But an EV one is very appealing. Exactly because it's more efficient and practical.
- I'm not sure I get the joke, but the project reference is interesting - thanks!
- While it might be possible to get the performance required for a web rendering engine out of Java, I think you'd miserable writing Java in the style you'd need to get that kind of performance. And you'd likely still end up with issues around memory usage, app bundle size (remember that browsers ship to client devices), GC pauses, and integrating with the JavaScript engine.
- > It creates robust, complex systems that work
Do you have any examples of these? All the vibe coded systems I've seen so far were very far from robust.
- It looks like HTML may be getting the ability to manipulate the class/attributes of elements in response to clicks (declaratively, without JS). Which would solve a lot of the interactivity issues (checkbox hack, etc).
See: https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com...
- I believe it's a soft fork where they're treating Iced as upstream. Having their own fork just means they can land changes quicker.
- I don't think that works if you want to mix "proportion of available space" units with siblings that have a fixed size (a super-common use case for flexbox - having a fixed size box followed by another box that takes up "the rest of the space").
- It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).
These are also the kind of cases where CSS layout ends up being slow. But a constraint solver based layout gives you more power to shoot yourself in the foot with.
> but that doing more complex layout requires more computation.
It's exactly this. The question is whether that makes for an ergonomic system to use for the developer. My assertion is that if there is no feedback when you create a slow layout, then it is not actually an easy system to use, and you're better off with something more constrained that guides you into the pit of success.
- My understanding is that constraint based layout performance is heavily dependant on providing lots of constraints so that the solver doesn't have too much work to do. But that the reason people like constraint-based layout models is that they don't have to provide many constraints.
Couple those together and you get poor performance. Or more specifically, unpredictable performance with lots of performance pitfalls that are hard to debug. Apple's AutoLayout is the real-world case study for this.
- The problem with a constraint system is that it would likely be even more subject to performance problems than the current setup.
IMO what CSS layout really needs is:
1. A "proportion of available space" unit. That is, something like the fr unit in CSS grid except applicable to the width/height properties so it can be used in all layout modes and without an implying content-based minimum size (like fr does).
2. A new "display: stack" (name provisional) layout mode that simply stacks boxes one after the other like "display: block" but that works in both axes, and doesn't have quirks of block layout (margin-collapsing, floats, inline-block splitting, etc).
When combining 1 and 2 you'd have a much more intutive layout system that would still give you most of the power of Flexbox and could be implemented with much better performance.
(and you'd still be able to use the existing layout modes if/when you needed to extra power)
- RAII doesn't necessarily require allocation?