4 ms·

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

by pwaai 9y ago

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.

mlsarecmg 9y ago
You can boil down react to virtually nothing. preact-compat turns it into 4kb. Redux + router don't add that much. The loading impact, if you watch out, code split, isn't the dire problem. As for laggy experience, Fiber is the only feasible attempt at the moment to actually tackle it. Microbenchmarks will not help and neither Svelte nor anything else will make a webapp fast on a slow phone as baseline diffing has never been the problem in the first place. The problem is and has been the dom and the single threaded handling of it. Fiber will allow apps to schedule. Imagine an app with 100.015 rows that Svelte renders in, say, 500ms, let it be 10ms faster than React 15's 510ms. It would still eat into your frame budget and cause heavy jank like all web apps do. Fiber just wouldn't render the 100.000 rows that don't fit your phones screen finishing the whole op under a single ms. It culls and prioritizes similar to how virtual lists operate in general, but you get that as a first class primitive being able to defer any render call of lesser importance without causing visual distortion or code complexity. Not to mention that with React you could actually produce a real native app, while redux would allow you to share most of your code. With something like react-native-web you could even write a universal app being able to render both in the web and natively.
- leeoniya 9y ago
  > Imagine an app with 100.015 rows i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the proper solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fastest way to render this is simply not to. it's not as if suddenly you don't have to worry about the shitty UX and performance of your app's architecture "because fiber".
  - boubiyeah 9y ago
    Haha yeah. The magic of green threading is so misunderstood: Ok, it no longer blocks your UI thread but it takes AT LEAST as long as before to render (browsers still don't have an API to reliably schedule small chunks of work without also incurring the cost of setTimeout clamping) So it's not really an improvement for me, your component tree becomes harder to reason about (when does this component renders??), you may see very unwanted progressive rendering where you didn't want to, etc. Many vdom implementations are faster than React, synchronous perfs matter a lot too. Even the core React maintainers acknowledge this is kind of like an experiment.
  - mlsarecmg 9y ago
    The list is an example, the cheapest one to make it understandable. Let it be 2000, or 100, filtered and pre-processed. It would still take longer than the 15 the user actually sees. The point isn't the list, but the primitive. I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in C# forever - it is a great tool to have and getting it for the web is a major step. Microbenchmarks that measure baseline deletes/adds/changes will simply not result in apps that feel native. Thinking framework xyz will just feel acceptable to mobile users because Krausest says it takes 1ms less adding 100.000 rows, that is just silly.
    - GordonS 9y ago

by pwaai 9y ago

mlsarecmg 9y ago

You can boil down react to virtually nothing. preact-compat turns it into 4kb. Redux + router don't add that much. The loading impact, if you watch out, code split, isn't the dire problem. As for laggy experience, Fiber is the only feasible attempt at the moment to actually tackle it. Microbenchmarks will not help and neither Svelte nor anything else will make a webapp fast on a slow phone as baseline diffing has never been the problem in the first place. The problem is and has been the dom and the single threaded handling of it. Fiber will allow apps to schedule. Imagine an app with 100.015 rows that Svelte renders in, say, 500ms, let it be 10ms faster than React 15's 510ms. It would still eat into your frame budget and cause heavy jank like all web apps do. Fiber just wouldn't render the 100.000 rows that don't fit your phones screen finishing the whole op under a single ms. It culls and prioritizes similar to how virtual lists operate in general, but you get that as a first class primitive being able to defer any render call of lesser importance without causing visual distortion or code complexity. Not to mention that with React you could actually produce a real native app, while redux would allow you to share most of your code. With something like react-native-web you could even write a universal app being able to render both in the web and natively.

leeoniya 9y ago
> Imagine an app with 100.015 rows i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the proper solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fastest way to render this is simply not to. it's not as if suddenly you don't have to worry about the shitty UX and performance of your app's architecture "because fiber".
- boubiyeah 9y ago
  Haha yeah. The magic of green threading is so misunderstood: Ok, it no longer blocks your UI thread but it takes AT LEAST as long as before to render (browsers still don't have an API to reliably schedule small chunks of work without also incurring the cost of setTimeout clamping) So it's not really an improvement for me, your component tree becomes harder to reason about (when does this component renders??), you may see very unwanted progressive rendering where you didn't want to, etc. Many vdom implementations are faster than React, synchronous perfs matter a lot too. Even the core React maintainers acknowledge this is kind of like an experiment.
- mlsarecmg 9y ago
  The list is an example, the cheapest one to make it understandable. Let it be 2000, or 100, filtered and pre-processed. It would still take longer than the 15 the user actually sees. The point isn't the list, but the primitive. I don't even know where the scepticism comes from, culling and priotization is normal on the desktop. You've been offloading UI related tasks that could interrupt animations or interactions in C# forever - it is a great tool to have and getting it for the web is a major step. Microbenchmarks that measure baseline deletes/adds/changes will simply not result in apps that feel native. Thinking framework xyz will just feel acceptable to mobile users because Krausest says it takes 1ms less adding 100.000 rows, that is just silly.
  - GordonS 9y ago