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

A tale of webpage speed, or throwing away React

solovyov.net

Post reply on HN
Print view View original

121–130 of 319 posts

Re: A tale of webpage speed, or throwing away React

#121

Post by _benj »

nthj wrote: post #104
_benj wrote: post #102

Reading all of the cynicism on the comments I wonder if we are taking into account the business context for the development of the app. I’m not a fan of react even though I use it daily, but the licentious nature of react allows me to build/modify features pretty quickly, albeit, low quality. I’m as idealist as the next person about a good architecture, but if the code you are writing is for a new product that is sti…

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It’s also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions. I am not opposed to React for like, a calendar application, or a particularly complex part of a web app…

I agree with you, even thought I might personally prefer Elixir/Phoenix :-)

In my particular case thought I've been opting for Golang given that my web app needs to perform a little more that CRUD. And in regards to the CRUD part I've been heavily relying on PostgreSQL functions, thus instead the pain of a ORM I just have simple raw sql `SELECT * FROM api.get_user_data(?,?);`

I'm not saying that is not possible to to things like this on Ruby, but when your application is a little more than CRUD RoR starts getting on my way...

Re: A tale of webpage speed, or throwing away React

#122

Post by _benj »

leeoniya wrote: post #118
mumblemumble wrote: post #112

Earlier quoted context omitted.

It's true. But, after having witnessed, and having committed, countless acts of perfecting something until it died on the vine, I would consider, "This hack is hard to change because so very many people are paying us money in return for the privilege of relying on it," to be a very nice problem to have.

the pendulum can swing too far in either direction. but pumping out features with no regard for how they will be maintained is a recipe for lower velocity and less stability in the future.

true, but for me writing highly architected features that take 3x or more time to write just to steer away because of business needs (i.e. doesn't sell) seems to me more painful.

Re: A tale of webpage speed, or throwing away React

#123

Post by jack_riminton »

nthj wrote: post #104
_benj wrote: post #102

Reading all of the cynicism on the comments I wonder if we are taking into account the business context for the development of the app. I’m not a fan of react even though I use it daily, but the licentious nature of react allows me to build/modify features pretty quickly, albeit, low quality. I’m as idealist as the next person about a good architecture, but if the code you are writing is for a new product that is sti…

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It’s also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions. I am not opposed to React for like, a calendar application, or a particularly complex part of a web app…

The happy engineer concept is a much neglected one imo.

Rails devs who’ve mastered a lightweight js framework like Stimulus and perhaps a webhook utility like ActionCable are immensely more productive than a team of very separate front and back end devs.

Basecamp take this a level further whereby each dev is quite heavily involved in the design process, and their designers can also code in Rails.

With Hey I think they’ve shown that it can not only be lightning fast but pretty shiny!

Re: A tale of webpage speed, or throwing away React

#124

Post by ricardobeat »

madeofpalk wrote: post #77
ricardobeat wrote: post #58

Earlier quoted context omitted.

> Seems to be blaming something on a library that the library has no care about in the first place Libraries and frameworks establish idioms, which encourage or discourage certain patterns. In my experience React / JSX definitely encourage complexity and abstraction by making display and logic so intertwined, especially with hooks. > And holy guacamoly, how do you end up with this? Libraries upon libraries, one tiny…

I cannot see how react encourages you to forget :hover in CSS.

You can argue it is not React's fault as usual, but this is how:

     setState('active')} />

    const styles = StyleSheet.create({
        active: { backgroundColor: 'purple' }
    })
progressing into:

     setState('active')}
      onHover={() => setState('hover')} />

    const styles = StyleSheet.create({
        active: { backgroundColor: 'purple' }
        hover: { backgroundColor: 'blue' }
    })
which is frictionless and 'clean', vs the alternative:

    const styles = StyleSheet.create({
      button: {
        '&:hover': { backgroundColor: 'blue' }
      }
    })
The states here doesn't make a lot of sense, but I think it illustrates the idioms involved and how you end up focused on JS. This is so common I bet most devs who entered the market using React will see absolutely no issue in that.

