4 ms·

This is yet another reason to avoid using frameworks you don't really need. Just because someone uses React, and there's buzz around this framework, doesn't mea

This is yet another reason to avoid using frameworks you don't really need. Just because someone uses React, and there's buzz around this framework, doesn't mean you've to use it. Talking from my experience frameworks are one of the hugest anti-patterns in software development. They're hard to learn, they limit your creativity, they go out of business, you've to upgrade them for no good reason and make your code compatible with the latest version, you've to search for help and ask others, they bloat your software and create unnecessary dependencies, and you probably need only 10% of what a framework offers. They just don't make sense. You can easily implement your own abstractions for your own application and be done with it. Your abstractions won't need upgrades, you'll be in control, and you won't have to waste time searching for help. You should be fighting complexity and not embracing it. I don't use frameworks and I encourage you don't use them too.

steve_taylor 11y ago
> you probably need only 10% of what a framework offers. Clearly you have not used React. You can't just use 10% and get any value out of it. It's typically 80% or more.
- deleted 11y ago
  [deleted]
- Silhouette 11y ago
  Though the effect you describe is partly because React isn't trying to be an all-things-to-all-people framework. It's a library, with a specific role and much tighter scope, and it's a small fraction of the size and complexity of something like Angular.
JamesMcMinn 11y ago
React is a library, not a Framework, and the core library itself is actually very small. In fact, part of the recent changes (splitting React into React and ReactDOM) have been in order to keep the core React library as small as possible. React itself doesn't do very much at all, but when you're using React, you're using almost everything React has to offer, and then can choose what you want to add on top of that. Take a look at the top level API [1] and compnenent API [2]. This is React. It's small, and it's compact - there's not a lot to it. [1] https://facebook.github.io/react/docs/top-level-api.html https://facebook.github.io/react/docs/top-level-api.html [2] https://facebook.github.io/react/docs/component-api.html https://facebook.github.io/react/docs/component-api.html
mplewis 11y ago
React is not really a framework in the same sense Angular, Django, or Rails are. It does not dictate how you should architect your app.
- Silhouette 11y ago
  It does not dictate how you should architect your app. This is a little optimistic in practice, because while React is often described as being just the V in MVC, it also has significant scaling issues out of the box. Useful strategies for keeping the performance acceptable can have profound implications for the wider architecture of your application. For example, it seems many in the React community are moving towards using immutable data for the underlying model and pure render components with React. That means you can write efficient shouldComponentUpdate checks. However, it also means you have to design your version of whatever the "M" and "C" become similar to how you'd structure a functional program, which is not at all natural or idiomatic in JS.
platform 11y ago
While it is possible to avoid using frameworks, it is not practical to avoid using powerful and expressive patterns. React is implementing several patterns. At least 2 of them are: 1) unidirectional flow of state management 2) server/client side isomorphism (meaning that a server side solution can render out a good number of client-side views) There are other libraries (not frameworks) that more and more do similar things. And some of them actually offer 'api' and/or source-code level compatibility amongst themselves. Further indicating that these libraries are offering patterns. For example Inferno JS with inferno-component https://github.com/trueadm/inferno https://github.com/trueadm/inferno
estefan 11y ago
> I don't use frameworks and I encourage you don't use them too. Instead you expect every new team member to wade through your homegrown framework-equivalent which means no transferable skills, less real-world testing, likely inferior documentation and no online community to turn to for help if you ever leave. Yeah, nice one.
- dozzie 11y ago
  Dude, you're talking about JavaScript. Documentation is most likely to be superior for shop-made tools, and the community will be at arm's reach. And do you really think seeing someone else's code means no transferable skills? Sure, you can't put it in CV, but on the other hand, you'd see more than merely using some random one-function module.

steve_taylor 11y ago

> you probably need only 10% of what a framework offers. Clearly you have not used React. You can't just use 10% and get any value out of it. It's typically 80% or more.

deleted 11y ago
[deleted]
Silhouette 11y ago
Though the effect you describe is partly because React isn't trying to be an all-things-to-all-people framework. It's a library, with a specific role and much tighter scope, and it's a small fraction of the size and complexity of something like Angular.

JamesMcMinn 11y ago

React is a library, not a Framework, and the core library itself is actually very small. In fact, part of the recent changes (splitting React into React and ReactDOM) have been in order to keep the core React library as small as possible. React itself doesn't do very much at all, but when you're using React, you're using almost everything React has to offer, and then can choose what you want to add on top of that. Take a look at the top level API [1] and compnenent API [2]. This is React. It's small, and it's compact - there's not a lot to it. [1] https://facebook.github.io/react/docs/top-level-api.html https://facebook.github.io/react/docs/top-level-api.html [2] https://facebook.github.io/react/docs/component-api.html https://facebook.github.io/react/docs/component-api.html

mplewis 11y ago

React is not really a framework in the same sense Angular, Django, or Rails are. It does not dictate how you should architect your app.

Silhouette 11y ago
It does not dictate how you should architect your app. This is a little optimistic in practice, because while React is often described as being just the V in MVC, it also has significant scaling issues out of the box. Useful strategies for keeping the performance acceptable can have profound implications for the wider architecture of your application. For example, it seems many in the React community are moving towards using immutable data for the underlying model and pure render components with React. That means you can write efficient shouldComponentUpdate checks. However, it also means you have to design your version of whatever the "M" and "C" become similar to how you'd structure a functional program, which is not at all natural or idiomatic in JS.

platform 11y ago

While it is possible to avoid using frameworks, it is not practical to avoid using powerful and expressive patterns. React is implementing several patterns. At least 2 of them are: 1) unidirectional flow of state management 2) server/client side isomorphism (meaning that a server side solution can render out a good number of client-side views) There are other libraries (not frameworks) that more and more do similar things. And some of them actually offer 'api' and/or source-code level compatibility amongst themselves. Further indicating that these libraries are offering patterns. For example Inferno JS with inferno-component https://github.com/trueadm/inferno https://github.com/trueadm/inferno

estefan 11y ago

> I don't use frameworks and I encourage you don't use them too. Instead you expect every new team member to wade through your homegrown framework-equivalent which means no transferable skills, less real-world testing, likely inferior documentation and no online community to turn to for help if you ever leave. Yeah, nice one.

dozzie 11y ago
Dude, you're talking about JavaScript. Documentation is most likely to be superior for shop-made tools, and the community will be at arm's reach. And do you really think seeing someone else's code means no transferable skills? Sure, you can't put it in CV, but on the other hand, you'd see more than merely using some random one-function module.