HTML was a huge advancement, but it is likely a local maximum.
The HTML / CSS stack comes with significant ergonomic hurdles (layout / positioning / "creative fidelity") and performance hurdles (inescapable GC pauses, constant overhead of constraint-solving layout system, DOM overhead in general.)
Can we do better? IMO the future GUI lingua franca is deeply inspired by HTML and will stand on the shoulders of that giant, but will:
- Build to LLVM native apps as well as websites
- Include React-style templating as a foundational concern
- Be fundamentally designed for visual building (think of the ergonomic differences between Webflow & Figma — if "an HTML" existed that "a Figma" could read & write natively, building front-ends would take a quantum leap)
WebAssembly makes all of this possible while still extending the Web and browser ecosystems.
Pax renders vector graphics to canvas layers and composites + clips + occludes native elements (web DOM nodes, iOS SwiftUI Text elements, etc.) in the same space to make a cohesive scene.
This solves accessibility and SEO, as well as dramatically reducing runtime size (~100KB WASM network footprint) because text rendering and atomic native UI elements don't need to be reinvented.
To my knowledge we're the only ones taking this particular approach so far (I'm on the team behind Pax) but it works quite well. Yes it was a lot of work.
Structure determines behavior. If a technology structurally encourages shooting oneself in the foot, people will shoot themselves in the feet.
The author seems to be arguing the the core problem is behavior — if only developers would stop building flimsy things! But what about a structural view? Is there a certain structure that lends HTML, CSS, and JS to creating frustrating experiences?
The structural heart of this problem is so big it's hard to see — it's the ground we stand on. The designed-by-committee dissonance between "the Web should be a simple document engine" and "the Web should be a game-engine-like interactive graphical runtime" leaves us with a bloated tech stack that doesn't excel at either.
WebAssembly and WebGPU give us a way out. Fork HTML. Employ a better language for authoring documents; employ a better language for authoring apps & games. It is a matter of time.
I think the fact that "structure determines behavior" is true is exactly what it is he is lamenting about. The fact that a tool enables you to shoot yourself in the foot is never an excuse to shoot yourself in the foot. Knowing how not to shoot yourself in the foot with a powerful tool is one thing that separates amateurs from professionals, and you get to be a professional by caring.
That is not to say that work shouldn't be done on making tools which require less cognitive load to use professionally, but until that happens I feel there are too many opinions blaming the tools instead of taking on the responsibility required to use them correctly.
The problem is: you shouldn't have to be a professional to author Web software. Certainly I was not when I started tinkering with HTML & CSS in the 90s. The trend line is moving — in 10 years, it's likely that billions of people will be able to create apps & websites. Should we hold all of those billions to a high bar of professional diligence? Not practical.
If a four-way stop intersection were missing one of its stop signs, a diligent driver would infer the missing stop sign and pass cautiously. We all agree that drivers should be diligent. In aggregate, anthropologically speaking, there would be accidents at that intersection. Rather than "scream into the wind" at every passing driver, a systemic solution is necessary.
Not that I would call most people to action to create a solution themselves — this particular problem is hard tech and a tremendous amount of work — but I do challenge people to be open to a better future. With such future in mind, "screaming at passing cars" feels like a battle against the wrong enemy.
1. Rust is growing in popularity, and a compelling GUI solution is needed
2. These solutions take significant time to incubate, so many of the ones we're seeing emerge have been incubating for months or years, started at a time when there were fewer options.
3. The implications for cross-platform app development with Rust are profound, and offer us a way to break free from the pain-points and shortcomings of the local maximum solutions du jour: Web + Electron and Phonegap-style WebView mobile apps.
I'm not sure this is the prevailing opinion. It may be something of a "vocal minority" opinion, but it does seem more common in the Rust community than elsewhere. The closer you get to traditional native app designers and developers, the more you'll hear the opinion that native look & feel (not to mention accessibility) is important to embrace.
IMO an ideal solution is to offer both: 1. to wrap native toolkits for things like text and UI controls, and 2. to enable canvas-drawn virtual controls, for those who would prefer to create their own widgets. These approaches can be enabled in parallel through an extensible widget/component system.
Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web.
This approach also enables a lean runtime footprint (<100Kb, particularly useful when targeting Web) because the runtime doesn't need to reinvent text rendering, selection, input, etc.
Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode:
1. Conditional templating, like:
<SomeLayout>
if $is_android {
//Only render the back button for Android
<BackButton />
}
/* ... */
</SomeLayout>
2. Dynamic properties where Rust logic checks for the target platform, like:
Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?
Pax's Android chassis isn't built yet — but a Pax `<Button>` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs.
That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `<Button>` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.
This "dual layer" approach is already implemented for Pax's `<Text>` element on macOS (native SwiftUI `Text`) and Web (native `<div>` + HTML text) — see: https://docs.pax-lang.org/intro-example.html
Last week at a birthday party, I met a 74-year-old career visual artist who still creates with various media: paint, colored pencils, sculpture, etc.
Curious for her thoughts on DALL-E, I pulled out my phone and invited her to generate some imagery. (I have early access via a family member at OpenAI.) She didn't skip a beat, and immediately started getting creative with it. We even did a "collaborative piece" à la Mad Lib.
I asked her if she felt threatened by DALL-E. Surprised by the question, she said: "No! I could see this really accelerating my process. Sometimes I'm blocked on an idea and I could see this being a great tool for finding inspiration. Can I get access to this?"
My take-away was that art is not zero-sum: someone's art isn't "less" because more entities are creating art. If computers can do it too — even if they're arguably more mechanical in the recombination of existing ideas (note: humans do the same) — nothing stops human art from being art.
Arguably, the biggest barrier to any creative domain is technical capability.
An immediate thought is that locked-in people who can only communicate by text would be able to share their thoughts more expressively.
In terms of the creation loop, anyone can create a bunch of AI-generated images. Wombo is huge right now. The differentiating factors will be prompt design, commitment to iteration, aesthetic-driven curation of generated works and presentation.
Photographers take and process thousands of photos to create just one masterpiece.
Art is zero sum in that there are a limited number of artist residencies, exhibitions and funds available.
In this case, we will likely see further contraction in the number of artists able to support themselves. There will ofc always be the super stars and hobbyists.
The amount of art that people want in their lives is much larger than the amount that's there now.
Artists who are willing to direct their talents towards satisfying others' desires for art will find the world is very positive sum. Those that vie for a limited number of spots in a prestige game may find that it's zero or even negative sum, but those are not good games to play anyways.
There is limited discretionary income available, why would I use $100 in funds to purchase digital art, when I can spend $0.10 to generate one and use the remaining $99.90 on a scuba diving experience?
Never heard of that one, but it's also very recently open-sourced. It's NodeJS with a browser-based GUI? Nice they're not going Electron. I wish there was a Flatpak but will definitely try out.
---
This code was open-sourced in August 2021 when Haiku shut down the commercial collaboration/storage services connected to Haiku Animator.
> I think a big part of the problem is that we try to map our programming language data types directly to serialized types
Much of the time, in-program data is relational with a possibly-cyclic graph describing relationships, ownership, etc. Systems that work with RDBMSes do a fine job of de/serializing data for relational stores, and ORMs are a powerful and delightful way to do this.
The problem with JSON and XML for these kinds of data is these formats are inherently non-relational. They are simple trees of data, not arbitrary graphs. In practice, e.g. in every full-stack web codebase I've ever seen, JSON blobs are hacked together e.g. by doing a makeshift front-end "join by ID" when needed — or adjusting a back-end method to perform the join and return — wait for it — a flattened JSON blob.
It seems like we need a "JSON" or "XML" where relationships are a first-class citizen. To my knowledge, the closest we've come to this is when the data broker and format are tightly coupled, e.g. with SOAP or GraphQL. Can this be achieved strictly declaratively, in a format that's better than a SQL data dump? Maybe!
> I wonder if a system similar to Scheme's `syntax-rules` (or Rust's `macro_rules!`) for mapping the serialized data into the program's data types (and vice-versa) would be a nice mechanism.
Does `serde`[1] look like it's close to your imagined mark? I haven't tried it personally, but it looks akin to Java's `Serializable` or C#'s `ISerializable`— all reasonably elegant ways of handling the messy binding logic of serialization over arbitrary formats.
> and ORMs are a powerful and delightful way to do this
I think we'll end up disagreeing there.
However, I think this type of model could maybe work better for "static" serialization/deserialization of file formats. But even so, I think the biggest part that's missing is a convenient way to describe the mapping between the structure of the serialized data and the internal representation. ORMs typically give you a single method of doing that mapping, which can work when you have control over the serialized representation. But it doesn't work very well when you're serializing to an existing file format, for example.
> Does `serde`[1] look like it's close to your imagined mark?
No, serde is exactly what I was talking about in terms of the serialized data matching your internal data structures. I think it's a necessary piece, but I think the part that's missing is a nice way to map that data to the representation your program want's to work on.
"Flash" was the creation environment: code IDE + vector design + timeline animation tool. "Flash Player" was the portable applet-style runtime.
> not really a fan of resurrecting Flash
Sounds like you're not a fan of resurrecting Flash Player. The previous poster (GP) was pining for a resurrection of Flash. You're talking about different things.
After Effects overshadows it for animation and Animate's "interactive application development" story is bloated and crufty. It's not adapted to the present-day software+hardware ecosystem like Flash&Player were in the 90's/00's -- and it never will be.
Fair point, but I don't recall Flash "things" ever being usable in anything other than some form of a Flash Player, so if the player was suboptimal, it kinda ruins the whole thing, no?
> so if the player was suboptimal, it kinda ruins the whole thing, no?
Agreed! Flash is dead for a reason, and that reason — while manifold and complicated and political and commercial — really boils down to Flash Player.
Back to OP's claim: "Flash needs to come back". I believe they're really pining for (because I pine for) "a creative environment where design, animation, and code coexist — and where every project can be deployed to any device." That was the fulfilled promise of Flash&Player in the 90's/00's.[1]
It will look technically different next time around (WASM? Native mobile targets? Native desktop targets? Modern collaboration/version control?), but I firmly agree with OP that creative environment needs to happen — will happen — again.
[1] Incidentally, that's the presently fulfilled promise of Unity3D for games.
The HTML / CSS stack comes with significant ergonomic hurdles (layout / positioning / "creative fidelity") and performance hurdles (inescapable GC pauses, constant overhead of constraint-solving layout system, DOM overhead in general.)
Can we do better? IMO the future GUI lingua franca is deeply inspired by HTML and will stand on the shoulders of that giant, but will:
WebAssembly makes all of this possible while still extending the Web and browser ecosystems.