Another familiar case is not having direct control over a parent/child component's styles, only their state, making it impossible to do it with CSS. Not exposing `style` is very common in component libraries, and using CSS-in-JS means you can't easily target them with CSS selectors.

Re: A tale of webpage speed, or throwing away React

#125

Post by commandlinefan »

_benj wrote: post #102

Reading all of the cynicism on the comments I wonder if we are taking into account the business context for the development of the app. I’m not a fan of react even though I use it daily, but the licentious nature of react allows me to build/modify features pretty quickly, albeit, low quality. I’m as idealist as the next person about a good architecture, but if the code you are writing is for a new product that is sti…

> react let’s you do pretty much whatever you want

Ok, so I haven't gotten around to learning React yet, but I understand it to be the next iteration of what Angular, which I have learned, was trying to be. Angular "let you do whatever you wanted", too, which made me wonder why it was even there in the first place. Javascript lets me do whatever I want, I just have to write a lot of code to do that. In theory, a framework ought to reduce the amount of code I had to write, but I found that I was actually writing more code to work around the 90% of things Angular didn't do than I would if I just used Javascript and DOM manipulation. Frameworks that "let you do whatever you want" usually end up being the thing they're supposed to replace with extra steps.

Re: A tale of webpage speed, or throwing away React

#126

Post by aphextron »

kilburn wrote: post #111

Most people here are criticizing the author for doing some dumb things. I concur, but still think they have a good point. First, keep in mind that the author's use case is a content-heavy app with sprinkles of interactivity. This is very important because it sets the "webpage speed" goalpost to a concrete place: they want good lighthouse/first load times and good SEO. I've fallen into the same pit before. I've used C…

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building web applications on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and active development around it and its' ecosystem. And hand rolling vanilla JS in a large scale web application quickly becomes a maintainability nightmare. The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend.

Re: A tale of webpage speed, or throwing away React

#127

Post by mumblemumble »

leeoniya wrote: post #118
mumblemumble wrote: post #112

Earlier quoted context omitted.

It's true. But, after having witnessed, and having committed, countless acts of perfecting something until it died on the vine, I would consider, "This hack is hard to change because so very many people are paying us money in return for the privilege of relying on it," to be a very nice problem to have.

the pendulum can swing too far in either direction. but pumping out features with no regard for how they will be maintained is a recipe for lower velocity and less stability in the future.

> pumping out features with no regard for how they will be maintained

That doesn't seem to be the position that's being advanced here. TFA, for example, starts out talking all about the author fell in love with React for its easy maintainability, before moving on to the need to make some tweaks for the sake of user experience, and finally ending by proposing a design that is based on a fairly principled set of design tradeoffs.

And the parent commenter, at least to my reading, isn't saying, "phooey, who cares about maintainability," they're saying that, while they don't like React, they do have to acknowledge that there is pragmatic value in it not being so rigid that you can't just grind out the code when business realities mean that that's what you need to do.

Long story short, if what you're trying to advocate is a flexible, middle-path-type approach, I don't know that this is the best place to go searching for a debate on the subject.

Re: A tale of webpage speed, or throwing away React

#128

Post by rmrfrmrf »

capableweb wrote: post #10

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc. This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using Reac…

> This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using React?

Because when requirements change and your hover animation needs some additional flare to it in certain cases, you'll be glad that you had automated unit tests to verify original behavior still works along with your customizations.

Re: A tale of webpage speed, or throwing away React

#129

Post by revscat »

recursivedoubts wrote: post #114

The initial motivation for intercooler.js (which the author forked) was performance. I was working on a large bulk table update and building the table dynamically in javascript. The performance was terrible (this was back in 2012, no idea what it would be like today). I realized that I could just deliver and slam HTML into the DOM and that the browser engine, written in C, was very fast at rendering it. That turned i…

This is amazing.

Re: A tale of webpage speed, or throwing away React

#130

Post by cuddlecake »

hliyan wrote: post #48
kungato wrote: post #46

Earlier quoted context omitted.

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.

"The performance benefits are evident" is a bit too authoritative to me. Would you mind giving a summary of the performance benefits?
Post reply on HN