131–134 of 134 posts
Earlier quoted context omitted.
What is the scroll bug exactly, or are you referring to the perf problems?
On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling; the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
Earlier quoted context omitted.
our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratc…
No need to try to explain why you think it is slow based on your understanding of React. Facts are always better. Good news is: I suspect you have no React issue. How is your NODE_ENV? Set to production? After looking at your website, you have no perf issue caused by React itself! Remove the blinking cursor made with setInterval, and use CSS animation for that. You'll see :)
That link has the data points you are looking for, react SSR problems are well understood and documented and have been for some time now, that repo is a year old
also see https://www.reddit.com/r/reactssr/
Earlier quoted context omitted.
What is the scroll bug exactly, or are you referring to the perf problems?
On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling; the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
Earlier quoted context omitted.
"It's not an ugly hack at all. It works well" URLs are addresses of resources on the internet. They're parsed by your browser to request resources on another server. If you've rewritten this functionality in JavaScript to support storing application state in your single-page application, it may "work well" but it is, in fact, a hack. If you've done this to support storing application state in your web application tha…
I haven't written this functionality in, it's a browser API: https://developer.mozilla.org/en-US/docs/Web/API/History_API https://html.spec.whatwg.org/multipage/history.html#history None of these arguments are for a specific stack. React has little to do with any of this. We're talking about underlying technologies that enable the web to be used as a platform for application development. My point about an ORM is that…
"My point about an ORM is that your API becomes so simple you don't require a lot of complexity that is required with server-side joins of data in order to render a view. That is gone. No need."
Yeah, I understood your argument the first time you said it, just couldn't believe you were making the argument. If you don't like joins (related: why do you think you need an ORM to join?), don't write your server-rendered endpoints to use them. The one technology has nothing to do with the other.
That said, as soon as you want to achieve reasonable performance and scale, you will rather quickly find it essential to return multiple pieces of data in a single API call.