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

271–280 of 319 posts

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

#271

Post by wwright »

7786655 wrote: post #218
wwright wrote: post #88

Earlier quoted context omitted.

This site also has almost no state at all per-user.

Every time you collapse a thread, that's saved on the server. Then, if you return to the page, it will render those threads collapsed. So that's a decent amount of state.

I disagree. It’s Boolean and flat (there is neither sequential nor nested logic around the state). It does recurse for each sub thread, but only in the case where there is no state. There’s also no business logic built around it, only display logic. It also is updated from exactly one location in the application.

That said, it’s a very simple and effective design. It’s an excellent program. But it’s not a fair comparison against other applications which, for one reason or another, need significantly more advanced state.

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

#272

Post by pqb »

kbenson wrote: post #217
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…

I stop reading the webapp/react specific posts on HN for a year, and now there's such foreign terminology that I can't even understand the comments of one. Hydration? From context I assume it's something to do with rendering trees and the Dom, but really, I'm just grasping. So out of hand. It feels like Javascript webdev is recursively devouring itself into a completely separate type of programming.

"Hydration" is a term often used on the backend too. I believe I have noticed it for the first time in Doctrine documentation, Object Relational Mapper (ORM), which is similar to Hibernate in Java - it was about transforming data retrieved from SQL database (memory) into usable PHP structure (object) [0]. In my opinion, this term has been perfectly described on the StackOverflow [1].

[0]: https://www.doctrine-project.org/projects/doctrine-phpcr-odm...

[1]: https://stackoverflow.com/a/6991192

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

#273

Post by oreoftw »

nawgz wrote: post #244
oreoftw wrote: post #243

Earlier quoted context omitted.

Yes.

Can you link me some docs? I would love to see how the modern tools I learned at my outset compare to the classics.

Check out

https://guides.rubyonrails.org/layouts_and_rendering.html#us...

There's no standard way for handling hot reloading, but there's a bunch of recipes on stackoverflow.

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

#274

Post by sixdimensional »

mattmanser wrote: post #185
nightski wrote: post #167

Earlier quoted context omitted.

I could definitely see something like intercooler boosting productivity. My only concern (possibly unfounded) is that you end up designing all of your server side endpoints specifically in an intercooler fashion. All of your endpoints must now return an html snippet, which is specific to the design of the page. So you have a lot of page specific endpoints. This is in contrast to a REST api where the api can be design…

If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data. It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request. A REST API is basically a massive ov…

Just adding some additional commentary based on your post.

I think you're talking about the difference between an "experience API" - that is, an API with the sole purpose of being support for user experiences/clients - and a "system" or "process" API, where the latter is for application or process integration between many systems. These are terms borrowed from Mulesoft, but I do like the terminology, I find it helpful for segregating concerns.

There are a lot of reasons people need separate experience APIs to power specialized UI/UX - especially with the needs of different client platforms (ex. chat bots vs phones vs desktop browser), separate from system/process APIs.

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

#275

Post by RandoHolmes »

heavyset_go wrote: post #259
RandoHolmes wrote: post #166

Earlier quoted context omitted.

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.

That is not what I'm referring to, you're concentrating too hard on the specific example rather than the idea behind it.

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

#276

Post by kbenson »

pqb wrote: post #272
kbenson wrote: post #217

Earlier quoted context omitted.

I stop reading the webapp/react specific posts on HN for a year, and now there's such foreign terminology that I can't even understand the comments of one. Hydration? From context I assume it's something to do with rendering trees and the Dom, but really, I'm just grasping. So out of hand. It feels like Javascript webdev is recursively devouring itself into a completely separate type of programming.

"Hydration" is a term often used on the backend too. I believe I have noticed it for the first time in Doctrine documentation, Object Relational Mapper (ORM), which is similar to Hibernate in Java - it was about transforming data retrieved from SQL database (memory) into usable PHP structure (object) [0]. In my opinion, this term has been perfectly described on the StackOverflow [1]. [0]: https://www.doctrine-project…

Yeah, I ran across that StackOverflow when I finally removed "react" from my search term when first looking.

I will say, hydration in the context of an ORM seems fairly odd to me. My concept of ORMs doesn't mesh well with the need to pre-populate of bunch of template which you fill the data in for, since I think of them as pretty much all data with some behaviorioral added on.

I guess it could apply towards auto-fetching data as you traverse relations, but those don't exist in a skeletal form AIUI, they are created as needed when requested and data is queried (that is, there's no structure to hydrate with data after the data comes back). I guess you could create objects, query data, and then add data to objects, but given that you often don't know how many objects you'll need, I'm not sure how beneficial that is.

Then again, it's not like I have enough experience with the concept to know the nuances of how it's bandied about.

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

#277

Post by schwartzworld »

madeofpalk wrote: post #253
schwartzworld wrote: post #120

Earlier quoted context omitted.

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.

It is actually in the react documentation. https://reactjs.org/docs/dom-elements.html#style

I'm not saying that's how it should be done. I'm just clarifying what the author of the article was referring to.

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

#278

Post by griffiths »

jevgeni wrote: post #32

Surprised Solid hasn’t been mentioned. This: https://github.com/ryansolid/solid

And the author of the library has great knowledge in this domain. The latest release has the new SSR features added (https://github.com/ryansolid/solid/issues/109#issuecomment-6...).

I would also recommend to anyone to read his blogs about different approaches to client side rendering, and the technology behind Solid. It is a really good read regardless of the choice of using the library.

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

#279

Post by jokethrowaway »

AtlasBarfed wrote: post #109
tom_walters wrote: post #60

Earlier quoted context omitted.

Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc. If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/co…

It's almost like all "modern JS" are written by new programmers hired on the cheap by companies to work on their new hip UI frontends. IMO UI is generally something new programmers like because of the visual/visceral "I built that", but once you get exposed to the sheer annoyance of UIs, programmers will migrate to backend. So the most experienced people don't want to be constantly undercut in price by the incoming "…

This can be generalised to all software that is perceived to be revolutionary. Sooner or later a big company that wants to retain and attract engineering talents will arrive, with a horde or junior engineers led by an engineer looking to justify a promotion or to embellish a CV.

API generators had the same thing. Strongloop was a decent frameworks before they started throwing 10'000 juniors to fix issues and made a mess of the codebase. If you look at the jungle the React codebase is and you compare it with Preact (it's smart, concise and performant) you'll understand why code quality matters. And I'm not talking about stupid metrics.

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

#280

Post by recursivedoubts »

JohnBooty wrote: post #258
recursivedoubts wrote: post #189

Earlier quoted context omitted.

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

Right. And not only is there no reason for responsibilities to be divided that way, as it stands you kneecap the promise of REST/HATEOAS by restricting it to the very specific cases of anchors and forms.

So with htmx I'm trying to complete the HTML hypertext and let people take advantage of the simplicity of the REST model without sacrificing user experience.

Post reply on HN