survivejs/ama

What do you think about "inferior paradigm"

Closed this issue · 1 comments

Lasts days I was trying to read André Staltz article "WHY REACT/REDUX IS AN INFERIOR PARADIGM" and it's astonishing in some way, what do you think about it? is it fair to says inferior paradigm? and what about writings a survive cycle version?

Lasts days I was trying to read André Staltz article "WHY REACT/REDUX IS AN INFERIOR PARADIGM" and it's astonishing in some way, what do you think about it?

There are some valid concerns in André's article. You could say we're in a discovery mode with React. During last year alone, we saw a huge amount of development and excitement around it. Understandably this had led to a rather interesting situation.

The scene has been dominated by frameworks like Angular and Ember for a few years. The rise of React displays an opposite trend. Instead of adopting a framework with opinions, you might bring your own opinions and adopt libraries. This approach has its pros and cons.

As André illustrates, there can be quite a few concepts you need to understand when you begin to glue various solutions together. I can only imagine how difficult it must be for a beginner to get into front-end development these days given how splintered it is!

On Boilerplates and Boilerplate Code

I think we'll see progress on this front this year. Instead of boilerplates, we'll start to see tools like @insin's nwb. In short, we'll start thinking a bit further. A boilerplate might give you a starting point but it won't help you with maintenance. Pushing some of the boilerplate to dependencies on the other hand gives you something you can consume across projects.

I agree that boilerplate code can be a symptom of some deeper problem. There is always some boilerplate of course, but a good platform can hide plenty of that through abstraction. We would still be coding using GOTOs if we weren't seeking for better abstractions. This happens on various levels. In short, we do our best to keep us productive and avoid those "GOTO"s.

A common theme to all these new solutions is that they push people towards functional purity. React forces you to think about state carefully. Earlier we tied state to the DOM, but as React has shown, perhaps that wasn't the smartest idea.

Libraries, Frameworks, Homegrown Frameworks?

You can see a similar theme with libraries. Currently library based projects tend to be like snowflakes. Each one is a little different. That's not particularly cool if you have to maintain a lot of projects. What if, instead, you could move somewhere between libraries and frameworks?

I expect we'll begin to see React inspired frameworks that fit into this space. That would definitely cut down the amount of boilerplate. These sort of homegrown solutions can make a lot of sense after you have formed your opinions and know well what you are doing.

is it fair to says inferior paradigm?

That feels bit of a hyperbole to me. I agree React has its warts and I would love to see progress on certain fronts. The basic idea of modeling your application in terms of components is great! My primary concern is that we don't have a common definition for a component yet. This means if I develop an awesome React component, only React users can benefit from it. That's not particularly cool.

I think it would benefit everyone a lot if we could agree on a component definition. React's function based components are a good starting point. If we had stateful functions in addition, that would be a very nice starting point and I could model a lot of reusable components based on these two definitions alone.

This is where JSX is valuable. Rather than compiling to React, you would compile to your target system whatever it might happen to be. Deku could be a good example of another library that could benefit from this.

I believe a move like this would be beneficial overall. It simply doesn't make sense to segregate ourselves voluntarily when there's room for collaboration. A move like this would also decrease the lock-in factor of React somewhat and inspire innovation.

and what about writings a survive cycle version?

I don't think that's going to happen in the near future at least. I will definitely keep an eye on Cycle, though.

You should check out my interview of André. I did try porting the Kanban to Cycle at September, but the problem was that it was very difficult to deal with drag and drop. React has the ecosystem advantage there.