The tech looks great but the landing page is a poster child for reminding engineers that you are not your customer, even when your product is designed to be used by other engineers.
The first full sentence of the first full paragraph on the landing page is "Qwik does not do hydration because it is resumable."
The fraction of people looking for a "zero hydration resumable web framework" is at best minuscule compared to the number of people looking to make their website load faster or looking for ways to convert a higher fraction of visitors into customers.
Even on HN, people adopt products because of the benefits, not because of the hard things you did. Zero hydration is not a benefit - it's a hard thing you did that makes the real benefits possible. Start with the benefits. Understanding the benefits makes people want to know more, including the secret sauce, like zero hydration, that makes the benefits possible.
This page [0] would make a better landing page - it makes a much more readable case for what Qwik is and why it's important.
> The fraction of people looking for a "zero hydration front end web framework" is at best minuscule compared to the number of people looking to make their website load faster or looking for ways to convert a higher fraction of visitors into customers.
It probably means that their target audience is people who understand these words. Probably web developers disenchanted with the state of today's web frontend, and looking for informed decisions in assessing different options.
As for ways to make their website faster, almost every web framework will boast of that. Gatsby (for crying out loud) will say it's "the fastest".
This announcement is a big deal. It's an extremely disruptive new project from an extremely experienced team. It's also an announcement that has driven a tiny fraction of the discussion one would expect a project of this importance built by a team of this experience to drive on HN.
Hopefully things pick up, but the past six hour's minimal response to this posting (and mostly similar or weaker responses to previous postings about Qwik here) is arguably a powerful measure of the landing page and the tag line for the landing page failing to do their job.
Bear in mind this is a beta product, it's being actively developed (e.g. signals like in solidjs are coming soon, which is a pretty major feature) and the API is probably going to change quite a bit in the following months.
The people that want to "speed up their site" are not the target audience at this point, it's developers who know what hydration and resumability are.
Very few web developers are "keeping up-to-date" that quickly. I've been aware of it for a while, but the vast majority of devs are not aware of tools until they hit mass adoption.
This feels like a good hook to me. Imagine how many executives and team leaders have heard “hydration” as an excuse for why a particular feature is difficult/late/complicated.
Bypass hydration, problems go away. It doesn’t matter what the solution is.
Plus, giving the usually-non-techy manager a good buzzword (which, let’s be fair, “resumable” is because it is a real programming term that is not well-defined and could somehow play a role in the design of an alternative to hydration) gives… uh, what was I talking about?
Plus, giving the manager a good buzzword that they can drop in meetings and catch the others participants unaware makes them feel powerful, and they will mention Qwik as part of that buzzword-droppage.
Is this a joke? I’m a senior PM at one of the “bigger” modern software companies they everyone loves to hate and I’ve literally never heard anyone talk about issues with “hydration”.
I’ve heard plenty about inefficient rendering of SSR react components, but literally never heard anyone say “we have an issue because of hydration speed etc”.
I don’t entirely agree with the original comment too but hydration has always been an issue when TTI is discussed.
Aside from the inefficient rendering of SSR due to data aggregating data, another inefficiency here is the need to re-render them again client side all that same JavaScript and json server side.
React tries to solve this issue with its concurrent mode, and streaming ssr, and server components.
I argue hydration is near to the core problem that many of today’s popular tools like graphql relay and react’s concurrent mode are trying to solve. Or Remix, Marko, Nextjs’s layout RFC. Each tool solves the problem slightly differently. Some try to make sure all data are loaded in parallel as much as possible so that hydration doesn’t cause a waterfall of requests. Others lazy load islands of JavaScript.
The first full sentence of the first full paragraph on the landing page is "Qwik does not do hydration because it is resumable."
The fraction of people looking for a "zero hydration resumable web framework" is at best minuscule compared to the number of people looking to make their website load faster or looking for ways to convert a higher fraction of visitors into customers.
Even on HN, people adopt products because of the benefits, not because of the hard things you did. Zero hydration is not a benefit - it's a hard thing you did that makes the real benefits possible. Start with the benefits. Understanding the benefits makes people want to know more, including the secret sauce, like zero hydration, that makes the benefits possible.
This page [0] would make a better landing page - it makes a much more readable case for what Qwik is and why it's important.
[0]https://qwik.builder.io/docs/overview/