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

381–390 of 756 posts

Re: If not React, then what?

#381

Post by quantadev »

baobabKoodaa wrote: post #334
quantadev wrote: post #320

Earlier quoted context omitted.

Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.

"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"

I literally said the exact opposite. I don't care what language you use as long as it's type-safe.

Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.

Re: If not React, then what?

#382

Post by xcrunner529 »

root_axis wrote: post #175
pier25 wrote: post #126

Earlier quoted context omitted.

You're missing the point of my comment. Someone is contesting that "frameworkism isn't delivering" when we have objective data to prove that it is in fact not delivering. The Amazon store is just a good example because there's a lot of data about it, not because it's FAANG.

You just picked Amazon arbitrarily because it supports your argument, but there are many more counter examples where react is used, so what's your point?

And who where it’s faster and more performant? Not Pinterest. Not Airbnb. Not X. Not the Amazon competitors he showed. Not even the flipping creators (Facebook) of the framework. You all keep blaming the specific companies for their sites but can’t ever seem to show us an actual performant and good example of react usage.

Re: If not React, then what?

#383

Post by [deleted] »

xcrunner529 wrote: post #346
afavour wrote: post #228

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

It’s just embarrassing any image scrolling site will eventually just eat all the memory and crash and you lose your place. Used to kill me back in the Tumblr days and React perpetuates it.

[deleted]

Re: If not React, then what?

#384

Post by lihaoyi »

fleabitdev wrote: post #342
lihaoyi wrote: post #243

The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…

You're completely right, but I think it's worth adding that the O(n^2) to O(n) change isn't specific to React or UI. That same improvement is often seen when migrating other code from a mutating style to a pure-functional style. "A pure function which transforms the entire input into the entire output" is obviously the simplest possible architecture for many programs, but people hesitate to use that architecture beca…

We've been doing the O(n) thing forever with PHP and CGI since 1995, the issue is that it required constant whole-page reloads and was a poor experience that got worse the more interactive your webapps got. React let you do the same thing but made it fast(ish) with local updates

We actually see similar innovations on the FP side as well, with persistent data structures that allow structural sharing so your "copy and update" operations can be fast enough to be usable (even if still not nearly as fast as in-place mutation)

Re: If not React, then what?

#385

Post by xcrunner529 »

quantadev wrote: post #320
baobabKoodaa wrote: post #308

Earlier quoted context omitted.

I don't share your opinion but I'm too tired to go into another JS vs TS debate

Me too. lol. People who don't think type-safe languages are important are the ones who simply haven't yet run into the problems you run into without type safety, and no amount of HackerNews posting is going to suddenly give them the experience to understand.

Awfully funny considering our major security issues in code these days are from a type safe language.

Re: If not React, then what?

#386

Post by xcrunner529 »

quantadev wrote: post #118
mollerhoj wrote: post #91

Earlier quoted context omitted.

Have you ever worked on a project that used Rails, Laravel, Django or Spring? Without being a SPA? For many (most) websites, I find that these are far superior to client side heavy SPAs with json apis (react, vue etc).

Most of the apps I've worked on were very business oriented, and about people getting work done, rather than "website" type stuff that's mostly static. So for example, being able to refresh a part of the screen with new information from the server, is critical. Doing page reloads would destroy the experience. I have 35yrs exp so yes I've used most of what you mentioned.

You’re just proving the point. This stuff was easy when it was called Ajax. You don’t need React for that simple thing lmao.

Re: If not React, then what?

#387

Post by wokwokwok »

afavour wrote: post #250
michaelcampbell wrote: post #248

Earlier quoted context omitted.

Reacting to assertions of broad averages with specific counter examples doesn't necessarily invalidate their point.

OK, let me restate something from my previous component explicitly: a site that’s concerned with SEO is not a “specialized domain”. It is very, very common.

Many sites have a two tier application with a CMS SEO “landing page” abd conversion funnel run by the marketing department and a user-login that takes you to a separate website that is SEO irrelevant.

So… a site that doesnt care about SEO and is not indexed and is purely for logged in users is also very common.

Re: If not React, then what?

#388

Post by yawaramin »

echelon wrote: post #192
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. This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks. Modern web applications sometimes feel incredibly shitty to use. Gm…

> Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.

Colour me doubtful. As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. And no one is going to transfer the DOM into WASM and break every JavaScript app out there.

Re: If not React, then what?

#389

Post by baobabKoodaa »

quantadev wrote: post #380
baobabKoodaa wrote: post #329

Earlier quoted context omitted.

> App.js is all the code there is No, it's not. Chatbot.js is 3400 LOC. There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"? Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts. > tiny toy project Huh?…

Even considering chatbot.js, it's still a small enough toy project to just barely get by without type safety. I don't consider a project "large" until it's in the 30K to 50K LOC at least, where it becomes impossible to literally remember where each use of any given variable is. Type Safety catches most typos at build time, and also allows ease of refactoring. Only these small projects can get by without type safety,…

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 if unnecessary complexity was some kind of inherent good.

Re: If not React, then what?

#390

Post by lihaoyi »

teddarific wrote: post #352
hasanhaja wrote: post #292

Earlier quoted context omitted.

How are you getting to O(n)? Is that in terms of the logic you need to read and keep in your mind? Or is it the actual computational complexity?

Am curious on the O(n) calculation as well haha — I get what OP is saying, but would love to know if there's some deeper technical details here.

The basic idea is if you have n ways your page can display, with the old PHP/CGI whole page refresh model you needed to write n endpoints, but every interaction required a slow and disruptive whole page refresh

With pre-react single page apps, if you had O(n) ways your webpage could display, you needed to write code to account for n^2 ways that each of those n states could transition into another one of those n states

With react, you write code to render n pages, and get the fine grained interactivity for free with good (enough) performance. It basically removed a tradeoff/dilemma that had been facing web developers since time immemorial, so no surprise it was a big hit

Post reply on HN