Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

181–190 of 756 posts

Re: If not React, then what?

#181

Post by Cotterzz »

QuiDortDine wrote: post #7

WOW this is a long article! Still waiting for the substance though... The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient. Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tel…

Between modern frameworks and that MS born monstrosity Typescript, I thought this was the JS-free web. I would love to see the back of it. Web Dev seems to be ignoring the last 10-15 years of new native browser technologies and getting really stagnant with proprietary bloat as a result. It's a really good time to start from scratch and see what we can do with WebGL/WebGPU/Shaders, WASM(C, C++, Rust Etc) and Web Audio, as well as the new features of Vanilla JS

Re: If not React, then what?

#182

Post by MarcelOlsz »

zmmmmm wrote: post #172
MarcelOlsz wrote: post #145

Earlier quoted context omitted.

You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.

I'm having trouble forgiving Vue for the backwards compatibility issues and short support period from Vue 2.x => Vue 3.x. I'm now faced with unnecessary cost to upgrade line of business apps built with Vue that in full maintenance mode but now have critical security vulnerabilities popping up in scanners with no way to fix them other than large scale code migration. I saw they are now dropping support for Vue 2 even…

That's actually fair and my one gripe with Vue, and I just spent the past week and a half porting over my old project that I wanted to resurrect. If they screw with my vue3 using composition API then I'll dust off my pitchfork.

Re: If not React, then what?

#183

Post by root_axis »

cyberax wrote: post #164
goobert wrote: post #149

Earlier quoted context omitted.

React is in use in many heavily used frontends at Amazon, maybe not the retail site But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site

My constant problem with React-based tools is that they don't support deep links properly. You want to right-click on a product description to open it in a different tab to check later, and you can't. Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.

I'm not sure how much experience you have with react, but it doesn't need to "support" links, they function exactly the same as with vanilla js, there's nothing about react that prevents their use. Using JavaScript for links is entirely a developer decision.

Re: If not React, then what?

#184

Post by quantadev »

floydnoel wrote: post #139
baobabKoodaa wrote: post #111

Earlier quoted context omitted.

If you have trouble imagining, here's one such project: https://github.com/baobabKoodaa/ouija

I have a lot of "framework free" single-developer projects as well (such as https://bongo.to ), but that isn't really what I think we are talking about here. Single developer projects can do whatever they want, it isn't a problem. The problem comes when you have to work with distributed teams, juniors, etc. One way or another a large team still has to come to agreements about how to do things, and without an external…

I absoluetly agree with your sentiment, and furthermore in projects as large and mature as mine, with 500K LOC (about maybe 30% in TypeScript) lots of times I simply cannot remember enough about my code to effectively refactor it from memory without type safety (to check me) and IDE refactoring to DO the refactoring.

I mean if I need to change a variable name in a class or something, unless it's a perfectly unique name (easily searchable), it would take me hours to do in JS what I can do in 4 seconds with TypeScript.

Re: If not React, then what?

#185

Post by lopatin »

MarcelOlsz wrote: post #178
aerhardt wrote: post #166

Earlier quoted context omitted.

But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem? And perhaps most important of all: it's the tool we know.

I only responded because they said they're using vanilla React which for some reason in my head instantly translated to "old version of React before it started sucking", and replied accordingly. >But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem? Yeah fair enough.

By vanilla React I meant that I don't use the new Next.js / SSR stuff and instead build a JS file.

Re: If not React, then what?

#186

Post by MarcelOlsz »

lopatin wrote: post #185
MarcelOlsz wrote: post #178

Earlier quoted context omitted.

I only responded because they said they're using vanilla React which for some reason in my head instantly translated to "old version of React before it started sucking", and replied accordingly. >But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem? Yeah fair enough.

By vanilla React I meant that I don't use the new Next.js / SSR stuff and instead build a JS file.

Yeah I only realized that later :P

Re: If not React, then what?

#187

Post by qudat »

> 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 the various Product teams.

These products benefit from being an SPA. Preload and fetch is such an incredible paradigm for speed and interactivity that every company I’ve worked for has appreciated. Company employees are not trying to run their work browsers without JS nor do they even have to particularly worry about mobile support. It’s a very predictable environment: office, work laptop, internet that can support video calls, and a modern browser. That’s the operational stack that many businesses require.

> The predictable consequence are NPM-algamated bundles full of redundancies like core-js, lodash, underscore, polyfills for browsers that no longer exist, userland ECC libraries, moment.js, and a hundred other horrors.

People really love to hate on npm without trying to understand the reason why it exists in its current form: https://bower.sh/my-love-letter-to-front-end-web-development

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. Next.js is a react framework and as a React expert it’s something I have zero interest in using.

I could keep going but these arguments have been argued and counter-argued before. For a different spin on the success of react: https://bower.sh/react-is-bad-because-its-great

Re: If not React, then what?

#188

Post by johnfn »

qudat wrote: post #187

> 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…

I agree with most of what you said. As a minor nit, my understanding is that you call into a library, whereas a framework calls into you. Since React typically does most of the calling into my components I think it’s fair enough to call it a framework.

Re: If not React, then what?

#190

Post by aaronblohowiak »

johnfn wrote: post #168

Reading 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…

>React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend.

Respectfully, I disagree on all of these points.

Post reply on HN