81–90 of 134 posts
Earlier quoted context omitted.
Not really, I'm the consultant people hire when they need to solve issues like this. There are some screenshots of what we're doing here: http://www.hyperfiddle-consulting.com/ http://hyperfiddle.net/ As I said, our app is sophisticated
Why in the world would you take over scrolling like that Is this how you get your kicks?
Earlier quoted context omitted.
Correct, except that initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.
If all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React. Isn’t that the whole point?
https://css-tricks.com/building-skeleton-screens-css-custom-...
Earlier quoted context omitted.
Modern JS frameworks try to solve this problem by inlining critical CSS and JS into the head for anything above the fold, and loading the rest dynamically.
Which frameworks do this?
Earlier quoted context omitted.
Assuming that your actual use case is rendering one small HTML table, yes. It probably isn’t, though.
OK lets assume it's 30x that do you really think that 300/month for SSR would be an issue for a site serving 400 mil sessions per month?
Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. https://github.com/janit/node-templating-benchmark/pull/1
Earlier quoted context omitted.
OK lets assume it's 30x that do you really think that 300/month for SSR would be an issue for a site serving 400 mil sessions per month?
Is optimizing for cost efficiency a cardinal sin on HN now?
Earlier quoted context omitted.
It's the other way around: you might not (in fact, probably do not) need React. Start with server-side rendering, and move to React if your application's dynamism demands it. Most applications don't. It's painful to see so many websites building huge, slow, JS-rendered monsters for one or two dynamic elements per page. Unless you are Facebook (and have your JS cached within one hop of every internet POP in the world)…
Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for a long time -- the Backbone.js days were painful. It was easy to accidentally leak event binds, code yourself into a corner, etc. The jQuery days were almost better in some ways but still had some real pain points. You missed that I'm working on SaaS and a we…
I didn't miss that. SaaS means "software as a service", and doesn't imply anything about the complexity of your UI. Plenty of SaaS companies use server-side rendering. Likewise, "web applications" were being written long before React was a thing.
Also no, you don't have to do a full server round-trip for every click, any more than you have to send JSON back to your Reactionary UI for every click.
So sure, if you can truly load all of your data in one big JSON blob and do everything else client side, then I guess you're in the 5% of people who can benefit from React. The other 95% should use a good server-side rendering framework and get things like low latency, URL routing, progressive enhancement and SEO-friendly pages for free, and build the few dynamic elements on their pages with a simpler, more robust technology. I never said that React isn't useful, just that it shouldn't be the default choice for most people.
It would be worth verifying that NODE_ENV=production is set during these benchmarks (I see no mention in either the article or the source repository.) Running in development mode has a significant performance impact. Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. https://github.com/janit/node-templating-ben…
Also, the React component is created on each request instead of just being created once. Unless one's goal is to specifically colour the perception of React, I don't understand that decision alongside the code for Pug which precompiles the template a single time.
(Also declaring the map function outside the component and not creating a closure makes for a tiny extra boost.)
It's disappointing to see that the article took off to this extent given how misleading and inaccurate it is.
OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
Max RPS equals number of users you can serve per second. Concurrency should just be tweaked until you eliminate the network latency of your test framework.