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

The rise of React

increment.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: The rise of React

#111

Post by hoorayimhelping »

hombre_fatal wrote: post #67
pmlnr wrote: post #52

> What differentiates websites from one another today isn’t their underlying architecture but their content, design, and editorial. This is bad, this will kill the quirky, fun internet. Monoculture is not good.

I don't get it unless you interpreted that statement inversely. It's the content, not the underlying architecture of a website, that makes in quirky and fun.

React and the tools used to build React applications (mainly webpack) strongly incentivize engineers to create single page applications, but don't provide good routing and back-button support out of the box. To make a React SPA behave like a traditional web page, you need to add a third party routing library, and that has traditionally been a dumpster fire in React.

That's a quick example of the way the React monoculture is bad for users of the web from a structural, not content point of view.

I say this as someone who has been using React professionally for 5+ years, and who was initially incredibly excited about React's potential. I'm less convinced it's actually good, after seeing how it's used in day to day work with regular engineers working on regular software that isn't Facebook scale.

Re: The rise of React

#112

Post by rimliu »

Swizec wrote: post #6
toshk wrote: post #5

Earlier quoted context omitted.

The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, it just got too complex. In that regard the old situation had better seperation of concerns.

In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.

So in your 15+ years you never saw a project done right. Sad, really. CSSZengarden is mostly forgotten. True, it is just a demo project, but there were some prominent redesigns, and some people even had fun doing "CSS Swaps".

Re: The rise of React

#113

Post by rimliu »

dgb23 wrote: post #25
toshk wrote: post #7

Earlier quoted context omitted.

I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the…

I’m currently training/mentoring a designer in using React, Tailwind, Markdown and basic CLI tooling (git and yarn). She appreciates the power and expression shes given and is learning quickly and steadily. No prior coding knowledge. Most of this comes down to getting past the fear of coding/programming. And it is a powerful enabler, even reshapes thinking. She recently came up to me with saying “why should I write t…

That's really the main reason React got popular. Somehow it lets the people who do not know what they are doing get by. At the expense of the users.

Re: The rise of React

#114

Post by rimliu »

kgin wrote: post #17
Swizec wrote: post #6

Earlier quoted context omitted.

In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.

The idea that HTML was meant to be a pure data format, styled by CSS classes that also were somehow part of that pure data format was always silly, but it became much more silly once REST apis became popular.

What REST has to do with it?

Re: The rise of React

#115

Post by ricardobeat »

_hardwaregeek wrote: post #100

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called wh…

> One way data flow combined with automatic updating and rendering

React did not bring that. Flux, released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same as calling `App.render()` after every data change.

> React lets developers make really smooth, really addictive websites

As someone who has been doing it for a decade, I don't see an inch of a difference. Browsers got more capable, our tools got more sophisticated, but there is nothing really you couldn't do a decade ago. If anything, React leads to bloated and inefficient SPAs.

> any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative

There is no 'round trip' for server render, it is the exact opposite - a client-side app will have no content to show in initial render until it boots in the client. Hence you need SSR + hydration to make it faster.

Re: The rise of React

#116

Post by hn_throwaway_99 »

acemarke wrote: post #105
hn_throwaway_99 wrote: post #31

Earlier quoted context omitted.

I totally agree. If you need access to one config variable CRA doesn't support out of the box, your only option is to eject. I really wish there were the option of just providing an "overlay" file that only had your changes from the CRA defaults, rather than being forced to eject the whole config.

There are multiple existing third-party tools in the ecosystem that let you do exactly that: - https://github.com/gsoft-inc/craco - https://github.com/harrysolovay/rescripts - https://github.com/timarney/react-app-rewired - https://github.com/arackaf/customize-cra No, they're not "officially" supported, and you basically void the warranty by poking the configs manually, but the tools do what you want them to do.

Thank you, this list is much appreciated.

Re: The rise of React

#117

Post by RussianCow »

Ididntdothis wrote: post #58
satya71 wrote: post #8

The only reason I choose React today is the immense ecosystem around it. With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.

Isn't that a failure of the framework developers that not more stuff is in reusable libraries? When I did some Angular I thought that at 70% of the framework should be in libraries that are independent of the framework and reusable.

You need framework integration at some point; otherwise, you end up writing glue code for every single library you use, which is a huge waste of time. The issue is when some library authors don't separate the "core" part of the library from the framework integration, but that's understandable because 1) it's less work to only support a single framework, and 2) you can design your API around that framework specifically, as opposed to trying to make something generic (which often doesn't translate well to some frameworks anyway).

Re: The rise of React

#118

Post by jaredcwhite »

exogen wrote: post #106
jaredcwhite wrote: post #87

This article was great…up until the very end when it failed to mention any alternatives to React that already exist . "Alpert, who helped chart React’s rise, doesn’t see an alternative emerging anytime soon." This is completely ridiculous. Vue, Svelte, LitElement / Web Components, to name but a few. Maddening to see this level of journalistic malpractice.

The writing could be improved, but to me it's clear that the previous paragraph is providing the context for this statement: they're talking about alternatives to using frameworks that provide a higher level of abstraction. Not alternatives to React itself.

I could see that interpretation. It's not very clear to me though…

Re: The rise of React

#119

Post by Nextgrid »

nicoburns wrote: post #23
Nextgrid wrote: post #18

Earlier quoted context omitted.

Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess R…

> I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. I think that might depend on what you're trying to do. I'm guessing as you say you are unfamiliar with the JS ecosystem, that you were trying to do something relatively simple. As a full-stack developer who does a…

> my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common

In this case, it seems to be a problem with the framework if certain parts can't easily be overridden and implemented with custom code. But this is a problem with one particular framework and not with the whole idea of a "batteries-included" framework.

> Angular tries to put the proprietary string templating language in charge of everything. Which is painful.

Probably yes. I have not used Angular, only skimmed the Ember documentation, and what I'm talking about is mostly its MVC structure and the basics it provides like URL routing, models (which is just a REST API client in the background), templates, etc. I'm assuming most of this can be overridden with custom JS for the areas that don't map to its structure well enough.

> Picking libraries is a skill you can develop.

True but my point is less about the complexity of picking libraries and more that these libraries are at its core still framework-agnostic. They are designed by different people, with different goals, skills and opinions, which means there's potential for interoperability bugs if you are unlucky enough to be using the wrong combination of libraries. In comparison, with a batteries-included framework I am more or less guaranteed that all the "batteries" will play nice together and will have a consistent API.

The Javascript ecosystem also moves very fast so even if you pick your libraries at the beginning you might realize 6 months down the line that some became unmaintained or no longer interoperate as well as they used to.

Re: The rise of React

#120

Post by Nextgrid »

ng12 wrote: post #20
Nextgrid wrote: post #18

Earlier quoted context omitted.

Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess R…

I hear this a lot and it's really missing the forest for the trees. Picking a routing library (if you need one) requires 10 minutes of googling. Picking Ember/Angular will haunt you for the lifetime of your project.

Picking a routing library out of 10 competitors might mean that it becomes unmaintained (in favor of some other competitor) or will have bugs integrating with your other libraries.

With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).

Post reply on HN