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

51–60 of 219 posts

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

#51

Post by deno »

Some bullet points are missing from the “perfect framework” list:

1. SSR must support streaming

2. SSR must work in a service worker (so in fact you have 3 targets: server, client/hydration, client/service worker)

3. All work that can be offloaded to a WebWorker must be offloaded

4. Navigating to subsequent pages must support prefetching, including dynamic data (Next.js doesn’t even tell you how to do it)

5. Navigating to subsequent pages SHOULD support prerendering (offscreen) where it makes sense, but…

6. MUST support FLIP-style transitions[1].

Which does mean prerendering anyway for about 100ms at least so the layout can stabilize and cached images load into memory.

For long pages you need to split them into chunks/sections and only animate the part that gets shown (usually above fold).

[1] http://www.pocketjavascript.com/blog/2015/11/23/introducing-...

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

#52

Post by goatlover »

megaman22 wrote: post #48
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.

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 o…

Are they going to also teach that at bootcamps?

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

#53

Post by rich_harris »

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…

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!

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

#54

Post by [deleted] »

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!

[deleted]

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

#55

Post by RobertRoberts »

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.

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.

Shadow DOM is around the corner, what then?

The reason this stuff gets popular is not because it's a good idea, it's because big companies have tons of cash and man power and can't wait for browsers to get updated. Well, a lot of us code monkey vets are done chasing "shiny crappolla", and we can wait a bit until the dust settles.

How many JS frameworks are there now? I saw all of them come, where is ember, knockout, etc...? Vue just popped up, and I can't even recall the other 5 I tried out at the same time. Which will succeed? When you have to put real money into a project and the framework matters to your clients budget, and your profitability, you can't make a risky bet and expect your client to pay for it later if you are wrong.

I am all for the long term now. Show me how a 1 year old framework is a good investment, I am willing to learn something. (keep in mind React is only about 4.5 years old, Angular is only 15 months old (AngularJS is 7 just years old and already being phased out!))

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

#56

Post by digitaltrees »

whome2 wrote: post #4
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…

Massive amounts of business were also built on Angular 1.x but it is no longer supported. To be honest, I am tiring of seeing a new javascript framework everyday. I am pretty sure I saw a post for something called StimulusJs in the last hour and now this.

Actually the nice thing about stimulus is that it is deliberate in ignoring the hype cycle. It works with Turbolinks and rails core to add the small but missing interaction from a traditional ssr framework.

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

#57

Post by rich_harris »

deno wrote: post #51

Some bullet points are missing from the “perfect framework” list: 1. SSR must support streaming 2. SSR must work in a service worker (so in fact you have 3 targets: server, client/hydration, client/service worker) 3. All work that can be offloaded to a WebWorker must be offloaded 4. Navigating to subsequent pages must support prefetching, including dynamic data (Next.js doesn’t even tell you how to do it) 5. Navigati…

This is an excellent list, thank you. To answer some of the points:

Sapper supports partial streaming of server-rendered HTML (typically you'll get most of the while it's fetching data for your page, unless there's no dynamic data in which case you get the whole lot instantly).

I'm not convinced there's actually a benefit to 'server' rendering in a service worker as opposed to serving a shell page. We have an issue for it though! (https://github.com/sveltejs/sapper/issues/22)

Sapper supports prefetching (including of dynamic data) of subsequent pages — just add rel=prefetch to elements (we'll add a programmatic way to do this in future as well).

As for the rest, some of it is app-specific, some of it is stuff the framework could help with. We're not at version 1 yet, so bear with us :)

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

#58

Post by digitaltrees »

azangru wrote: post #36
whome2 wrote: post #4

Earlier quoted context omitted.

Massive amounts of business were also built on Angular 1.x but it is no longer supported. To be honest, I am tiring of seeing a new javascript framework everyday. I am pretty sure I saw a post for something called StimulusJs in the last hour and now this.

Stimulus.js is first and foremost for Rails devs. Not very interesting for the rest of us.

You can use it with Turbolinks without rails. I have seen elixir and laravel devs using Turbolinks, not sure if they will adopt stimulus too but I suppose they could.

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

#59

Post by rich_harris »

dfabulich wrote: post #47

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 s…

Sapper supports partial streaming if you have data that needs to be loaded asynchronously (i.e. you'll get most of the immediately, then other stuff later), but it doesn't currently do what you suggest (such as loading a while is pending). That's something that we intend to tackle in future, though hydrating pages with async data dependencies is a hard problem.

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

#60

Post by dmitriid »

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({
      data: {
        count: 99
      }
   });

   ...then {{count}}, or counter.get('count')
Why is it `counter.get('count')`? WTF?

Or just the section on computed properties[1]: oh, it's no longer even Javascript. It's some magic Javascript-like scripting language that gets injected with properties based on what you write.

Much like in Vue data, properties, and methods are magically hoisted up to the object breaking everything you learned about Javascript:

  export default {
    methods: {
      say: function ( message ) {
        alert( message ); // again, please don't do this
      }
    }
  };

  // and then

  import MyComponent from './MyComponent.html';

  var component = new MyComponent({
    target: document.querySelector( 'main' )
  });

  component.say( '' );
Why the hell is `.say` a top-level method now?

And so on and so forth.

[1] https://svelte.technology/guide#computed-properties

Post reply on HN