Will canvas kit have any impact on this project <h...

# compose-web

[eygraber]

Will canvas kit have any impact on this project https://skia.org/user/modules/canvaskit

[Casey Brooks]

I wonder if the existing kotlinx.html code-gen could be repurposed to generate DOM-based Composable functions? Then compose for web would mostly be about the underlying runtime, and not much about the specific HTML composable functions themselves.

Personally, the more I use Compose, the more I want to see a Skia web version for rich applications, rather than HTML DOM

[eygraber]

I've heard that argument a lot (about not feeling consistent with the rest of the web because no native DOM), but I feel like there's a significant demographic that it doesn't apply to.

I'd say that most Kotlin devs haven't worked with the DOM before, and of the ones that have, I'd venture to say there's enough that don't want to work with it to make something like that useful.

I think it would be super cool to build a PoC for this. If someone else doesn't get to it by the time I'm ready, I definitely will (need to get some free time at work + finish the other compose projects I've been working on 😁)

[rnett]

I think part of the "not consistent with the rest of the web" is from a user & 3rd party tooling angle, i.e. web scraping, SEO (although I presume most of the dynamic site methods would work), dev tools, etc. It's definitely an interesting idea though, especially with Kotlin/WASM being in the works.

[eygraber]

That's a good point. I always forget about that. I think accessibility is a big one. Fun challenges ahead.

[Robert]

I think it would be a good thing, not having to stick to the default tooling from ages ago. It’s not like CSS + JS + HTML is a logical coherent whole. I’d prefer to see those three functionalities integrates (and that’s basically what all new frontend frameworks try to do, in a component-based matter). I’d just go for it if I could. Would let Google/SEO stop some cool innovation 🙂

[Tristan]

SEO would not be an issue, the server could detect that a robot is visiting the website and just return the markup for it. For accessibility it would be more complicated I guess.

[Robert]

Probably true, but you can’t solve everything at once 💪

[Daniele B]

In my opinion the top 2 goals for a Compose for Web toolkit should be:
• the smallest file size
• SEO-friendly

[suresh]

If small file js bundle size is important, then CanvasKit is a non-starter. CanvasKit renderer itself adds more than 2.4 MB in download size.

[Robert]

Why would you care about SEO? These are just 3rd party rules that has nothing todo with tech or innovation. I’d say these things doesn’t matter. Also file size is relative, if canvaskit is on CDN and cache from any other site, it has no impact in real life.
These are all details that will be taken care of later on. HTML/CSS/JS didn’t start with all the details either. Just make a simple POC and go from there.

[jim]

@Robert eeerr, SEO matters a lot to content-heavy apps that want to be discoverable via search engines. For a lot of apps, discoverability via search engines is THE key benefit of targeting web. Similarly, many apps care immensely about initial load time (which number of bytes impacts heavily), as seemingly imperceptible increases in initial load time can translate into entire percentage points off revenue which for a company like Google or Amazon means literally hundreds of millions of dollars per year (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html).

All of that is not to say that targeting CanvasKit isn't a good idea. CanvasKit would open the door to entire classes of applications that are not possible to write today, and some factors (like search and load time) don't matter for some classes of applications. CanvasKit would allow substantially more code sharing between existing applications, which can be the difference between feasible and infeasible for startups.

I don't think there is a one-size-fits-all approach. I honestly think there are times and places for both approaches. I am actually really looking forward to seeing something that uses CanvasKit. My comment was not prescriptive about what should be, but was merely descriptive of what is currently being done. If you think CanvasKit is a better approach or better fits your use cases, feel free to team up with Eliezer and help build something. We are very open to taking community contributions in this space. As I mentioned, the first step is probably providing Skiko bindings to CanvasKit: https://github.com/JetBrains/skiko

[Robert]

Neh, SEO should be following tech, not decide what it can or cannot do. SEO should just adjust. SEO isn't even a standard, it differs per company/search engine etc. You can't take things like that in consideration if you want to decide if a tech stack is a good innovation

[jim]

In theory there is no difference between theory and practice. In practice, there is.

[jim]

And like I said, contributions welcomed, nothing is stopping you from proving your position by making it happen.

[Daniele B]

I agree with what Jim is saying. Both approaches would make sense, for different types of applications.
A high traffic B2C website definitely wants to focus on small-weight and SEO-friendliness. While niche or B2B websites might be more interested in the canvas approach.

[eygraber]

Another thing to keep in mind is that SEO, accessibility, etc... currently wouldn't play well with this approach.

That's doesn't mean that tooling and/or support for that won't come around.

[orangy]

For games, canvas would be very suitable :)