Live data from Hacker News

The rise of React

increment.com

11–20 of 168 posts

Re: The rise of React

#11
post #6
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.

This is true. The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated.

As a mostly back-end developer, I am not a fan of the complexity and magical bullshit you have to know about to use React properly. I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. The fact that it completely disregards MVC, which maybe never really worked anyway, is the least of its problems.

Re: The rise of React

#12
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.

This is exactly what drew me into React.

I used to _hate_ front-end programming, everything was a huge framework of magic dust and unicorns. Stuff Just Worked - if you knew the name of the magic incantations (variables and functions) you had to cast to make it work. Never mind that the whole front-end landscape seemed to do a complete pivot and invent new stuff every other week.

With React + Typescript it's just components that produce fragments of HTML and are entirely or at least mostly self-contained with a clear interface.

Re: The rise of React

#13
post #7
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.

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…

In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic.

Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.

Re: The rise of React

#14
post #13
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…

In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic. Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.

I've seen few organisations where there was a group of frontenders specialised in html/css. Even integrated in continious development. It's a fine line, but with backbone.js and sass they could manage, but with react and postcss the line between templates and logic disappeared.

But it's less specific then that. When 6 years ago hiring a frontender they needed to just know html and css, now they need to be full blown devs.

Re: The rise of React

#15
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.

Yes, as a programmer I love react. It fits into my mental models of composability and state management.

Re: The rise of React

#16
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.

> 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?

Re: The rise of React

#17
post #6
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.

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.

Re: The rise of React

#18
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.

> 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 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. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial.

I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.

Re: The rise of React

#19
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.

Yes, as a programmer I love react. It fits into my mental models of composability and state management.

Funny for me state management was pretty simple until React came along and made it asynchronous.

Re: The rise of React

#20

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…

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.
Post reply on HN