Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Reaction to React

pseudoconcurrentthought.wordpress.com

Post reply on HN
Print view View original

131–140 of 147 posts

Re: My Reaction to React

#131

Post by true_religion »

Chris_Newton wrote: post #124
cloverich wrote: post #119

Earlier quoted context omitted.

> But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. My view on this is that generally if you haven't extensively used at least a couple of existing fra…

My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion. If your background is mainly in modern JS development, that’s probably true. I don’t think it holds more widely, though. Modern JS lives a little bit in its own world, and the state of the art in that w…

I'm curious what peoples reaction would be to a framework/library that borrowed from Smalltalk's principles.

With the current lineup of frameworks, there's a lot of effort made to remove state from the system in order to make it understandable and performant (which is reminiscent of how people talked about Haskel a few years ago).

Yet with Smalltalk the entire language and tool base embraced the existence of state and gave you a lot of tooling to help make it manageable.

To me, the main problem with frameworks such as Backbone/Angular 1 is that state was bidirectional and that anyone could attach event listeners on anything so your webpage was a network of state flow with none of that being transactional, nor guaranteeing that the system would come into a consistent/valid state.

React is great with their unidirectional approach for rendering, but when a deeply embedded component makes a state change for itself it may logically have to effect the entire system. The current practice is to have top-down handling with Dispatchers/Stores (Flux), or pure reducers (Redux).

Another approach would be to compartmentalize each component so actions can automatically bubble upwards where they are handled by whomever in the VirtualDOM tree can take up the task. This would do away with global dispatch, and make it easier to mix and match components. I think this approach has merit.

Re: My Reaction to React

#132

Post by true_religion »

marknutter wrote: post #86
codemusings wrote: post #47

I won't make an argument for Angular or Flux/Redux because those are very opiniated frameworks that might be overkill or simply not at all how you want to go about your app's architecture. But React is about the view. You can't possibly be convinced that manually traversing the dom is just as easy and expressive as using JSX. Even in the simplest of interactive (as in you need Javascript) components or pages. React's…

> You don't have to - but without them stuff gets messy pretty quick. Which is the same as saying "you have to". Can't we just accept that developing with React is no longer as simple as just stitching some views together? It's as if the collective React community is very insecure about the fact that writing web applications is gonna be hard and complicated no matter how shiny your tools are. Sure, you don't have to…

Are there any other options out there part from Flux/Redux patterns?

I've been looking into using React (well for the past 4 days of solid research), but I'm finding that pure reducers are a mental-mismatch for me.

I'd like something that helps me manage state, and perhaps constraints its flow (like Reach does with unidirecitonal renddering), but not something that tries to abstract state away completely.

Re: My Reaction to React

#133

Post by true_religion »

undo76 wrote: post #75
ohnomrbill wrote: post #71

Earlier quoted context omitted.

I fully agree that his version has flaws, and I certainly am not convinced that he presents a credible case against using React. But to be fair, I think part of his rationale for doing things this way is to avoid the configuration needed to develop with React. I'm somewhat ignorant, so what is the necessary tooling/configuration needed to convert this file to something that can easily be executed in the browser?

It is a misconception that you need a lot of configuration to start with React. The minimum setup requires just to import the React libs in your webpage and to transpile your code to ES5 using Babel in case you are using JSX/ES6 (recomended). Of course for bigger projects, it pays off to use an automatic build tool like webpack or gulp. https://jsbin.com/keyuqohusa/edit?html,js,output https://babeljs.io/repl/#?experi…

I think the issue people have with React is that a lot of tutorials assume you are already using NPM/Babel.

If you're using a module importer already then adding React to your stack is pretty easy. For example with JSPM:

$ jspm install --dev react react-dom $ npm install --save-dev babel-preset-react

Then add 'react' to your .babelrc preset.

In your ES6 javascript file you can now use react via:

import React from 'react';

----

That's it.

However, if you have none of that already set up... Then you'll naturally be persuaded that now is the time to get a 'modern' javascript environment setup and doing so can take time. It took me about 2 days of beating through RequireJS --> Webpack --> JSPM before I settled on the latter.

Figuring all that was difficult, but looking back on it was extremely useful to now have all my Javascript bundling done within JSPM rather than using some Django bundler, and downloading raw JS files from the internet without evening using Babel to help me write ES6/ES7.

Re: My Reaction to React

#134

Post by karussell »

Maybe completely off-topic: I've not yet looked really into React and I'm still hesitating as I've seen this mixture of logic (JavaScript) and presentation (HTML) before e.g. via JSP stuff. Or am I misunderstanding something?

Why not create components that do still separate logic and view like Apache Wicket does/did?

Re: My Reaction to React

#135

Post by smadge »

brightball wrote: post #67
skewart wrote: 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…

100% agree on the common language front. The real challenge is when you're dealing with a language that has framework saturation, so there isn't really a "common" framework. Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR th…

