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

101–110 of 319 posts

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

#101

Post by coffeefirst »

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…

Yeah, those are choices. You still have to understand what you're actually doing in the browser and the DOM, same as jquery or vanilla js.

I can see how easy it would be to accidentally get a bonkers js bundle if you start using external dependencies without monitoring how much code they ship.

Does React have a perf cost? Absolutely. But there's something else going on here.

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

#102

Post by _benj »

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 still trying to find a market-fit spending a lot of time in the architecture of something that could drastically change doesn’t make much sense to me.

All that I’m saying is that, as opposed to some other opinionated frameworks, react let’s you do pretty much whatever you want, which is great for speed development but can also exhausting in the huge amount of decisions that need to be made.

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

#103

Post by leeoniya »

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

> but if the code you are writing is for a new product that is still trying to find a market-fit spending a lot of time in the architecture of something that could drastically change doesn’t make much sense to me.

"Nothing is more permanent than a temporary solution"

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

#104

Post by nthj »

_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, but most web apps have 90% CRUD and 10% shiny.

And with well-tuned SQL and turbolinks dropped on, Rails pages load in 30-60ms with no page refresh.

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

#105

Post by untog »

tom_walters wrote: post #11

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool. If you want speedy initial interaction times and manageable codebases, (and requireme…

IMO it’s unfair to blame “low quality developers”. The industry has coalesced around React as the one stop answer to everything. Coding boot camps focus on it to the detriment of broader web technologies. It’s worth calling out when it actually fit a use case.

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

#106

Post by heavenlyblue »

dsego wrote: post #95
Jestar342 wrote: post #39

Earlier quoted context omitted.

RE: jQuery.animate() - that was around before CSS animations were. Animations were not in the CSS spec until v3 which only saw widespread support this side of 2010. Before then you could only do animations with Javascript, and frankly jQuery's `animate()` was a god-send.

On top of that, js animations are still better for controlling timing and events or for a more realistic natural motion (springs instead of timed easing).

I would say that what JS animations are even better at is justifying inflated budgets of the projects made for people who are not very familiar with tech.

Is there ever a real reason for animations that doesn't make the interface feel sluggish and unresponsive? In the other hand if you actually set the animation delay to something incredibly low, all of your animation needs could be easily solved by animating the transparency of the appearing elements.

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

#107

Post by piranha »

yowlingcat wrote: post #92
piranha wrote: post #36

Earlier quoted context omitted.

> additionally, I highly doubt that the author has replicated this functionality by using his new turbolinky framework. Which functionality? > a bunch of UI requirements So your point is that you don't really know, but let's blame them for trying, or what?

> So your point is that you don't really know, but let's blame them for trying, or what? I think GP's post is that _you_ don't really know the landscape which was why you reinvented the wheel, which I tend to agree with. You even agree with this unless you're being rhetorical here, no? > Which functionality? Let's take a look at every feature we see on the next.js page ( https://nextjs.org/ ): Zero Config Automatic c…

That is a good list. Have you heard about ClojureScript? Obviously, TypeScript is not supported, but everything else is.

> How long do you think it will take to incorporate them into your new tool which you just rolled from scratch?

Here is the news: we will never add them to the new tool. No TypeScript, no compilation, no routes, nothing.

> If I am your CTO

Good news you're not, right?

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

#108

Post by toddmatthews »

christkv wrote: post #100
tom_walters wrote: post #11

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool. If you want speedy initial interaction times and manageable codebases, (and requireme…

React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We…

godsend

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

#109

Post by AtlasBarfed »

tom_walters wrote: post #60
Udik wrote: post #53

Earlier quoted context omitted.

In general, these posts sound a bit like this: I tried jQuery, and after a while it all became a mess; took up a Backbone project, and was good for a while, but eventually it became too complex; then I worked on Angular and that seemed a big improvement, but then... and finally with React my architectures are clean. While the reality is more like this: I had 6 months of programming experience and used jQuery and made…

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 "talent", realize that WebUIs get chucked every 3-5 years anyway due to browser tech churn, and move to data monopolization.

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

#110

Post by fogetti »

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

The exact thing that makes development fast is not to make decisions. In fact, this is such a fundamental principle that Uncle Bob spells it out this way: "A good architect maximizes the number of decisions not made" and I wholeheartedly agree with that. Also as a sibling comment mentioned it, Rails and similar batteries included frameworks (like Angular for example) are the way to go for rapid prototyping, since they include everything you might ever need.
Post reply on HN