[HN Gopher] Qwik Reaches v1.0
       ___________________________________________________________________
        
       Qwik Reaches v1.0
        
       Author : pier25
       Score  : 53 points
       Date   : 2023-05-02 15:14 UTC (7 hours ago)
        
 (HTM) web link (www.builder.io)
 (TXT) w3m dump (www.builder.io)
        
       | _jezell_ wrote:
       | Not to be confused with Quic.
        
         | benatkin wrote:
         | That makes me think of Oui or "Ouic" which would sound like
         | "weak".
         | 
         | Free startup name: Ouil "wheel"
         | 
         | Free quip: ouicsauce
        
       | benatkin wrote:
       | I like it uses .value instead of () to read a signal like Solid.
       | More keystrokes but feels cleaner.
        
         | pier25 wrote:
         | I know it's petty but I really dislike how Solid uses the array
         | destructuring pattern for Signals.
        
           | benatkin wrote:
           | It isn't petty. It's disliking React hooks. Few things are
           | more natural than that. It is too bad Preact gave into them
           | after putting up a fight.
        
       | AbuAssar wrote:
       | > Frameworks such as React, Vue, Angular, Svelte, SolidJS, and
       | their meta frameworks (Next.js, Nuxt, SvelteKit, SolidStart,
       | Astro)
       | 
       | angular has a meta framework called analogjs, as it is not
       | mentioned in the post as an example.
        
       | mrath wrote:
       | More and more frontend frameworks are now somewhat mandating a
       | server part. I know pretty much all(sveltekit, nextjs) say you
       | can do static export, but docs are more focused to use with a
       | server. IMO it appears like this is being pushed by cloud vendors
       | sponsoring those projects.
       | 
       | If you want to build a plain old SPA, the new react docs pretty
       | much have no info. Sveltekit docs discourages it. I have not
       | looked much into vue, but it appears like vue does better here.
       | 
       | Qwik while has a static export, looks like you lose all the good
       | parts of you don't use a server.
       | 
       | I can certainly see the SEO and other good thing that comes with
       | SSR but not everyone needs it.
        
         | vyrotek wrote:
         | Yep, not a fan either. A big shift is that where "routing"
         | happens has moved. Routing has traditionally been done within
         | the SPA. Now it's an external concern and part of a build
         | process.
         | 
         | The various hybrid/mpa/spa innovations are great but not
         | everyone needs them. It's sad to see the traditional SPA
         | approach be discouraged so much.
         | 
         | These meta-frameworks crossing into the server-side will raise
         | a lot of architectural questions for teams. For us, we have
         | React SPAs served by ASP.NET backends and using Vite locally.
         | We'd rather not adopt another dependency like Next or Remix.
         | We're definitely not going to adopt any Node on the backend.
         | 
         | The friction we're experiencing with these new static-exports
         | is that we'd have to configure the backends with the front-end
         | framework's routing system in order to serve the split out
         | static files. e.g. ASP.NET needs to know how to serve NextJS's
         | folder/file/path structure. As opposed to today where we just
         | have to serve an index.html file regardless of whether it's
         | Ang, React, Svelte, etc.
        
         | pier25 wrote:
         | > _IMO it appears like this is being pushed by cloud vendors
         | sponsoring those projects._
         | 
         | Having a server component is just the natural step after a
         | decade of bloated and unnecessary SPAs.
         | 
         | That said, I do think Vercel has probably influenced the design
         | of Next and SvelteKit so that it fits better with their
         | platform.
        
           | mrath wrote:
           | > Having a server component is just the natural step after a
           | decade of bloated and unnecessary SPAs.
           | 
           | Not sure I buy that argument. While I am not totally against
           | the idea of server based frameworks, what is disappointing is
           | the frameworks are appearing to plant the above message.
           | 
           | SPAs provided us a good boundary and that is blurred by all
           | these server based frameworks. You now have server for UI,
           | server for BE. While I agree some SPAs are heavy, I think we
           | have reasonable solutions for most. And these server based
           | framework still need all the work that is done in SPA, just
           | that routing and some aspects of bundling are taken care.
        
       | gdsdfe wrote:
       | haven't done frontend in years ... so how do I use this with say
       | my spring boot backend ??
        
         | benatkin wrote:
         | Spring Boot is a fullstack web framework but it can be used as
         | a backend web framework.
         | 
         | You would use Spring Boot as the backend web framework and Qwik
         | as the fullstack web framework that, instead of using a
         | database*, uses an API powered by Spring Boot to access
         | information.
         | 
         | Everything in the Spring Docs about HTML/CSS/JavaScript would
         | cease to be relevant. https://spring.io/guides/gs/serving-web-
         | content/
         | 
         | * Qwik is perfectly capable of using a database despite being a
         | frontend-heavy framework. It's like Next.js in that the backend
         | runs in Node.js and you can use any npm package that runs on
         | Node. The server-side part of Qwik would be lighter weight with
         | it just passing requests on to the Spring Boot app.
        
           | aatd86 wrote:
           | Basically, needing two servers... One for the API, one
           | (mandatorily a js one, nodejs or deno or whatever... ) to
           | serve the pages.
           | 
           | Personally, I don't like much where the frontend is trying to
           | lock people into.(javascript)
        
       | tuyenhx wrote:
       | At first, I thought it was a python framework from making desktop
       | UI. As I remember, there is a python framework with almost
       | similar name.
       | 
       | Congratz on the first stable version!
       | 
       | P/s: as I am getting older, I am just too tired for new frontend
       | stuffs.
        
       | rektide wrote:
       | Qwik is really interesting. Initially the page is rendered
       | server-side, then sent to the page. But what happens is very
       | unlike most we apps, which then have to re-run most of the app to
       | hydrate:
       | 
       | > _Qwik is different because it does not require hydration to
       | resume an application on the client. Not requiring hydration is
       | what makes the Qwik application startup instantaneous._
       | 
       | > _All other frameworks ' hydration replays all the application
       | logic in the client. Qwik instead pauses execution in the server,
       | and resumes execution in the client._
       | 
       | https://qwik.builder.io/docs/concepts/resumable/
       | 
       | It stores state in the DOM tree in a way that lets it "resume"
       | running. If you click a link, a top level handler can recurse
       | down the page to find listeners. It can gather any extra state &
       | on the fly spin up components needed by the handler.
       | 
       | In general I think the topic of serializing & exposing
       | application state is a vast untapped trove of awesomeness that
       | compsci could be mining. 9p is the best reflection we have. But
       | we also see a steady stream of git-based data projects coming
       | out, that also reflect the value of serializing your state in a
       | valuable way.
       | 
       | The twist here of using serialized app state, baked into the DOM,
       | to allow instant resumability is awesome. On-demand paging back
       | in state is like live migrating a vm or user process, just an
       | awesome feat that redefines the computing model in such a more
       | open way.
       | 
       | Congrats on your 1.0!
        
       ___________________________________________________________________
       (page generated 2023-05-02 23:03 UTC)