Live data from Hacker News

If not React, then what?

infrequently.org

671–680 of 756 posts

Re: If not React, then what?

#671

Earlier quoted context omitted.

> Any web application with a UI _requires_ a frontend build for CSS/JS. Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step. - http/2 makes bundling a questionable choice - polyfills are pretty much no longer a thing - CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.) -…

In web application terms, the "build" is everything that needs to happen to get your application running into production. That means a runtime and dependencies. Speaking of dependencies, does your perfect frontend simply not have any of them? Is every tool you will need to use perfectly packaged with vanilla CSS and ES6 modules? Browser support for import maps is around, but its nothing I would build a production app…

I mean, people ARE doing it, and like I said it's mature enough to be the default way to build Rails apps. There's tradeoffs, no doubt, but this is absolutely a valid, productive way to write (certain types of) web apps.

Re: If not React, then what?

#672

Earlier quoted context omitted.

> I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler Modern CSS is amazing. Why on earth would anyone use SCSS? It pays to look at what Vanilla can do these days. > Even a "thin" layer of JS on top requires some degree of dependency management Use modules and import away. If it is truly a thing layer, there's no need for further optimisation until far along in the pr…

Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them. But most importantly, many of dependencies one might want to use also make use of SCSS/SASS downstream. If you're happy to build everything from scratch and eschew any dependencies that require a build system, then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-buil…

> Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them

You say it like more those features are desirable.

> then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component

Sure. I wasted more time getting an assortment of pre-built components to behave than I did building the basics from scratch. And then comes a breaking change. And then that component library uses styled components and doesn't run properly on the server. Why do people do this to themselves?

Re: If not React, then what?

#673

Earlier quoted context omitted.

He's right. You have a project with two source files in it. That's basically not at any kind of scale he was talking about, and is easily classified as brochure-ware, from an architectural standpoint, simply because there's no architecture to it at all. Just a monolithic file.

> Just a monolithic file. I was willing to assume good intentions from you earlier, but at this point it's clear you're just lying. You've seen the number of files in the repository, we already had a back and forth and you already conceded there was more than one file. And yet here you are, reiterating the same lie. Weird stuff.

Those two 17 LOC files don't count. That leaves precisely two source files, just like I said. It's well under the threshold where I'd consider a framework mandatory.

Re: If not React, then what?

#674
post #372

Earlier quoted context omitted.

Then you are in a bubble. I was recently asked by my elderly parents why they are paying for 5g internet when the internet resources they use are so slow, slower than what they remember from 1997. They ask me to call our ISP because it makes no sense that the sites they have used for decades feel so slow All I could say was that there was nothing I could do.

Every time I use Facebook (which isn't many but still) I am re-shocked at how fucking SLOW it is. How many times I end up refreshing the page because some damn thing didn't connect quick enough, or maybe too quick and it wasn't ready, I'm not sure. YouTube is also great for this, like, 1/50 navigation clicks just results in a blank page with no error message. Ctrl-R to the rescue. Or the number of times Reddit's infi…

Insulated market forces allow certain platforms to operate like this with very few overall repercussions.

They also don’t represent the overall web. I think it would be more far to take a sum of websites used, as opposed to number of users.

Re: If not React, then what?

#675
post #372

Earlier quoted context omitted.

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…

Then you are in a bubble. I was recently asked by my elderly parents why they are paying for 5g internet when the internet resources they use are so slow, slower than what they remember from 1997. They ask me to call our ISP because it makes no sense that the sites they have used for decades feel so slow All I could say was that there was nothing I could do.

That is a bit of an uncommon situation. Given the prevalence of things like 5G internet is typical in more rural or underdeveloped areas, the vast majority of the population of which don’t live.

It’s a valid concern (as I think performance always is to be clear) but the majority are not on higher latency / limited bandwidth connections like 5G internet service as their primary ISP delivery tech.

Vast majority are in cable or fiber at this point, given urban saturation

Re: If not React, then what?

#676
post #311

Earlier quoted context omitted.

> 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 parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on l…

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…

How do you know that was a React issue and not a memory leak, or an error in your own code perhaps?

This smells of a memory leak, particularly if you forgot to add a dependency to a hook for example, but there is plenty of non react related code that could go wrong with drag and drop interfaces too

Re: If not React, then what?

#677
post #573

Earlier quoted context omitted.

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…

People scroll pages to skim. This also sounds like it might break CTRL-F. If I can't skim your page instantly I will more than likely churn my visit. Doesn't matter that I have a good computer on a 1Gbps connection, you ruined my experience. I'd rather wait 1 sec for the full page to load, than wait a series of 100msecs on what should've been a fully loaded page to actually load at an arbitrary point in time.

Maybe you missed the part where I said we're using SSR for content? That solves the CTRL-F problem easily.

You (and a lot of others here) are making a ton of wrong assumptions, imagining things I never said, and making up your own problems that don't exist in my code just to try to bash me, without even really understanding anything that I wrote in my comment. This entire thread sucks and is full of low-quality trolls. I've been doing front-end for ~30 years, I know what I'm doing. Don't bother replying, I won't be responding to further wrong assumptions and bashing.

Re: If not React, then what?

#678

Earlier quoted context omitted.

Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason. If Python was just fine without type-safety that's how everyone would have kept it.

> Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason. This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, beca…

Every highly experienced developer knows the importance of type-safety. The existence of large numbers of experienced Python developers in the world doesn't disprove that, because it's a statement about their knowledge, not their actions.

Python developers simply tolerate the lack of type-safety only because it's a trade-off to get other things the language has to offer. I agree there are trade-off decisions being made.

Re: If not React, then what?

#679
post #660

Earlier quoted context omitted.

I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives. And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer…

To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back. I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience…

I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React answered my three basic concerns very clearly, in an obvious way:

1. Component based architecture

2. The ability to express view as a pure function of state

3. The ability to express HTML and code together in a neat and ergonomic way

This is what I mean by obvious -- all experienced frontend engineers I knew at the time immediately got it, they got that React nailed these three things, and why they were important. Surprisingly, even new frameworks don't always lead with these three principles, which makes me less likely to believe that they resolve the particular concerns that I find of most importance.

Re: If not React, then what?

#680

Earlier quoted context omitted.

> Seasoned Python developers started using every type-safety feature available to them, as they've became available, just like JavaScript developers who know what they're doing have switched to TypeScript for the same exact reason. This is another lie from you. A vanishingly small minority of Python developers is using "every type-safety feature available to them". Not that it even matters to your earlier claim, beca…

Every highly experienced developer knows the importance of type-safety. The existence of large numbers of experienced Python developers in the world doesn't disprove that, because it's a statement about their knowledge, not their actions. Python developers simply tolerate the lack of type-safety only because it's a trade-off to get other things the language has to offer. I agree there are trade-off decisions being ma…

This is what you said earlier:

> For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion.

Clearly, more than 1% of experienced developers choose Python, despite it not being a type-safe language.

Post reply on HN