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

211–219 of 219 posts

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

#211

Post by vanderZwan »

mlsarecmg wrote: post #106
rich_harris wrote: post #22

Earlier quoted context omitted.

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.

"lean" is not limited to memory though - walking down the vdom reconciliation tree can incur get some pretty large overheads in terms of nested JS calls, just to decide that only a few buttons have to change. PureComponents and things like that are meant to help with this, but it still can take quite a bit of engineering effort to get this right.

Mind you, I don't actually know if Svelte avoids this problem, but a statement like "doesn't depend on virtual DOM reconciliation or anything like that" kind of implies that it defaults to less work.

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

#212

Post by QGmLe »

innocentoldguy wrote: post #127
wcarron wrote: post #32

Earlier quoted context omitted.

Do you have any other frameworks in mind? Ones that easily and concisely hook into the DOM APIs provided by browsers? One that hot reloads in dev? Or maybe just accomplishes even a handful of the 11 targets listed at the beginning of the article? Because I don't know of any. Except maybe the new Rust framework, Yew. Which seems very interesting.

Perhaps you're right, there may not be one. However, I think the point the OP is trying to make is that JavaScript is a shitty language and it would be better to invest some effort in replacing it with something better than to continuously try to "fix" all its inherent shitty-ness over and over again to little avail. Sure, JavaScript isn't as shitty today as it was 10 years ago, but it still isn't a well-thought-out,…

yes. well put

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

#213

Post by fineline »

rich_harris wrote: post #174
fineline wrote: post #168

Earlier quoted context omitted.