I'm not convinced we need a monolithic, standard front-end web framework. If there is a framework, it should just be a collection of libraries, and integrations between those libraries. The libraries should be useful by themselves. If you want to integrate a non supported library(may God be with you), you should be able to write your own simple adapter.

What I don't like is a when a library sneaks it's way into all of my code. The rest of my application shouldn't care what technology I am using for my views. I should be able to swap between the DOM API, jQuery, React, mustache, etc without having to write a single line of code outside of my views.

Re: My Reaction to React

#136

Post by marknutter »

true_religion wrote: post #132
marknutter wrote: post #86

Earlier quoted context omitted.

> You don't have to - but without them stuff gets messy pretty quick. Which is the same as saying "you have to". Can't we just accept that developing with React is no longer as simple as just stitching some views together? It's as if the collective React community is very insecure about the fact that writing web applications is gonna be hard and complicated no matter how shiny your tools are. Sure, you don't have to…

Are there any other options out there part from Flux/Redux patterns? I've been looking into using React (well for the past 4 days of solid research), but I'm finding that pure reducers are a mental-mismatch for me. I'd like something that helps me manage state, and perhaps constraints its flow (like Reach does with unidirecitonal renddering), but not something that tries to abstract state away completely.

Relay and Falcor both remove the need for Flux, I believe, but those solutions involve the backend I believe.

Re: My Reaction to React

#137

Post by cloverich »

Chris_Newton wrote: post #124
cloverich wrote: post #119

Earlier quoted context omitted.

> But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. My view on this is that generally if you haven't extensively used at least a couple of existing fra…

My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion. If your background is mainly in modern JS development, that’s probably true. I don’t think it holds more widely, though. Modern JS lives a little bit in its own world, and the state of the art in that w…

I appreciate the angle and definitely agree. This is really what I think of in general -- when I imagine a new (e.g.) javascript ui framework, I"m hoping that the creator has experience not just in other JS frameworks, but many other UI frameworks. At my last job (for instance) the UI team was grouped together (rather then web ui into the web team), and I always loved comparing architecture for similar components with Windows, Android, etc., and especially the "embedded" guys.

Re: My Reaction to React

#138

Post by jondubois »

gcommer wrote: post #62
jondubois wrote: post #48

I've tried most of the major frontend JavaScript frameworks. My favourite one is Google's Polymer framework - I like it specifically because it is very lightweight, easy to setup, easy to integrate into existing projects and it's ideal for building complex single-page apps. The best thing about Polymer is that, unlike React, it works with W3C standards instead of going off on a tangent and hacking the DOM entirely. I…

> it works with W3C standards instead of going off on a tangent and hacking the DOM entirely While this sounds good on the surface (standards!) I think it is missing part the bigger picture. React, and more generally, the whole ecosystem of related libraries/frameworks it has spawned, is most importantly defined by a move to describing components using pure functions. The virtual DOM diffing is, in my view, just an i…

Polymer is also purely declarative/functional but it doesn't need to do DOM diffing, instead, it relies on the atomicity of individual properties.

Re: My Reaction to React

#139

Post by jondubois »

EdwardMSmith wrote: post #113
marknutter wrote: post #84

Earlier quoted context omitted.

The major difference being, if something is written as a Polymer web component, it's immediately usable by anybody else writing for the web (with the possible exception being React developers because of their unwillingness to acknowledge or adopt web components as a standard).

> Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you…

What I struggle to understand is why you would need need to 'sync' the DOM with your data? If you're dealing with atomic values, you don't need to diff or 'sync' data. In Polymer, when you update data on the frontend, it sends a CRUD update request to the server, the relevant field is then updated in the database, then a realtime notification is sent out to all frontends which are subscribed to changes on that specific field.

Multiple fields might belong to the same 'object' but each field is atomic and can be updated independently of the whole object (without having to diff the entire object each time). This is much more efficient on both the client and server because diffing is expensive and incurs a high latency and bandwidth overhead when you scale out. Diffing is useful for collaborative editing of unstructured text documents, but it is not needed for structured (or even semi-structured) data.

Re: My Reaction to React

#140

Post by true_religion »

marknutter wrote: post #136
true_religion wrote: post #132

Earlier quoted context omitted.

Are there any other options out there part from Flux/Redux patterns? I've been looking into using React (well for the past 4 days of solid research), but I'm finding that pure reducers are a mental-mismatch for me. I'd like something that helps me manage state, and perhaps constraints its flow (like Reach does with unidirecitonal renddering), but not something that tries to abstract state away completely.

Relay and Falcor both remove the need for Flux, I believe, but those solutions involve the backend I believe.

Yes. That's true. I've found out about GraphQL lately, which seems to be with a real possibility for me to use since I have a python backend and Graphene will help with creating an api for GraphQL to consume.
Post reply on HN