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

61–70 of 219 posts

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

#61

Post by RobertRoberts »

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!

>...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, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework.

To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment)

A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)

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

#62

Post by al2o3cr »

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!

    is a very 2002 way of doing things
Despite sharing a common three-letter prefix, "fast" and "fashionable" are frequently uncorrelated qualities.

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

#63

Post by scottmf »

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…

>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 reloading the entire page. And who cares that this rerender actually takes longer than reload?

This isn’t how it works. Rerenders can be incredibly fast.

>Did I really need to waste 200KB of my mobile data to load scripts all I wanted to see were 5 pages each weigthing 5KB? What did I gain from trading full reload for the a-la-SPA kind of deal?

What did you lose? You lost nothing because SSR provided the initial page load as quickly as any other HTML.

It sounds like you’ve generalized the entirety of modern SPA development from your experience of a few terribly developed sites with poor user experience.

You probably only notice the poorly-built SPAs because the UX gets in the way. i.e., confirmation bias.

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

#64

Post by bdcravens »

scottmf wrote: post #42
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…

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.

Isn't the opposite true? A lot of "younger" developers are stuck disliking anything older than 2010 because it's not "new". Not because it's slower, or creates a bad experience for the customer, but because it's not new. If it's not faster, and doesn't provide a competitive advantage (I'm talking about real competition, not the pseudo-competitive market of "hire all the developers by dangling shiny new tech in front of them"), then what's the point? (There are certainly use cases where new approaches make sense, but that doesn't mean they become the new defaults)

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

#65

Post by dmitriid »

gedy wrote: post #10
mlsarecmg wrote: post #9

Earlier quoted context omitted.

As much as i want to like it, i have troubles thinking of templates as something that questions the status-quo. The other big thing seems to be loading effort, but react has gotten so small (react+react-dom = 29kb, react+react-dom-lite 15kb, preact-compat 4kb), there's not really an impact any longer. And as for performance, could Svelte even approach something like the Sierpinski demo - something that would allow Re…

Svelte is not "templates" (i.e. client-side), it compiles to JS modules

Whatever it compiles down to in the end, it's stringly-typed templates with a custom syntax and weird assumptions about code that break everything you know about Javascript: scoping rules, variable declarations etc.

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

#66

Post by timr »

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!

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-100ms. The difference decreases further when you enable server-side compression and start doing fragment rendering, which tends to remove the penalty for HTML payloads.

The argument for react-like technologies is not connection latency, but rather, the hope that you can avoid synchronous connections in the first place by moving your view logic client-side. And truthfully, few client-side apps are written in a way that would minimize payloads anyway. Most people are doing it because they hate working with the DOM and AJAX and server-side frameworks in a mishmash of web technologies, and perceive these client-side frameworks as easier.

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

#67

Post by rich_harris »

RobertRoberts wrote: post #61
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!

>...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.

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

#68

Post by goatlover »

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!

How long does it take going back to the server and loading 100kb of HTML these days?

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

#69

Post by RobertRoberts »

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…

>You probably only notice the poorly-built SPAs because the UX gets in the way. i.e., confirmation bias.

Maybe you are too young to remember Youtube before it was turned into a webapp. It was _considerably_ faster. Todays version requires all sorts of odd refreshing bits and pieces. The old one just loaded right away and showed the video.

If I was paranoid, I'd think that Google did it on purpose to push Youtube Red ads at us.

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

#70

Post by tobr »

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.

Post reply on HN