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

81–90 of 168 posts

Re: The rise of React

#81

Post by julianeon »

toshk wrote: post #5
Swizec wrote: post #3

I think React’s biggest win is that it appeals to the programmers, not just the web developers. For the first time everything you need to make a website or webapp — html, css, etc – is just data. You have direct control, direct access, you can do what you want. There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.

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.

They could always look into a minimalist framework like Svelte, which is intentionally the most minimal step up from plain JS/HTML in terms of coding, yet gives you the power to make React-level websites.

I recently wanted to throw up some minimal stuff on S3 without building, just a HTML file, and was surprised at how small the difference was, for simple enough pages - almost 0.

Re: The rise of React

#82

Post by bobthepanda »

ridicter wrote: post #32
whycombagator wrote: post #16

Earlier quoted context omitted.

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?

My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically. I p…

> You burn a lot of mental energy figuring out which forms library, router library, etc to use

Why do you need a specific forms or router library? Those are both things you can do with vanilla ES2015+ and React.

The library problem is self-inflicted, but it doesn't help that search engines tend to boost a lot of half-baked Medium posts about why you should use slightly-nicer flavor-of-the-month library to wrap something really basic like the fetch browser API.

Re: The rise of React

#83

Post by Ozzie_osman »

As someone who has been in the industry for a dozen years, and been an engineer or managed engineers at companies of different sizes, I love React. Some benefits:

1- It has bridged a previously large gap between FE code and BE code, and hence, made it a lot easier for engineers who aren't FE-specialists to build frontend code. I've found that backend engineers are a lot more willing and able to write React code, since it just feels more like the type of software they're used to writing.

2- It has brought concepts like functional/declarative programming much more center-stage. Prior to React, most developers might get a taste of declarative programming if they used SQL, but not in their day-to-day. They might give something like Scala a try, and either join the cult or turn around and run away screaming. React made these concepts a lot more accessible.

Re: The rise of React

#85

Post by ng12 »

k__ wrote: post #78
ng12 wrote: post #56

Earlier quoted context omitted.

I like Next.js quite a bit but I don't need SSR. To expand upon my use case a bit: I need a way to create dozens of small SPAs in an enterprise environment maintained by people who are not front-end experts. CRA fits the bill almost perfectly except it makes certain Webpack/Babel configs unavailable that make my life very difficult. The token response from the CRA team tends to be: we don't think you need this, fork…

CRA focuses on the very basics, so it's probably not suited for your problem. Can't you switch Next.js to SSG for all routes since v9?

CRA is exactly suited to my problem: these are simple React front-ends. I don't want any sort of server-side rendering. I don't need any of the features from Next.js. I just the ability to modify some of the basic configs that are hard-coded in CRA for unclear reasons.

Re: The rise of React

#86

Post by stimpson_j_cat »

ht85 wrote: post #37
ng12 wrote: post #22

Earlier quoted context omitted.

> I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. Same, but this is also why I feel burnt by create-react-app. There's so many important features the team has simply decided it won't support. One of the biggest issues with the React ecosystem is that there's nothing in between training wheels (CRA) and a motorcycle (rolling your own config). Mayb…

I've has a lot of success using react-app-rewired to do small changes to the webpack config. You avoid ejecting and benefit from upgrades to CRA, but you can customize anything you like. There's a `customize-cra` lib that provides useful helpers that you can use to perform the most common operations.

> to do small changes to the Webpack config

90% of the reason I eject CRA. rewired is essential.

Re: The rise of React

#87

Post by jaredcwhite »

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.

Re: The rise of React

#88

Post by lucassen »

Nextgrid wrote: post #18
whycombagator wrote: post #16

Earlier quoted context omitted.

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?

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…

> everything (local state management, API calls, forms, URL routing, etc)

hooks, axios, html, reach-router.

my point is that if you start with the assumption that browser APIs are sufficient, there is a natural progression to your project and «taste» in supporting libraries to react

Re: The rise of React

#89

Post by clivestaples »

bsaul wrote: post #77

sidenote : i find it funny nobody in the comments mentions vue.js. i find mentions of ember and angular, but i had the impression vue was the one that got all the love recently. Has something bad happened to this framework ?

Not that I can tell. I recently stumbled upon Quasar/Vue and was very impressed. The ecosystem seems to be flourishing.

Re: The rise of React

#90

Post by notJim »

bobthepanda wrote: post #79
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…

> local state management, API calls, forms, URL routing, etc for all of these examples, React offers a vanilla way to do this, or you could use React + ECMAScript & polyfills to do this. there are definitely bolt-on libraries that do more with those but you can be fine with minimal dependencies on other things. I feel like a lot of pain with React development is self-inflicted.

Agree with this. On a recent React side-project, I decided to try avoiding dependencies as much as practical, and building my own stuff. I've found the libraries often don't do as much as you think, and you'll spend more time customizing them than you would rolling your own. I think often I reach for a library because I don't understand how to solve a problem in react. It's better to first figure out how to solve the problem, then decide if you still want a library for it.

The only libraries I used aside from React itself were react-router (scars from dealing with the history API in a past life) and material-ui (not a designer.) react-router was a breeze, and I did end up spending a lot of time figuring out how to customize material-ui, but I still think it was worth not having to write my own components.

One thing that's key to this approach though is understanding the patterns your would-be dependencies use. For example, I did implement unidirectional state flow like in Redux. I just didn't use Redux. I also considered using a form library, but ended up just stealing some of its ideas.

Now where I do think libraries shine is on larger teams. Once you have a larger team, having documented ways of doing things, and the possibility of hiring people that already know them outweighs a lot of the costs of using libraries.

Post reply on HN