Hi Rich, I notice you mention Marko. That was my first thought when checking out Svelte today - Marko uses somewhat similar approach, and thus brings somewhat similar benefits. But Marko has couple of other advantages - beautiful "concise" syntax option, and easy debugging at dev time as the Lasso bundler turns JS modules into equivalent files in the browser, complete with same line numbering. (It only works with Com…

I'd say it's a matter of personal preference as much as anything else. (Personally I'm not a fan of the compact syntax — I prefer just using HTML and CSS, but it's subjective.) Performance-wise, you'll get great results with either framework. You mention debugging — Svelte creates useful sourcemaps, and the generated code is very readable anyway. Svelte has a few features you might find interesting (AFAIK Marko doesn…

Thanks, sounds worth a closer look.

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

#214

Post by Can_Not »

weego wrote: post #120
dbbk wrote: post #97

Earlier quoted context omitted.

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.

So you have 2 versions of the code with a shared contract between the two. Isn't that exactly what the original criticism was, other than in this world your server and client both have packaged code that is likely redundant or at least not a clean abstraction?

We have one version of the client-side code and one version of the backend API code. The server-side code mounts the client-side code like a pure function for rendering on a user's first arrival. You can technically separate the SSR from the API if you want (might even be default in some places). "You have 2 versions of the same code" is a simple misconception from people who still think in terms of jQuery at best, at worst it's intentionally ignorant and misleading.

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

#215

Post by Can_Not »

Touche wrote: post #13
rich_harris wrote: post #11

Earlier quoted context omitted.

In practice, this isn't an issue. Component lifecycle hooks and methods (which is where anything involving raw DOM access or animation takes place) never run on the server — the SSR renderer just generates some HTML for a given initial state. Once you grok that, it's easy. Certainly much easier than maintaining two codebases in parallel!

Then you have a server/client difference if the lifecycle hooks change the dom (like a jQuery plugin or something). So you have to figure out what to do on the server.

If it doesn't make sense to render on server (last child tag for Google maps? YouTube? Calendar datetimepicker?) Then wrap it in a simple tag that has existed for a long time in all major frameworks supporting SSR. Interesting problem, but when it ever rarely actually shows up, it has an obvious, practical, and proven solution.

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

#216

Post by nh2 »

austincheney wrote: post #178
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…

> This is a mistake a lot of developers make. The server and client are not the same. This is the basic value premise of frameworks. Write less code with uniform conventions and make it easy by hiding the complexity. Unfortunately, the premise is faulty. You can only lie to yourself for so long that your ignorance of how things really work is fine because of (name your favorite abstraction). This is a very direct exa…

> The reason for this snowball effect is largely due to a lack of confidence that feeds upon convenience as opposed to examination of why technical problems exist in the first place.

I find this a great answer.

Much time is spent these days on taping over problems at the high level on the top of broken stacks, instead of fixing the underlying issues.

Building on broken foundations will only get you so far and yield diminishing returns, even if it initially looks easy and convenient to just build on top.

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

#217

Post by tboyd47 »

Can_Not wrote: post #214
weego wrote: post #120

Earlier quoted context omitted.

So you have 2 versions of the code with a shared contract between the two. Isn't that exactly what the original criticism was, other than in this world your server and client both have packaged code that is likely redundant or at least not a clean abstraction?

We have one version of the client-side code and one version of the backend API code. The server-side code mounts the client-side code like a pure function for rendering on a user's first arrival. You can technically separate the SSR from the API if you want (might even be default in some places). "You have 2 versions of the same code" is a simple misconception from people who still think in terms of jQuery at best, a…

"2 versions of the same code" is not a very precise description. Either it's one chunk of code or two chunks, or one chunk that extends the other chunk in some way.

What we ended up in my case was one chunk of code (server) that extends a shared chunk (server/client), with plenty of server vs. client branching inside the shared chunk, either on a boolean flag or the presence of some data structure that only exists in one environment.

I have never seen the use case that many people flippantly claim is so easy, which is the "one chunk" concept, nor have I seen a chunk of server- or client-only code extend shared server-client code in a way I would describe as clean. Stuff tends to get messy when you have to deal with the space between the server and the client, like cookies, asset loading, or third-party services, or when you have to do fancy UX tricks. Then users who are used to "traditional" websites do things like refresh the page at weird times, click buttons more than once, load the app from the wrong URL, use the wrong browser, click things too fast, leave a tab open too long, and so on. And then, as others have mentioned, you have sensitive logic that needs to live only on the server for business reasons. Then the framework you're using moves too quickly or not quickly enough to support a browser feature you didn't know you needed until right now. All this stuff only comes in later, once the app meets the ground, and is rarely discussed in initial architecture meetings. The only way I could possibly see these solutions as cleaner than the old "two-chunk" way are if I were to automatically dismiss all those pragmatic concerns or consider them to be cleaner simply by virtue of the fact that they're different.

It's frustrating to me because I see so much optimism on online forums about "Universal" JS as this earth-shaking sea change on the verge of happening, even though honestly it's been 10 years since NodeJS came out and first made Universal possible. It makes me feel a bit like an old fogey for throwing up my hands and saying, "Let's just let it go and stick to the original design of the web," meaning, two chunks. But that's the only way possible for me to deliver the real requirements I have on projects without driving myself crazy.

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

#218

Post by [deleted] »

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!

[deleted]

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

#219

Post by Nemi »

rich_harris wrote: post #156
Nemi wrote: post #111

Earlier quoted context omitted.

> The point is they don’t inherently make user experience objectively worse. Ah, but they do. Browsers are very mature and predictable in their management of html pages and SPA's break that behavior in subtle, uncanny-valley ways. For instance, click into the Sapper HN page https://hn.svelte.technology/item/16052558 , scroll down to a post with a random link and click into it. Click on another page in that link. Now…

> You find that you will be at the top of the page as it re-renders. You lose the place you were scrolled to. What browser is that happening in? In Chrome it works correctly — Sapper uses `history.scrollRestoration = 'manual'` for this exact reason, but maybe it fails elsewhere? It's a bug, and we should fix it. (This is pre-1.0 software, your forbearance is appreciated.)

Way late on this reply, but it was in chrome. I found that an immediate back button would often work, but if the page you were navigating to was overly large or you clicked into another link or two and then went all the way back it would lose place.
Post reply on HN