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

561–570 of 756 posts

Re: If not React, then what?

#561

Post by proto-n »

qudat wrote: post #227
johnfn wrote: post #188

Earlier quoted context omitted.

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.

That’s a nice description but it is not perfect. React does one thing well: view = func(state) It doesn’t have a great story for virtually anything outside of that single function which means for many large apps it is never enough.

It seems you only want to call MVC frameworks frameworks? But there's millions of other types of frameworks for thousands of purposes. Framework is a generic term (for which the definition is usually the calls into you/you call into it thing). What it does and whether it's a framework is two completely orthogonal things.

Re: If not React, then what?

#562

Post by throwaway2037 »

eastbound wrote: post #491
LegionMammal978 wrote: post #459

Earlier quoted context omitted.

> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really s…

I generate a report in our software and 70.000 cells work like a breeze (1000 rows, 70 columns). React just can’t handle adding an input to a cell. It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie. React is better than all predecessors, but it’s still the wrong abstraction.

What about AG Grid? We have apps at work with 1M+ cells. I am pretty sure that AG Grid has React support.

Re: If not React, then what?

#563

Post by gf000 »

hmeh wrote: post #476
vessenes wrote: post #458

Earlier quoted context omitted.

Meh. What is that self-evident alternative supposed to be? I ask as someone who crafted HTML with my father's lisp parens on computers running linux kernels which were still delivered with the pl suffix, and as someone who occasionally still occasionally tries to deliver frontend code, much to my dismay. I've made websites in so many stacks and varieties that it would be intensely boring to list or read them, and I h…

Meh, indeed :) Thank you for your response, it's a fair question and critique. It'd be rather challenging to write guidance on which technology to use to build an application. Thorough guidance would need to consider far too much. You wouldn't have a tome, you'd have an anthology. You'd have to consider what is being built and by whom at the very least. It becomes "self-evident" when you have enough knowledge and exp…

So now you have two, entirely separate worlds that don't compose in any way, and you have to create "DTO"s to convert from one to the other and back.

Don't get me wrong, I would much prefer coding in a single language for both backend and frontend, and I would not choose JS/TS for that. But your choice is that, only a decent choice. Just like react is. There are so many ways to do web development, and neither of these are fundamentally bad.

Specific applications of these architecture/designs on the other hand can be catastrophic in both cases, and I'm sure most of us has been burnt by these (e.g. for SSR, I have seen code that sent back HTML segments that reused IDs. With dynamic JS it was a pain to hunt down these errors. But there is an entire field dedicated to all the vulnerabilities that have historically been opened up by careless backend devs).

Re: If not React, then what?

#564

Post by gf000 »

slotrans wrote: post #466
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. Many years ago I worked at a wonderful company that made the terrible decision to rebuild the frontend in React. We had a performance dashboard permanently displayed on a TV in the office, prominently showing the p99 time-to-interactive of our home page. It sat at TWENTY SECONDS for at least 2 years. No progr…

E-commerce sites are a pretty good fit for SPAs. Sounds like a bad rewrite, nothing more, nothing less.

Re: If not React, then what?

#565

Post by ricardobeat »

leptons wrote: post #559
RedShift1 wrote: post #542

Earlier quoted context omitted.

I'm with albedoa on this one. Loading things only when you scroll to them makes for a terrible scrolling experience.

You obviously didn't read what I wrote or understand it. I specifically said this: > Sure you can load scripts in-line for stuff below the fold, but make sure it doesn't actually get parsed by the browser until that feature is likely to be visible on the screen. " I specifically said you could load a script in-line for stuff "below the fold" as long as the browser doesn't parse it until it's used. That's very differe…

You also said

> We use a "loading" spinner

> users can wait an extra second [every time they scroll to load new content]

which is exactly the bad experience the commenters above are talking about.

They understood your comment, and they disagree. This is not the good advice you think it is, unless your main goal is to score 100 on lighthouse for SEO purposes, not UX.

Re: If not React, then what?

#566

Post by baobabKoodaa »

quantadev wrote: post #468
baobabKoodaa wrote: post #389

Earlier quoted context omitted.

The question in this thread is not TypeScript vs JavaScript. It's framework vs no-framework. Specifically, is it possible - possible at all - to create an interactive web app without frameworks - one that isn't "just a document" or "brochure-ware". I've demonstrated pretty clearly that yes it is possible. You people just keep shifting the goalposts further and further... Now it doesn't count unless it's 50K LoC? As i…

I never saw anyone on this thread deny that JS CAN be used without frameworks. As a developer since before the internet even existed I've written probably at least two to four million lines of JS in my life, so I'm well aware. What people are saying is that for LARGE projects you NEED a framework. And your app is tiny. It's got like two source files. So it's just an example of a tiny project getting by without a fram…

> I never saw anyone on this thread deny that JS CAN be used without frameworks [...]

https://news.ycombinator.com/item?id=42282054

"brochure-ware"

B-R-O-C-H-U-R-E-W-A-R-E

Re: If not React, then what?

#567

Post by ricardobeat »

gf000 wrote: post #556
archerx wrote: post #504

Earlier quoted context omitted.

React sites still feel janky on my 24cores and 48gigs or ram. Which is impressive for all the wrong reasons.

Which react sites? Are you sure you are not a victim of confirmation bias? How often do you check what framework does a smooth and performance website uses? Because demo sites are snappy on even low-end devices. It's not react itself that causes slowness, but all the other libraries/tracking/ads.

This answers your questions: https://astro.build/blog/2023-web-framework-performance-repo...

Re: If not React, then what?

#568

Post by baobabKoodaa »

quantadev wrote: post #468
baobabKoodaa wrote: post #389

Earlier quoted context omitted.

The question in this thread is not TypeScript vs JavaScript. It's framework vs no-framework. Specifically, is it possible - possible at all - to create an interactive web app without frameworks - one that isn't "just a document" or "brochure-ware". I've demonstrated pretty clearly that yes it is possible. You people just keep shifting the goalposts further and further... Now it doesn't count unless it's 50K LoC? As i…

I never saw anyone on this thread deny that JS CAN be used without frameworks. As a developer since before the internet even existed I've written probably at least two to four million lines of JS in my life, so I'm well aware. What people are saying is that for LARGE projects you NEED a framework. And your app is tiny. It's got like two source files. So it's just an example of a tiny project getting by without a fram…

> And your app is tiny. It's got like two source files.

If the same app had been written by a typical team of React devs, it would be >1000 source files and 50K LoC. That's not an argument against my approach, it's an argument in favor of it.

Re: If not React, then what?

#569

Post by ricardobeat »

Too wrote: post #525
harrall wrote: post #297

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

Same reason Python is eating the world. It’s technically one of the worst runtimes. Slow and difficult to distribute. Nobody cares, because code ends up short and pretty.

If this was true we’d have Ruby everywhere.

Re: If not React, then what?

#570

Post by zelphirkalt »

flimsypremise wrote: post #208
deergomoo wrote: post #147

Earlier quoted context omitted.

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization…

Do you know, that some of the most used features of SASS/SCSS are now in vanilla CSS?
Post reply on HN