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

11–20 of 219 posts

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

#11

Post by rich_harris »

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…

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!

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

#13

Post by Touche »

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

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.

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

#14

Post by rich_harris »

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.

The server is only involved when you first hit the page. After that, the client takes care of all the rendering. There is no discrepancy!

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

#16

Post by mike-cardwell »

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…

In Universal React based apps, some of the lifecycle methods only run on the client side, e.g componentDidMount. So you just perform client-side-only functions there. There's also react-no-ssr - https://www.npmjs.com/package/react-no-ssr.

It is an issue, but one that is really easy to handle.

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

#18

Post by DougWebb »

Sorry, I couldn't resist. Second and third paragraphs, with some minor editing:

HTML is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at https://www.w3schools.com/html/. HTML introduced a brilliant idea: all the pages of your app are files in a your-project/pages directory, and each of those files is just an HTML page.

Everything else flows from that breakthrough design decision. Finding the code responsible for a given page is easy, because you can just look at the filesystem rather than playing 'guess the component name'. Project structure bikeshedding is a thing of the past. And the combination of SSR (server-side rendering) and code-splitting — something the React Router team gave up on, declaring 'Godspeed those who attempt the server-rendered, code-split apps' — is trivial.

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

#19

Post by nailer »

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…

I think I've been using Rixh's previous project, Ractive, onr of the first virtual DOM implementations, for 4 years now. It has a decent community and good stack overflow love.
Post reply on HN