271–280 of 343 posts
Earlier quoted context omitted.
HTML and CSS is the worst layout system except all others. But actually, HTML and CSS is pretty good considering the problems is solves.
> HTML and CSS is pretty good considering the problems is solves. Agreed: pretty good. Shouldn't we pursue excellence?
Alternate layout engines for the web might be a fun experiment, PhD thesis, or talent retention program, but it's not practical.
Earlier quoted context omitted.
> I hope in the process of doing it we will find new ways of doing things. HTML & CSS themselves have become a major bottleneck to quality and creativity. The arcane layout model, the baggage of backwards compatibility, the cognitive dissonance — played out over decades of design-by-committee — between "this is a document engine" and "this is an app engine." The rendering-thread-is-the-main-thread architecture of JS…
Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? Don't get me wrong, I also could imagine better markup languages for that purpose. But everything I have seen in the wild was worse in multiple, show-stopping ways. Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and put the solutions into CSS4 and HTML6
For interactive interfaces, I think it's not very good.
This page speaks to a different approach (I'm the author) https://skinnyjames.codeberg.page/hokusai/concepts/layouting...
Earlier quoted context omitted.
They said some of the code can be rewritten in Rust but majority of the code cannot. Therefore they are stuck with C++ forever. Scary thing to think about.
Also scary for Rust.
Earlier quoted context omitted.
> HTML and CSS is pretty good considering the problems is solves. Agreed: pretty good. Shouldn't we pursue excellence?
I think CSS is excellent and pragmatic. Alternate layout engines for the web might be a fun experiment, PhD thesis, or talent retention program, but it's not practical.
Flexbox was once an "alternate layout engine for the web," as was Flash player, as is Figma. Framer, Retool, and Squarespace all offer alternate layout engines tailored for visual building. All of these seem practical to me.
Earlier quoted context omitted.
Oh, yet another ActiveX.
Closer to "yet another Flash," but 100% open source, and no browser plugin thanks to WebAssembly
Use those same great adobe tools in a vm.
Earlier quoted context omitted.
> Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? HTML/CSS is pretty good! SwiftUI's HStack and VStack are solid, though they suffer from ambient API complexity & Conway's law.[0] Figma's autolayout is a strong reference, but it's not a tool for creating software. > Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and…
Isn't Figma's "auto layout" just a GUI for a canvas-based implementation of flexbox? Likewise, HStack and VStack are ports of flexbox to SwiftUI.
None of these is a perfect technology, but I believe the most practical answer to the question driving this thread[0] is to study/understand the landscape, then build towards a better future.[1]
[0] > Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces?
[1] www.pax.dev
Earlier quoted context omitted.
FWIW Ladybird is also built by people with actual browser engine experience
Ladybird was mostly developed by one person (Andreas Kilng) with no financing whatsoever ,Servo was mostly developed by a team who was being paid with Mozilla money.
Earlier quoted context omitted.
Xcode 16 rewrote much of the autocomplete behaviors and the new engine is blazing fast in terms of UI blockage compared with 15, and stable. Everything to do with tagging etc not just completion itself.
I don't know if this is irony or you've been in Apple ecosystem way too long. I had to do a very simple macOS app for my personal consumption recently and XCode dx is nothing to write home about. The only reason I finished the project there was that I couldn't set up vs code quickly for Swift/Cocoa project. I had to endure the slow compilation time, slow reaction time of the IDE UI. You make a change you keep seeing…
Earlier quoted context omitted.
Xcode 16 rewrote much of the autocomplete behaviors and the new engine is blazing fast in terms of UI blockage compared with 15, and stable. Everything to do with tagging etc not just completion itself.
Can you get the profiler to do anything useful? Even comprehensible? We tried and tried but there was nothing we could use amongst the blinking lights and wonderful graphics.