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

251–260 of 319 posts

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

#251

Post by madeofpalk »

ricardobeat wrote: post #150
dceddia wrote: post #134

Earlier quoted context omitted.

The thing is, React works with plain CSS too. I think a lot of newcomers see that JSX looks like React-flavored HTML and naturally assume that React will have its own flavor of CSS, but it doesn’t. There are libraries for CSS-in-JS of course, third party ones. But implementing :hover on a button in React can be done just the same as in plain old HTML - with a bit of CSS in a .css file. Or for active/inactive states,…

That doesn't change the reality that there are a million projects out there using css-in-js - about 50% according to developer surveys. I doubt they are all written by newcomers. The fact that React is a plain view library and doesn't provide / interfere with the rest of your tooling is precisely the problem in my opinion, and does not exempt it from the resulting mess. The lack of standards has led to the proliferat…

Even if you do use a CSS-in-JS solution, which i'm not a fan of but have used in a few projects, they still don't do "hover in js"!

All they are are just fancy wrappers around putting more or less the same straight up CSS into the page. So you still use :hover or :active or whatever to do the appearance states in straight up css.

I still fail to see how React encourages adding event handlers to add hover appearances. A developer who thinks that's what to do with React was going to fuck that up with any technology.

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

#252

Post by madeofpalk »

ricardobeat wrote: post #124
madeofpalk wrote: post #77

Earlier quoted context omitted.

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

Low quality developers will end up with low quality code.

I understand that frameworks might push you in a certain direction, but not this for React.

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

#253

Post by madeofpalk »

schwartzworld wrote: post #120
madeofpalk wrote: post #14

How on earth does React encourage the bad practice of “hovers in JS”? React absolutely has zero influence on this - that one is entirely on the developers. I’m also exceptionally confused why the Pagespeed score was sitting at just 5/100 - it doesn’t sound like the dev team actually understood the result and attempted to resolve it. It sounds like the author has found some new technology they’re happy with for now, b…

If you are writing JS styles, you don't have access to pseudoselectors like :hover. A quick solution adopted by many is simulating hover with onMouseEnter and onMouseLeave event handlers. This can be remedied by using CSS or styled-components.

This is nowhere near a common practice (I've never seen it on any work project, or on community projects). React does not promote or advocate or make it easier to do it this way, rather than the proper way in CSS.

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

#254

Post by sparks1970 »

RandoHolmes wrote: post #166
aphextron wrote: post #126

Earlier quoted context omitted.

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…

This all indicates that browsers and html/css are bad tools for creating UI. Long term I think we'll eventually see the ability to interact with the local system via the browser, and we'll start seeing more things like "QT for the web". Because if we don't, at some point it's all going to just fall over.

Qooxdoo? https://qooxdoo.org/ ?

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

#256

Post by davidwparker »

kilburn wrote: post #225
davidwparker wrote: post #216

Earlier quoted context omitted.

If you're truly having issues with CSS and rendering different sizes, I'd recommend taking the time to really learn CSS inside and out. I find it incredibly simple nowadays to do both Mobile/Desktop (+Tablet) with CSS and media queries. I may have agreed with you in the past, but not so much anymore.

There are still some things that are impossible to achieve with CSS alone, even if you have the luxury of only needing to work with evergreen browsers (remember we are speaking of content-heavy sites here, which are the most prone to still have to support older browsers). Example: I have a stack of boxes of varying heights. On mobile they are fine as is (one below the other). On tablet I want them in two columns but…

I would tend to use grid for this, and no, I wouldn't use HTML/CSS alone, if there's a dynamic dataset. The intent with my comment is you don't need to render different views entirely, but that there are CSS tools (col-span-1, 2, ... ) + grid that work really well.

That said, I also don't have to support older browsers. We're content heavy, but traffic is so small from Safari, older IE, etc. so we're fine with using newer features.

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

#257

Post by Semiapies »

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.

It's not React, it's new developers hungry to do everything in React, even as people better-versed in web technologies tell them to use CSS, etc.

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

#258

Post by JohnBooty »

recursivedoubts wrote: post #189
JeremyNT wrote: post #165

Earlier quoted context omitted.

I love seeing more work in this space! This sounds similar to the approach Basecamp has taken, with tools like stimulus.js (combined with with Rails UJS and Turbolinks). You can make a really responsive page with normal server-side HTML templates that "sprinkle" in the ajax functionality. Tools like this feel very familiar to those of us who got started before the rise of the modern JS framework. It's kind of fun to…

Yep. The problem is that HTML was never completed as a hypertext, they just kinda stopped at anchor tags and forms. There isn't a good reason that only anchors and forms should be able to specify HTTP requests. There isn't a good reason that only clicks or form submits should be able to trigger HTTP requests. There isn't a good reason that only POST and GET should be readily available (and POST only for forms.) And t…

    There isn't a good reason that only anchors and forms 
    should be able to specify HTTP requests. There isn't a 
    good reason that only clicks or form submits should be 
    able to trigger HTTP requests. There isn't a good reason 
    that only POST and GET should be readily available (and 
    POST only for forms.)
That's an excellent and thought-provoking way to think about it.

I'd always been mentally locked into HTML's basic "the web is a series of linked pages" paradigm that was in effect ever since it debuted, thinking that to do anything outside of that paradigm you'd obviously want to resort to manipulating the DOM directly with javascript.

But, there's really no reason for responsibilities to be divided in quite that manner. There's really no reason HTML itself can't encompass somewhat more robust hypertext features, with declarative support for functionality like "this link should load URI abc in the xyz region of the current page."

Frames, of course, did sort of do that natively in HTML, but that was a very clunky implementation to put it mildly.

I can think of potential arguments against what you say, but I think I agree...

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

#259

Post by heavyset_go »

RandoHolmes wrote: post #166
aphextron wrote: post #126

Earlier quoted context omitted.

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…

This all indicates that browsers and html/css are bad tools for creating UI. Long term I think we'll eventually see the ability to interact with the local system via the browser, and we'll start seeing more things like "QT for the web". Because if we don't, at some point it's all going to just fall over.

Qt for the web already exists within Qt.
Post reply on HN