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

91–100 of 219 posts

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

#91

Post by dgreensp »

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.

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

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

#92

Post by RobertRoberts »

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.

Yep, the svelte version here appears faster. I'd have to inspect the network traffic to see what it's doing with the data. But I can see a definite speed advantage in this circumstance. To bad it doesn't work everywhere like this.

How fast would it load if every entry had an image? Maybe then it wouldn't seem so different? (edit: this is from a desktop/Firefox)

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

#93

Post by [deleted] »

abritinthebay wrote: post #74
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…

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

[deleted]

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

#94

Post by rich_harris »

dgreensp wrote: post #91
rich_harris wrote: post #67

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.

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…

Hi David! That's odd — it sounds like maybe you're interacting with the nav before the client-side app starts, though it's a little hard to tell exactly. Will try and reproduce it here — thanks

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

#95

Post by purple-again »

dmitriid wrote: post #60

What I don't get in all these frameworks is the desire to invent new and incompatible template languages with increasingly inane syntaxes. Oh. And, of course, with stringly-typed programming and magic binding rules. Just look at Svelte's templates: https://svelte.technology/guide#template-syntax Not only it's some custom implementation, it also breaks all assumptions about javascript code const counter = new Counter(…

I’m not an expert can I can chime in and say that .get and .set are common in Ember data objects as well. No idea if it’s an ES6 thing or Ember thing though.

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

#96

Post by kelvin0 »

Tankenstein wrote: post #2

As always, my main concern with this is traction. Will this be well supported, with a good community, 4 years down the line? I know React will, just because of the massive amounts of business depending on it. When building something real, i have to think about this because i need to be able to hire developers and actually develop my product instead of rewriting it. That aside, the idea of svelte is cool, and i'm happ…

Ask not what your framework can do for you, but rather what YOU can do for your framework.

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

#97

Post by dbbk »

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…

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.

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

#98

Post by tobr »

rich_harris wrote: post #76
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 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 there both {{#if condition}}

Content

{{/if}} and {{{condition && '

Content

'}}}? I feel like all these different concepts break the "it's just HTML" promise, when it seems like it could be simplified a lot.

Yes, JSX has similar gotchas, but at least it has references and specifications.

And what's up with the crazy semantics of computed properties?

Sorry if this sounds negative, but these have been genuine problems for me in getting a hang of Svelte.

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

#99

Post by dbbk »

purple-again wrote: post #95
dmitriid wrote: post #60

What I don't get in all these frameworks is the desire to invent new and incompatible template languages with increasingly inane syntaxes. Oh. And, of course, with stringly-typed programming and magic binding rules. Just look at Svelte's templates: https://svelte.technology/guide#template-syntax Not only it's some custom implementation, it also breaks all assumptions about javascript code const counter = new Counter(…

I’m not an expert can I can chime in and say that .get and .set are common in Ember data objects as well. No idea if it’s an ES6 thing or Ember thing though.

Those are Ember-specific, because ES getters and setters weren't widely available at the time of introduction. They just dropped < IE 11 though so they'll start to go away.

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

#100

Post by aspiringuzer »

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?
Post reply on HN