Live data from Hacker News

My Reaction to React

pseudoconcurrentthought.wordpress.com

11–20 of 147 posts

Re: My Reaction to React

#11
post #8
post #5

Okay I think the author is severely misinformed as to why we use React. I say this because the very first thing he says is to use MVC architecture and then goes on to write his own framework ( from scratch??????? ) ...Why? This solves none of the problems React was designed to solve and only makes things more complicated by introducing new APIs only you know. Yes, this approach with vanilla JS is great for small apps…

I'm not really fighting you on the merits of frameworks (which should be obvious to everyone), but are you implying that implementing a design pattern is equivalent to building a framework?

Not at all but what is the end goal of this if we consider that the code base will increase in size? You'd likely start adding more and more things to it to make it easier to work with and eventually you've unintentionally rolled your own framework.

React could also still be implemented as part of the author's view because they haven't covered any of the problems with large cascading data updates. So there's literally no argument against React in this post. It's basically just a post about how to implement a design pattern in a language, React doesn't even need to be mentioned. I might even call it click bait.

Re: My Reaction to React

#12
post #10
post #6

Earlier quoted context omitted.

I totally agree with you on the scalability aspect, but I think one of the main issues correctly pointed out by @ilovefood is that a lot of juniors nowadays start directly with one of the big frameworks, with no idea on what vanilla JS is. I really hoped that we learned something from the jQuery experience but it seems to happen again and, maybe this is just my feeling, but JavaScript is kind of the only big enough l…

Can't blame the tools for a lack of decent developers any more than you can blame a spell checker for illiteracy.

True; us, the Web community (which also built the frameworks) as a whole, is to blame.

Re: My Reaction to React

#14
post #7

Components are easy. Just write a function... Until you want to automatically unregister event handlers when the component is removed Until you want to compose them and select child and parent components without traversing the DOM Until you want to pass options to the components in various ways, and have default values for them Until you want to store component state and re-render part of the component whenever somet…

This this this. Why is the best comment at the bottom.

Re: My Reaction to React

#15
React is just a library. It is the ideas behind it that are important:

a) building web front-ends by dividing them into components which are first-class citizens of the codebase, and can be composed, parameterized and reused, just like pure functions. [1]

b) expressing the view as a pure function of state has replaced any need to mutate the DOM manually and think about transitions ($.remove(), $.append() etc.). We need virtual-dom and diffing to be able to pull this off successfully, which makes this abstraction irreducible.

c) interspersing content-inside-code (JSX) is better than code-inside-content (template languages like Angular). [2]

The recent 'React fatigue' is due to people trying to figure out how to best manage state within this framework and causing a lot of noise in the process. And that is perfectly fine, but if you are confused by it, just use vanilla React and React's immutability helpers, keep all the state in the root node and pass everything down as props {...this.props}, and then when you get a hang of it, hop on to Redux. There is no 'one true way'; as long as your app works and you can hold it in your head, everything is fine.

[1] - http://www.jasimabasheer.com/posts/on-react.html [2] - http://www.jasimabasheer.com/posts/evolution-of-view-templat...

Re: My Reaction to React

#16
post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

imo: frameworks are materialized expectations

given that software development is mainly about managing expectations this is of huge value

Re: My Reaction to React

#17
post #3

The first Javascript post I enjoyed reading, this looks simple for humans like me. It is more readable and more understandable. You should write more Javascript tutorials and show that things don't have to suck. This is how I should have started learning Javascript. I bet the time lost in not using a framework is gained with a better understanding of what is happening and also with an absence of imposed conventions.…

Yes and no. Homerolled solutions such as this are free of another developers assumptions, but tend to scale poorly. Generally they need to be modified as new requirements are created, or unforeseen circumstances arise. Over time you end up putting together more and more logic in and the illogical conclusion is that you end up building your own heavily bespoke version of React/Angular/jQuery/whatever, before realising…

You are absolutely right, but I do believe people should start learning the alphabet before trying to read a book.

React looks fine to me and at my daily job our frontend devs do some amazing job. I just wanted to learn and all I seem to find is how to learn javascript through React, and not React through Javascript.

I do agree this is a home made solution and would not work nicely with lots of devs involved. I'm talking about learning though, and we devs are usually bad teachers when we don't know how to boil it down to the essentials.

How many people do you know that only use React to draw boxes and not for the advantages it brings?

Re: My Reaction to React

#18
There are some subtle bugs in this code. For example `new App.View.Hobbies(model.hobbyList)` is not going to do what you're expecting when the `Hobbies` function is explicitly returning an object.

I like the premise of the post, but I did not find the end result very convincing.

Re: My Reaction to React

#19
post #15

React is just a library. It is the ideas behind it that are important: a) building web front-ends by dividing them into components which are first-class citizens of the codebase, and can be composed, parameterized and reused, just like pure functions. [1] b) expressing the view as a pure function of state has replaced any need to mutate the DOM manually and think about transitions ($.remove(), $.append() etc.). We ne…

    There is no 'one true way';
    as long as your app works and 
    you can hold it in your 
    head, everything is fine.
With all due respect, this is the major criticism of adopting React, given that it's still in active development and given that many who are looking at using it have established apps using other patterns already.

Re: My Reaction to React

#20
post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

imo: frameworks are materialized expectations given that software development is mainly about managing expectations this is of huge value

"frameworks are materialized expectations"

I like that. It's a nice way to put it.

Post reply on HN