Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Sapper.js – towards a better web app framework

svelte.technology

Post reply on HN
Print view View original

111–120 of 219 posts

Re: Show HN: Sapper.js – towards a better web app framework

#111

Post by Nemi »

scottmf wrote: post #63
rimliu wrote: post #49

Earlier quoted context omitted.

Or it may well be that this "all new web tech" was created by people who do not understand neither web nor HTML. Sudenly everything needs to be SPA, every site needs to load hundreds KBs of scripts just to "be current". What's the value of being modern if it makes user experience objectively worse? Sure client side render may prevent you from reloading the entire page. And who cares that this rerender actually takes…

>Sudenly everything needs to be SPA, every site needs to load hundreds KBs of scripts just to "be current". Not everything has to be an SPA, but React is 30kb gzipped and Preact et al are in the single digits. >What's the value of being modern if it makes user experience objectively worse? The point is they don’t inherently make user experience objectively worse. >Sure client side render may prevent you from reloadin…

> The point is they don’t inherently make user experience objectively worse.

Ah, but they do. Browsers are very mature and predictable in their management of html pages and SPA's break that behavior in subtle, uncanny-valley ways.

For instance, click into the Sapper HN page https://hn.svelte.technology/item/16052558, scroll down to a post with a random link and click into it. Click on another page in that link. Now click the back button in your browser to get back to the sapper page. You find that you will be at the top of the page as it re-renders. You lose the place you were scrolled to.

This does not happen with standard cached html pages in the browser.

One of the worst offenders is google's home page. When clicking into the links looking for something, clicking back will take you to top, again and again, losing your place. This is a big step back in usability that people are not even aware is happening. It is a small thing individually, but in aggregate it adds up to a large thing.

Re: Show HN: Sapper.js – towards a better web app framework

#112

Post by alkonaut »

Touche wrote: post #6

I think this premise is wrong: > 2. As a corollary, your app's codebase should be universal — write once for server and client This is a mistake a lot of developers make. The server and client are not the same. As far as rendering HTML goes, the client does a superset of what the server does. This means either the framework has to be without leaks; meaning you never need raw DOM access at all, OR it means once you do…

I’m not sure I’d share a lot of code between server and client even if I could, but sharing the odd domain type, some utilities etc might be handy.

The universalness I want is that I want one language, package manager, toolchain, IDE etc for all the code I’m working on. Worst case would be to have the two platforms being slightly different. Say two IDE’s with slightly different shortcuts, two curly brace languages with slightly different syntax, two different build systems you need to integrate in the CI etc.

Re: Show HN: Sapper.js – towards a better web app framework

#113

Post by dsego »

rich_harris wrote: post #67
RobertRoberts wrote: post #61

Earlier quoted context omitted.

>...because there's less data to transfer... The problem is that just the theory, reality if often times different. >Going back to the server for 100kb of HTML and reloading the entire page... This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions. Another thing…

Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.

Bearing in mind that HN loads content in html tables, which are notoriously slow to render. I am not saying it makes a huge difference, but it could have an impact.

Re: Show HN: Sapper.js – towards a better web app framework

#114

Post by ralmidani »

Touche wrote: post #21
rich_harris wrote: post #14

Earlier quoted context omitted.

The server is only involved when you first hit the page. After that, the client takes care of all the rendering. There is no discrepancy!

There's a discrepancy if the user doesn't see something when the page first renders but then does see it once the JS runs.

With Ember and React at least, it's the same if you use 100% client-rendered elements; the component/template renders to the page, then a lifecycle hook is triggered, and then your custom code/plugin runs.

Re: Show HN: Sapper.js – towards a better web app framework

#115

Post by aspiringuzer »

AiDirex wrote: post #75

How the fuck something that is in early development advertises as military grade!

Getting new technologies to gain traction is not easy - regardless of their technical merit. I do admire the framework designer's P.T. Barnum like showmanship. He's got it down to a science.

Re: Show HN: Sapper.js – towards a better web app framework

#116

Post by goatlover »

nine_k wrote: post #71
rimliu wrote: post #49

Earlier quoted context omitted.

