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

101–110 of 219 posts

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

#101

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.

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 specific feature though, it's just a js tabs sort of interface. It doesn't seem like a good argument piece for or against this framework)

I did get a possible error, the pages didn't match up after a while. Is the svelte data was being cached in a way that can't refresh properly? I can't debug this as a normal user, does hitting refresh do anything to reload the site content on the svelte site?

Try this, open both sites in different tabs, and navigate around on them a few times, and after awhile, the news.ycombinator will show new content, and the other one will be different. (I am guessing older content, server cache issue? I didn't compare carefully, maybe they started off different and I didn't notice)

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

#102

Post by rich_harris »

tobr wrote: post #98
rich_harris wrote: post #76

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…

Colons indicate that something is a directive rather than an attribute — so `on:click` is the `on` directive with the `click` event, and `bind:thing` is the `bind` directive with the `thing` data property. The one place we violate that slightly is with `:foo`, which is shorthand for `foo={{foo}}` (since people dislike the ceremony of passing props down between components, and this makes it easier).

{{#if condition}}...{{/if}} tells Svelte something about the structure of your app. {{{condition && '

Content

'}}} doesn't, and you can't add interactivity to the

if it's just a string. Moreover, if `condition` is `undefined`, then that's the string that will get rendered to the DOM. Generally, {{{triples}}} should be used for blobs of HTML you get from data sources, such as a blog post.

If you can overcome your distaste for the computed property dependency injection, you'll hopefully find it's an extremely easy and compact syntax for declaring arbitrarily complex graphs of properties. The advantage of doing it this way is that Svelte can generate, at compile time, very efficient code for updating computed properties without any wasteful runtime dependency tracking. I realise it's slightly controversial (because it's a Svelte idiom, rather than something in JS itself), but for those who have embraced them, computed properties are one of the best features of Svelte!

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

#103

Post by RobertRoberts »

scottmf wrote: post #87
RobertRoberts wrote: post #55

Earlier quoted context omitted.

I've been doing webdev since 1999. I've seen all manner of stupid hacks, dumb "best practices" that have come and gone, ridiculous frameworks that became _useless_ because browsers just integrated the features. Flash home screens, table layouts, IE only coding up the wazoo. So, when someone says they have a JS framework that replaces the core of the browser's display, the DOM, my response to that is sigh , this again…

You should learn React and build a simple project with it to understand its real value, which is component-based architecture. React will likely be around longer than/as long as any framework, but whatever replaces it will use a lot of the same concepts.

How does that help 1000 visitors to a blog read the blog easier? Not every site is an app, and the apps we do build we already have invested in VanillaJS framework. Do you think React will outlast the VanillaJS framework? (http://vanilla-js.com/)

(edit: this is partly a joke comment, fyi)

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

#104

Post by tboyd47 »

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.

It was and is a reality for many people and was my very frustrating reality for quite a while. The concept of "client-side only" code that does anything more significant than animations (such as, say, modals) breaks down if you want deep linking, and deep linking requires full data reloading on every action, because how can you be sure the data is all there if you don't load it, and once you're reloading your entire state tree on every action you're already slower (not just in data transfer but in code execution) than the "traditional" client-server pattern, and if you have a UX team and any timeline pressure at all, you've already written yourself into several corners for UI bells and whistles, which unfortunately affect the server side as well now, not to mention being at least a major version out of date on several NPM libraries, and just another rewrite away from clean architecture, and so on...

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

#105

Post by antonkm »

RobertRoberts wrote: post #55
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.

I've been doing webdev since 1999. I've seen all manner of stupid hacks, dumb "best practices" that have come and gone, ridiculous frameworks that became _useless_ because browsers just integrated the features. Flash home screens, table layouts, IE only coding up the wazoo. So, when someone says they have a JS framework that replaces the core of the browser's display, the DOM, my response to that is sigh , this again…

I agree - have yet to see the benefit of using a framework that aren't at least 2 years. Never do client work using newly released frameworks (if that isn't specified as a must by the client). The result will come back to bite you sooner or later.

I like the idea of universal code, maybe Sapper will be the solution that comes out winning. I'll let the community be the judges and hop on the train a year later if that's the case.

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

#106

Post by mlsarecmg »

rich_harris wrote: post #22
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…

You mean this Sierpinski demo? http://svelte-sierpinski.surge.sh/ Ok, I'll level with you — that's not actually doing the same thing as the Fiber version. But that's it's basically impossible to accidentally slow down your Svelte app in the same way as the Fiber demo depends on. Fiber doesn't really speed things up so much as it prevents bad code slowing things down. The innovation isn't templates (though these aren'…

The whole point is the artificial slowdown. Taking it out makes it meaningless, it prints a few blue bubbles. Scheduling is and always will be the biggest bottleneck. It is that kind of innovation that keeps react relative.

As for a lean dom representation, i have never seen or heard of memory related problems regarding v-dom. And won't byte-code make it leaner in any case? React-compiled is already being tested.

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

#107

Post by mlsarecmg »

gedy wrote: post #85
dmitriid wrote: post #65

Earlier quoted context omitted.

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.

Okay, but JSX is not 'just JavaScript' either - it's a DSL embedded in JS. You could make the same argument that Svelte is 'just HTML' with a script block, style block etc.

Like typescript, flow or even es-next. An optional DSL that transpiles to pure javascript isn't an obstacle to programming. A string-template with an arbitrary syntax is an obstacle on the other hand.

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

#108

Post by shoover »

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…

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.

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

#109

Post by pwaai »

How many of you actually built a React/Redux stack SPA that actually came anywhere near what Sapper offers?

The file size problem is underrated. Not everybody walks around with 5G like in South Korea. Not everybody has the latest and greatest Samsung or Apple phone.

It's a big problem when you advertise PWA as quick and fast but then in tiny letters mention its using the best case on best network and best phone. If you design without worst case in mind, you've discriminated people based on whether they can afford the best or not.

The vast majority of users don't. It's only recently that Android phones have gotten cheap that its seeing widespread usage. These people are not going to wait around for the React/Redux stack to load AND still wait on more data coming through their 2g/3g connection. Oh, and there's slow rendering on older Android phones and now you have a laggy Javascript app experience that Lighthouse tells you everything is okay.

Let's not be so quick to judge. It's not as if Sapper has deviated from the trend that even React team is acknowledging. This is a fresh approach to a quickly monopolizing space, from an organization that has other agendas in seeing their tech stack flourish.

I'm gonna definitely be watching Sapper.js in 2018 and if they deliver on most of the 11 criterias, I know my customers and their customers will be happy.

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

#110

Post by Touche »

mlsarecmg wrote: post #107
gedy wrote: post #85

Earlier quoted context omitted.

Okay, but JSX is not 'just JavaScript' either - it's a DSL embedded in JS. You could make the same argument that Svelte is 'just HTML' with a script block, style block etc.

Like typescript, flow or even es-next. An optional DSL that transpiles to pure javascript isn't an obstacle to programming. A string-template with an arbitrary syntax is an obstacle on the other hand.

svelte templates compile to "pure javascript".
Post reply on HN