zackbrown

Check out the approach that Pax is taking.[0]

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.

[0] see pax.dev or check out a simple example: https://static.pax.dev/space-game/ ; source code for space game in examples on github https://www.github.com/paxengine/pax

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.

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.

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

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:

  <SomeElement some_property={self.get_platform_specific_value()} />

3. Maintain a separate codebase (or different specific components) for each target platform, in the spirit of React Native

Or any mix of the above.

Why?

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.

> Contrary to the prevailing opinion

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.

This is a core design goal for Pax. https://www.pax-lang.org

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.

Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ and https://www.github.com/pax-lang/pax

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.

Haiku Animator recently went free and open source: https://www.haikuanimator.com

> 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.

[1] https://serde.rs/

> 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.

Adobe Animate is a zombie.

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.

"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.

The best practice is to test.

Measure how a set of prices performs against your driving metric, e.g. customer growth or revenue growth. Iterate on pricing, measure again.

Repeat until you have enough data to model a demand curve[1] between price and your key metric, then choose your pricing as the point of inflection on that curve. Fine-tune with another round of experiments for charm pricing (e.g. 50 vs 49).

Repeat and localize currencies and prices (e.g. via PPP) for each of your top five geographic markets if you really want to optimize.[2]

Second-best practice? Research what your competitors are charging and charge roughly that.

[1] https://en.wikipedia.org/wiki/Demand_curve

[2] I wrote this article: https://crow.app/blog/price-localization-with-stripe

p.s. wouldn't it be great if folks who lived in lower-buying power countries could jump on a VPN and start making (e.g.) a US salary?

Hey, yes — you can do this with a VPN.

Check out NordVPN.

> If you’re doing badly, why would you want to keep working on this for 24 or 36 months?

Doesn't this run exactly contrary to the prevailing YC wisdom that "those who stay in the game are those who win?"

While pivoting in search of P/M fit, every startup is doing badly — until they're not.

Would you really suggest to pack it in after 12 months without traction or luck? Instead of pivoting and adapting? How many of YC's Top 100 wouldn't exist today if they operated by that advice?

Apt that it was originally called Future Splash.

Recognizing that this has been posted several times over the years on HN —

Conway's law comes up so often in our remote team & design decisions that I thought the HN community may benefit from a fresh look at this phenomenon in the age of Covid-19.

Edit — link to the meatiest past discussion thread: https://news.ycombinator.com/item?id=16856537

`git subtree split` will extract a subdirectory and its (exclusive) history to a new repo.

Publish that repo and maintain it separately.

To apply established terms to these concepts, the divide you're describing is roughly "cost-based pricing" vs. "value-based pricing."

GP may be describing the Figma plugin platform itself, which allows you to "automate anything in Figma with TypeScript" — by authoring plugins.

The article is misleading. That's either unintentional or intentional.

Per Hanlon's razor, my first hypothesis is the former but we shouldn't rule out the latter. Proactively question good faith but don't proactively doubt it.

Calling out the article as misleading mitigates the damage it causes and thus exactly "contributes to understanding the topic."

Thanks for the feedback!

"Lazy work" does not mean "lazy person." And "joke" would be better stated as "this article reads suspiciously as astroturfing."

But I see how the blunt call-out of lazy work and tip-toeing around the astroturfing vibes—i.e. the way I worded my comment—could read as a personal attack, and I agree that's not a productive way to approach discourse.

I missed the edit window, but I would amend the first line: s/author/article and s/a joke/intentionally misleading.

The author's assessment of the "no-code" and "hybrid tools" landscape is either lazy or a joke. Here are a few more:

No-code tools for apps & websites:

  - Webflow
  - Glide
  - SquareSpace
  - Dreamweaver [1]
  - Visly

Hybrid "designer/developer connectors"

  - Hadron
  - Modulz [2]
  - Interplay [3]
  - Haiku [4]
  - Zeplin
  - Zeroheight [5]
  - InVision DSM [5]

Sad to see this blog post on the front page of HN since it's such a poor representation of this landscape. Hopefully this comment helps in a small way :)

  --

[1] yeah it still exists, and yeah it's pretty much still Webflow as a 90's-vintage desktop app.

[2] Modulz' product doesn't exist yet, but they've built hype. Caveat emptor.

[3] Just like Modulz, but from what I've seen there's more execution and less hype.

[4] My company: we pivoted our original "designer/developer connector" into an animation tool — we're launching our new collaboration tool soon.

[5] Sort-of; designer-focus

Between Delphi, C#, and TypeScript the man has already had a storied and impactful career.

When it comes to winner-takes-all (the bread & butter of VC economics,) it strikes me as dissonant to bet both on no-code and on dev tools.

No-code’s winner-takes-all scenario presumes full automation of developers. It’s in the name: no code, no developers.

Postulate: software developers will remain necessary as long as human brains don’t natively speak “Von Neumann.“

Thus the winner-who-takes-all is going to be “with-code,” not “no-code.” “No-code” is a misnomer and a dead-end.

“REST for design tokens” is alluring because it’d be codebase-agnostic, but it would be incredibly risky & maintenance-intensive.

Design tokens evolve. Builds would break when schemas change—or if you hacked around that you’d forfeit the advantages of typed languages on iOS/Android. Untyped Javascript/CSS would silently break and start to decay the minute changes are made on either side of the server.

There are ways to wrangle “single reference point” for design tokens without introducing a network dependency.

See the open-source project Diez, a polyglot native transpiler for design tokens. (I’m a project maintainer)

https://diez.org

Beta URLs fixed: https://github.com/diez/diez/pull/7/files