Earlier quoted context omitted.
They don't say "I'm sick of React websites," they just say "Wow websites are getting slower and slower." or they complain about specific tabs or just the browser in general sucking up tons of RAM and CPU.
I’m also aware they won’t make the direct references and I’m willing to bet the OP is too. There are very few instances I can think of for the last 4 years where I heard anyone complaining like this about the general state of these things. There’s a few offenders I can think of, like Salesforce, but I haven’t heard from any non technical users especially about things like Gmail being slow or their browsers being too…
If not React, then what?
531–540 of 756 posts
Re: If not React, then what?
#532Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…
Ironically the first question you ask is the question people should be asking about React. Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief. Likely many developers don’t even know how to build something without React. They don’t kn…
> Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.
The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.
> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along
Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.
Re: If not React, then what?
#533Earlier quoted context omitted.
API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" sho…
> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. I really hope nobody takes this "advice". What are you trying to save me from?
I'm not trying to save you from anything. Stop being dramatic. I honestly don't care what you do or what advice you take.
Re: If not React, then what?
#534Earlier quoted context omitted.
Wow. I've never seen anyone make a sky-is-falling argument about Javascript to this level before. Bravo? /s? Either way it's an impressive reach.
If you're a large hosting provider like a Google or a Microsoft or an Amazon or a CloudFlare, you want to be eco. You want to be eco for PR reasons, for financial reasons, and for practical engineering reasons. Slow scripting languages don't make you eco. You have to think bigger.
Yes, let's save the electrons so we can mine bitcoin with them. /s
oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s
You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just looney tunes crazy. Sorry, it just is.
Re: If not React, then what?
#535I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
> React will be unseated like jQuery got unseated when someone makes something that looks nicer. The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want. No more JavaScript limitations.
> The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want.
OK and then how do I do my form UI on that codebase?
When at all possible I write stuff in Scala, using Scala.js when it needs to run in the browser. But I still use React for the UI part.
Re: If not React, then what?
#536It sounds like the author is complaining more about SPAs than the React itself.
Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
Re: If not React, then what?
#537It sounds like the author is complaining more about SPAs than the React itself. Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
Nobody needs an SPA, it’s a stylistic choice, not a need.
Re: If not React, then what?
#538I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
I call that "developer happiness". It's extremely subjective but yeah, writing and then maintaining React code makes me the most happy in the best case scenarios, makes me feel like I can do more with less, it's easy for me to read and design. I feel like I have more friction with other JS tools.
Re: If not React, then what?
#539> The choice isn’t between JavaScript frameworks, it’s whether SPA-oriented tools should be entertained at all. For most sites, the answer is a clearly “no”. “Most sites” sit in the world of marketing, ecommerce, blogs. True, they don’t need an SPA. Then there are businesses that “require” highly dynamic websites with tons of data funneling through them. I use require here in the sense of business requirements set by…
> As a semantic aside, I wince when people call React a framework. If we think of an SPA in terms of an MVC framework, it primarily handles the V. So really it’s a view library since developers can use whatever M and C they want.
React isn't a library, it's a framework. A narrowly focused framework perhaps, but a framework nonetheless: it has to control the event loop and you have to follow its special rules (hooks), you can't just call into it like vanilla code.
Re: If not React, then what?
#540It sounds like the author is complaining more about SPAs than the React itself. Indeed, if your needs are more static, a SPA is probably not a good solution. But if you really do need a SPA, React is a sensible choice and can perform well assuming good engineering.
Nobody needs an SPA, it’s a stylistic choice, not a need.
Ugh, that's just the fundamentalistic, non-engineering approach that we need less of.
Everything is a trade-off, and SPAs offer a trade-off that is right for some cases and wrong for others.