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

71–80 of 219 posts

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

#71

Post by nine_k »

rimliu wrote: post #49
scottmf wrote: post #42

Earlier quoted context omitted.

I feel like a lot of HN is stuck in 2010 and dislikes all of this new web tech because they don’t understand it. This comment is a prime example.

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 HTML + CSS is often a good replacement to something like Wordpress.

Some people use latest trending tech for no good reason, just to show off. But the problem here lies not in the tech used.

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

#72

Post by ravenstine »

kiernanmcgowan wrote: post #39

Question: > 1. It should do server-side rendering, for fast initial loads and no caveats around SEO Is server-side rendering still an issue for SEO? Don't major search engines evaluate pages now so that SPAs can be indexed?

It's not as much of an issue for SEO, depending on what you're using to render.

The bigger problem is Facebook, Twitter, and the like are not going to run JavaScript to read your meta tags. It's not an issue for everyone, but if you're a publisher of articles then you're still going to have to render something from the server. Of course one can come halfway by only rendering the head tag contents and not producing a body, which is where most of the complication comes from.

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

#73

Post by abritinthebay »

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.

That would be poor coding or application design. There’s no reason for that to happen with SSR. At all.

There’s especially no reason for it with modern frameworks like React/Vue/etc - it’s not been a technical problem for years.

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

#74

Post by abritinthebay »

tboyd47 wrote: post #46
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…

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…

Apparently I’m working in El Dorado then...

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

#76

Post by rich_harris »

tobr wrote: post #70

Curious: why use Webpack rather than your own and IMHO much superior bundler, Rollup? I’m excited to try this more but I have mixed feelings about Svelte. The concept is brilliant but I feel like there’s too much API and some weird gotchas. I hope there’ll be an effort to simplify it if possible.

It uses code-splitting, dynamic imports and hot module reloading, which are all well supported in webpack. We definitely plan to support Rollup as well, once it has those features — it should be possible to shrink down JS payloads by a reasonable amount. (Maybe Parcel too, eventually.)

I think the 'too much API' feelings might be more unfamiliarity than anything. The API surface area is much smaller than anything like Angular, Vue etc, and although it's a fundamentally different approach to React I'd argue Svelte has a much shallower learning curve there as well. We're very open to feedback and suggestions though!

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

#78

Post by Touche »

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.

Judging based on the 'load' event they are about the same, or the HN version might be a little bit (So basically the added complexity gives you the same load time when done extremely well (as Sapper is). In terms of bang for your buck, the service worker is biggest improvement. Which you can implement in your server-rendered app.

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

#79

Post by OJFord »

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…

> the rule of 3 is the rule of 3, not the rule of 2.

But, to quote from your link:

> and may or may not if there are two copies.

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

#80

Post by GordonS »

timr wrote: post #66
rich_harris wrote: post #53

Earlier quoted context omitted.

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!

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! The difference between streaming 100kb and 10kb is small when compared to the connection latency itself. Even on a low-end LTE connection (5mbps), 100kb is 20ms, whereas the latency of a cross-country (US) transit is realistically ~50-100…

There is also browser caching. So subsequent page loads may not require any new scripts or stylesheets to be loaded, for example, so you're only loading some GZIPped HTML.
Post reply on HN