Live data from Hacker News

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

svelte.technology

131–140 of 219 posts

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

#131

Earlier quoted context omitted.

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.

I tried this on my phone. (Android/Firefox) And I found that it's about .5 second to navigate between pages on hn.svelte.technology And about 1.5-2 seconds with the news.ycombinator.com, on average. Sometimes the straight page load was just as fast (.5 second) and sometimes it sat there while 3-5 seconds. Yes, the svelte is generally faster on my phone as well. (I am not sure I see the need for a framework for this s…

Possibly a misbehaving service worker serving stale content! I can never configure those right first time.

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

#132
post #128
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.

I am willing to concede your pedigree as a developer as necessary but I've been writing all manner of languages and environments since 99 and I'm sorry to say there's no revolution here, no battlefield to die on. It's a poor model that has been tried and abandoned any number of times in my career. The ubiquity of platforms that suit these ideas and developers who think Web development began with node and spas isn't c…

Your comment expresses a really common sentiment, but it also vague and offers no supporting evidence.

When was a model like React + Redux (or Elm) used previously, and why did it fail? The combination of factors (browser advances and iteration on existing models) is unlike anything before. This tech stack did not exist in 1999, it did not exist in 2005, and it did not exist in 2012. It is driven by real problems.

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

#134
post #98

Earlier quoted context omitted.

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 lik…

Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is ther…

Just like anything, there's a small learning curve on syntax. Once you can get past your grievances (is HTML any less weird?), Svelte is extremely fast to build with.

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

#135
post #98

Earlier quoted context omitted.

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 lik…

Maybe it's just the documentation that is lacking, but when I've played with Svelte, the API and template syntax feels like a hodgepodge of special cases. For example, what exactly does a tag starting with colon mean? Is it just arbitrary syntax for things that don't fit in? What does a colon in an attribute mean? (i.e., why on:click rather than onclick or onClick or even something simpler like :onClick?) Why is ther…

I'd love an attributes syntax akin to riot.js, less noise and blends into html nicely.

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

#136

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 isn't really anything comparable. Really. It doesn't include the framework in the end build. It's only in the original source. So it's a compiler, not really a framework, that compiles to code that's performant to specific tasks.

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

#137
post #78

Earlier quoted context omitted.

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.

What about when you start clicking the links in the nav, or opening other stories and profile pages? As far as I can see, the Sapper version blows the original out of the water.

The Sapper version is cheating a little. It is preloading the pages on mouseOver events of the links.

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

#138
One of the authors of Next.js here. I want to clarify that all the points against Next.js are virtues! They probably just arise from Rich not being so familiar with it (or not having looked at the examples/ directory extensively: https://github.com/zeit/next.js/tree/canary/examples)

1. I think this point is trying to say that we don't have special "mask files" inside `pages/`, which is an idea worth exploring. Right now, Next.js instead gives you full flexibility on how you want to match the routes on your server (as it should be). For example, `your-domain.com/xyz` can even first perform a database query before deciding what page to render it with (if any).

2. What the author points out as a weakness here is that you can handle server things directly in your server code (`server.js` using micro or express for example). That sounds like the right thing to do to me, and if you don't want that, you still can do something like:

  // pages/my-server-page-only.js
  export default ({ req, res }) => res.end('hi')
3. "To use the client-side router, links can't be standard tags." This is by design. Magically overloading `` to add client-specific behavior sounds like the days of jQuery or TurboLinks. If you want client-side behavior, wrap `` in the higher-order `` component. There also very important properties of the `` like `` that are simply not part of the `` standard definition.

Also noteworthy: the entire ZEIT Documentation is written in Markdown with React components. It's open source: https://github.com/zeit/docs

On size: the Next.js and React teams are both working towards really interesting solutions to ship only the code that's necessary, without resorting to templating as the main strategy. Our team actually spends more time on the 'compiler' parts of Next.js than the 'framework API' parts. (the API has barely changed since the initial 0.1 release in fact).

Additionally, since Next.js uses React as peer dependencies, you'll also get to do `yarn add next react react-dom-lite` https://github.com/jquense/react-dom-lite in the future.

Overall, I think Sapper is an excellent framework for Svelte users. I'm looking forward to seeing more Next.js-like frameworks.

For Vue users: check out https://nuxtjs.org/!

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

#139

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…

I get what you mean and you are right in a way, but raw performance is not the only thing to consider. Yes, server rendered sites are usually an order of magnitude simpler to code than these JS-rendered solutions, and are often faster, but where JS rendering shines is interactivity and perceived performances: you always know what is going on! loading, sending a text, etc (provided the UX is right) Sprinkling some client-side code on top of server rendered templates is so limitating for everything but the simplest websites!

It's 80% more effort for the 20% last performance/richness points.

it's over, people want/expect these kinds of apps, e.g feels as good as native apps but on the web.

But you're also right some people misuse that kind of technology to a ridiculous extent. Downloading a 3MB angular app just to display a crappy site without any rich interactions is really infuriating but that's just bad engineering and people who make choices based on what's popular, disregarding context.

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

#140

Earlier quoted context omitted.

Hi Rich. On my iPhone, I get a 3-second delay between when I “swipe to go back” and when the page is usable/scrollable on the Sapper HN. When I first went to the site, via the link above, the top nav links did not seem to work reliably, and it may have been the same 3-second delay, but I’m only getting now when swiping to go back — maybe because the page is being reloaded from the server? It’s still quite a delay, th…

Interesting. I get behavior like that with twitter.com on the iPad. It hangs with a blank white page for a few seconds. I always wondered what kind of client script shenanigans were going with that. Using the back button embedded in the web page does not cause the same delay.

I get the same behavior on my phone with their new website too. Service worker infancy bugs?
Post reply on HN