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

41–50 of 219 posts

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

#41

Post by dbbk »

mike-cardwell wrote: post #16
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.

The same applies to Ember apps as well. Honestly, this is not an issue.

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

#42

Post by scottmf »

RobertRoberts wrote: post #37
rich_harris wrote: post #23

Earlier quoted context omitted.

If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.

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…

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.

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

#43

Post by dbbk »

chaostheory wrote: post #12

Is there a reason why most Javascript web frameworks, like this one, tend to ignore relational databases? hmm, I don't even see a mention of how to integrate any datastore with Sapper or did I miss something?

> Is there a reason why most Javascript web frameworks, like this one, tend to ignore relational databases?

Yes, because these are frontend frameworks and that is a backend concern.

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

#44

Post by LeonM »

kiernanmcgowan wrote: post #39

Question: > 1. It should do server-side rendering, for fast initial loads and no caveats around SEO Is server-side rendering still an issue for SEO? Don't major search engines evaluate pages now so that SPAs can be indexed?

I can confirm that Google can crawl SPA's like any other page. But do note that they crawl using Chrome 41 (!) so make sure you have sufficient polyfills in place.

This also applies for AdWords, it drove me mad when Google kept insisting my site was not reachable, even though it was.

Only after installing a client-side exception tracking tool (like raygun or errorception) I found out the page was not rendering on the 'old' browser Goolge uses internally.

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

#45

Post by ashelmire »

"This framework is 95% ideal, let's build another framework for my personal 5%."

This attitude is why we have a hundred different relevant frameworks right now. How about instead of a building a new framework, you contribute to an existing one? You even say that Next is close to what you want... why not help to make it better?

Relevant song about this issue: https://www.youtube.com/watch?v=Wm2h0cbvsw8

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

#46

Post by tboyd47 »

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 your code is executed. You'll have pieces of code written and rewritten again and again and executed several times just to make sure it gets called in the exact moment, with the exact arguments you need, at least once.

I spent many years in search of "universal" JS, and worked with many people who were convinced they had found El Dorado, yet always ended up in situations like I described, so maybe I'm jaded.

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

#47

Post by dfabulich »

I think the major missing principle on this list is "streaming." (This is missing in Next, too.)

The server should send down parts of the page as soon as their data becomes available. Typically, pages have a "header" section that requires no data at all, and the server should render it instantly and stream it to the client. Then there's typically some fast-loading "above-the-fold" data; the server should render and stream that as soon as it's ready. Beyond that, there's other below-the-fold components, which may load/render more slowly. The server should render those as they come in.

Then, the magic technique is to progressively attach event listeners to components as they stream in, so you don't have to wait for the whole page to load to be able to interact with above-the-fold components.

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

#48

Post by megaman22 »

scottmf wrote: post #42
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…

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.

Possibly a lot of HN has been around the block for a couple of decades at this point, and has seen this web dev stuff come full circle several times, and before that, the same ideas in desktop software.

Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Maybe we can get away from rehashing the same cycle of trends every five years and move onto some different wheels.

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

#49

Post by rimliu »

scottmf wrote: post #42
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…

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.

Or it may well be that this "all new web tech" was created by people who do not understand neither web nor HTML. Sudenly everything needs to be SPA, every site needs to load hundreds KBs of scripts just to "be current". What's the value of being modern if it makes user experience objectively worse? Sure client side render may prevent you from reloading the entire page. And who cares that this rerender actually takes longer than reload? Did I really need to waste 200KB of my mobile data to load scripts all I wanted to see were 5 pages each weigthing 5KB? What did I gain from trading full reload for the a-la-SPA kind of deal?

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

#50

Post by lcfcjs2 »

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…

I completely agree. These 2 layers must be separated, by the HTTP protocol.
Post reply on HN