It's worth watching the video to understand the context: https://youtu.be/V8oTJ8OZ5S0?t=1012
Definitely worth it just to learn about the prefetch API and the XHR prefetch technique
Netflix: Removing client-side React.js improved performance by 50%
81–90 of 172 posts
Re: Netflix: Removing client-side React.js improved performance by 50%
#82I was at the All Things Open conference this week, and Yehuda Katz gave a talk on Glimmerjs[0]. It was enlightening. The size of your front-end application is generally dominated by view code. So, they precompile views into a super simple set of binary VM instructions (making your views very compact). These views don't go through the JS compile / parse phase on the client (saving hundreds of ms, up to seconds on slow…
That's pretty exciting. I'm curious when we can just compile our views into some IR or byte code that can be natively run. Isn't that kinda what WASM is trying to do?
Re: Netflix: Removing client-side React.js improved performance by 50%
#83I was at the All Things Open conference this week, and Yehuda Katz gave a talk on Glimmerjs[0]. It was enlightening. The size of your front-end application is generally dominated by view code. So, they precompile views into a super simple set of binary VM instructions (making your views very compact). These views don't go through the JS compile / parse phase on the client (saving hundreds of ms, up to seconds on slow…
Considering the various components of the front end stack - increasing the number and depth of the turtles is a win now? That lady was right - turtles all the way down!
If you can get all three of these-- good performance, simple application code, and a rich UI experience-- then yes, it's a win.
Re: Netflix: Removing client-side React.js improved performance by 50%
#84Earlier quoted context omitted.
Bad UX and buggy implementation can also cost a company customers and conversion. Sometimes the trade off is worthwhile.
You can't lose customers you never converted in the first place. Does React really eliminate the potential for buggy implementations? Also I'm fairly certain that UX has more to do with design than your choice of frameworks.
You also have to consider what side benefits libraries provide. Eg, we're likely choosing React (first time in company using React) because we're choosing React Native for our mobile apps. This is because we're a very tiny shop, with very limited developers. We simply don't have the manpower to hire or learn both Android and iOS development.
Now, we reviewed a handful of iOS/Android abstractions, and React Native seemed competent - so we're using it for our first pass. Likely, we'll use it for the web frontend too, because we're using React Native. More familiarity can be a good thing.
As I discussed internally when we were choosing frameworks, if I was just choosing a web frontend it would never be React. It's not that I think React is bad, it's just that there are a dozen frameworks similar to it that are faster. It popularized a new good idea (vdom), but it's just not best in breed imo. Yet, having the same concepts and very similar codebase between mobile apps and frontend is a pretty big deal for us.
Re: Netflix: Removing client-side React.js improved performance by 50%
#85We learned this hard way :P We avoid fancy tools as much as possible and use basics as much as possible. Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern stuff. Easy to implement, deploy and manage. P.S. Use knife which you really need. Try to use simple knife as much as possible.
> Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern stuff.
It's interesting to remember that Facebook started out as a PHP application. I imagine that Facebook's original tech stack closely resembled the stack you're recommending. And scaling that stack is what led to the creation of React. If you choose to build a rich user interface (like Facebook or Netflix) on top of that stack, you will likely find yourself creating abstractions to manage the complexity. Those abstractions will be equivalent in their utility to React, Ember, Angular, etc.
I agree that a website does not always need or benefit from a React or an Ember. Small dynamic behaviors behaviors can be implemented with less powerful tools. But, the power of your abstractions will need to scale with the complexity of your UI behavior. That's why, at a certain point, the abstractions provided by React _are_ the right choice and jQuery is not.
Regardless, the slide featured in this tweet does not comment on React working or not working well. As they say in a reply to that tweet, the application still loads React and renders React components. What they are presenting is an interesting optimization that has to do with the unique performance constraints of Netflix's UI.
Re: Netflix: Removing client-side React.js improved performance by 50%
#86I was at the All Things Open conference this week, and Yehuda Katz gave a talk on Glimmerjs[0]. It was enlightening. The size of your front-end application is generally dominated by view code. So, they precompile views into a super simple set of binary VM instructions (making your views very compact). These views don't go through the JS compile / parse phase on the client (saving hundreds of ms, up to seconds on slow…
If I'm not mistaken Angular 2+ also has this. It's named AOT compilation (ahead of time).
Edit: so does Vue if you're using vueify (https://github.com/vuejs/vue/issues/4272).
Re: Netflix: Removing client-side React.js improved performance by 50%
#87Earlier quoted context omitted.
FYI, vanilla.js is a thing now. Some asshole made it a thing. http://vanilla-js.com
Default choices on that page show the following file size: Final size: 0 bytes uncompressed, 25 bytes gzipped.
Yeah, but it bloats up considerably when you add in the other features.
Re: Netflix: Removing client-side React.js improved performance by 50%
#88I was at the All Things Open conference this week, and Yehuda Katz gave a talk on Glimmerjs[0]. It was enlightening. The size of your front-end application is generally dominated by view code. So, they precompile views into a super simple set of binary VM instructions (making your views very compact). These views don't go through the JS compile / parse phase on the client (saving hundreds of ms, up to seconds on slow…
If I'm not mistaken Angular 2+ also has this. It's named AOT compilation (ahead of time). Edit: so does Vue if you're using vueify ( https://github.com/vuejs/vue/issues/4272 ).
It's not the same, though. Those are compiling textual templates into executable JavaScript. React/Preact do this automatically, too.
What Glimmer does is it converts your views into bytecode (not JavaScript) which can be streamed and run without a JavaScript compilation / parsing phase in the browser. Vue, React, and Angular views all ultimately are translated into JavaScript which has to be compiled / parsed in each browser.
Re: Netflix: Removing client-side React.js improved performance by 50%
#89Earlier quoted context omitted.
I don't know why you'd use such heavy duty applications for such a simple use case. I merely use a butterfly to induce cosmic rays to flip the bits of memory needed to send a http request.
A butterfly is way more complex than React.js.
How true, in fact butterflies are more complex than all software put together :P you just broke that whole branch of xkcd jokes dammit!
Re: Netflix: Removing client-side React.js improved performance by 50%
#90Earlier quoted context omitted.
I've see this go down before. React was the wrong choice but I'd put the blame right at the feet of the consulting firm. Let me guess, the budget was under $5M but the firm was one of the large ones probably being used elsewhere in the company right? I work for a very very large consulting firm, anything under $30M is not worth getting out of bed for them. Projects like this get staffed by nobodies and run by nobodie…
I'd put the blame on the manager for not knowing better. I mean s/he is the gatekeeper for company resources.
Most middle managers at large companies are totally clueless. Consulting companies are built to take advantage of them and drain their budgets.