Or it may well be that this "all new web tech" was created by people who do not understand neither web nor HTML. Sudenly everything needs to be SPA, every site needs to load hundreds KBs of scripts just to "be current". What's the value of being modern if it makes user experience objectively worse? Sure client side render may prevent you from reloading the entire page. And who cares that this rerender actually takes…

"Right tool for the job", as the old saying goes. There are sites that indeed are applications, with lots of updates occurring dynamically on a page: a chat, a dashboard, any type of control interface. They do benefit from the libraries that make highly dynamic things efficient. There are sites that are best served as static pages. This includes the server component, too, BTW. A static site generator producing plain…

Agreed, don't make SPAs out of sites that work well as traditional websites. Browsers and the internet are fast at serving up html & css these days. Even PHP rendering is pretty damn fast. And it best fits how browsers work for traditional sites.

Re: Show HN: Sapper.js – towards a better web app framework

#117

Post by innocentoldguy »

aspiringuzer wrote: post #100

I've used many web frameworks over the years and I really wanted to like this Sapper technology, but for the life of me I just don't understand what problem it's trying to solve. Can someone give me a comparison of what comparable technologies it is replacing?

There hasn't been a new, shiny JavaScript framework out in a few days. Perhaps Sapper is trying to solve that?

Re: Show HN: Sapper.js – towards a better web app framework

#118

Post by deno »

rich_harris wrote: post #57
deno wrote: post #51

Some bullet points are missing from the “perfect framework” list: 1. SSR must support streaming 2. SSR must work in a service worker (so in fact you have 3 targets: server, client/hydration, client/service worker) 3. All work that can be offloaded to a WebWorker must be offloaded 4. Navigating to subsequent pages must support prefetching, including dynamic data (Next.js doesn’t even tell you how to do it) 5. Navigati…

This is an excellent list, thank you. To answer some of the points: Sapper supports partial streaming of server-rendered HTML (typically you'll get most of the while it's fetching data for your page, unless there's no dynamic data in which case you get the whole lot instantly). I'm not convinced there's actually a benefit to 'server' rendering in a service worker as opposed to serving a shell page. We have an issue f…

It should be “free” with the right architecture, and it should be faster, that’s why I included it for the “perfect” framework list.

However, it’s only a win on first page load on a subsequent visit. So definitely not a priority for an actual implementation.

BTW one easy way to implement this would be to flip the usual model:

1) Have service worker/server as main renderers

2) On navigation do a fetch to service worker and patch the page

So you’re on /main, do fetch to /page2?from=state and get patching instructions.

If you could give the service worker readonly access to DOM without copying this wouldn’t actually be that stupid.

It might be possible some day:

https://github.com/whatwg/dom/issues/270

Re: Show HN: Sapper.js – towards a better web app framework

#119

Post by dsego »

rich_harris wrote: post #53
RobertRoberts wrote: post #37

Earlier quoted context omitted.

But this is where the entire argument of "do first page load server side because it's faster" doesn't make any sense. Because then aren't you suggesting that after that, all the other pages can be slow? The worst sites I visit now are React.js like sites, instead of the page load being slow, _everything_ is slow. Ugh. I can't wait until web 3.0 and this silly balogna with the "make a browser with React and run it ins…

Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!

If we replaced JSON with something less "chatty", would that propel us to 2022?

Re: Show HN: Sapper.js – towards a better web app framework

#120

Post by weego »

dbbk wrote: post #97
tboyd47 wrote: post #46

Earlier quoted context omitted.

Can't agree more. It's El Dorado for web developers. You might be able to write all your app code in Javascript, but the inputs and outputs are so different that you never really avoid "if(isServer()) {...} else {...}". You can't contain that in a single file, either. It surfaces in the most unexpected places and gradually erodes the illusion of "universal," until you're never sure in which order or what environment…

This is not the reality though... with React and Ember (presumably also Vue) there is one place where client-side only stuff happens, and it's in component lifecycle hooks. It's perfectly clean and makes sense.

So you have 2 versions of the code with a shared contract between the two. Isn't that exactly what the original criticism was, other than in this world your server and client both have packaged code that is likely redundant or at least not a clean abstraction?
Post reply on HN