TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why We Moved to React

158 点作者 sorcercode大约 9 年前

20 条评论

tracker1大约 9 年前
In this way, it seems that React makes a lot of sense as a migration path. Honestly, I find flux&#x2F;redux and other unidirectional data flows are much easier to scale than most patterns for UI development, especially class&#x2F;oo ones.<p>That said, React is just a part of it, and some flows are counter-intuitive in React. This must be said because it is true... that said, I find that React is far better, all around than most of the other options I&#x27;ve used, and I&#x27;ve been building web apps for two decades now.<p>I&#x27;m currently working on supporting an Angular 1.x app, have a proof of concept built in Redux+React, and another app I&#x27;ve been instructed to write in Angular 2. I&#x27;ve also built a couple of SPAs using Backbone. In the end the Redux flow has meant less code as features are added, and I&#x27;m working towards writing my Angular 2 app with that in mind. Modern React takes a lot of tooling setup to get started (or starting with someone&#x27;s existing boilerplate), but the shear amount of boilerplate code that you have to write with Angular2 is just unnerving. The DI model is awkward, and I&#x27;m not enjoying it at all...<p>The Redux+React proof of concept is for half the functionality of the Angular 1.x app, I&#x27;m pushing for the change in the next version... with about 1&#x2F;3 the functionality, the code is 1&#x2F;10th the size, and there&#x27;s a lot less complexity... A single state tree, in the end is easier to reason with, even if you&#x27;re only looking at part of it. It&#x27;s much easier to deal with, even with scale than trying to add more message channels in an application between components. Getting used to separating actions via a single dispatcher, and the resulting state changes takes getting used to... but so much easier in the end.
评论 #11186515 未加载
评论 #11186909 未加载
评论 #11186392 未加载
评论 #11187283 未加载
评论 #11186301 未加载
bschwindHN大约 9 年前
I like the idea of React. I like it even more when you take out all the frills and boilerplate. If you haven&#x27;t already, I would encourage you to give Clojurescript and Reagent a try:<p><a href="https:&#x2F;&#x2F;reagent-project.github.io" rel="nofollow">https:&#x2F;&#x2F;reagent-project.github.io</a><p>I decided to use it for a small client for a chat server my company runs. The initial environment setup on OS X wasn&#x27;t the smoothest, but once I got that taken care of the actual development was very pleasing and quick. You need to know just a few core concepts and then you can more or less replicate the common patterns you use in React - application state, component properties, local component state, initial values for local state, etc.<p>Along with that, you get immutable data structures and the benefits of the Google Closure Compiler out of the box. Give it a shot!
评论 #11186983 未加载
drdaeman大约 9 年前
I must&#x27;ve done something wrong, but I haven&#x27;t attained that &quot;zen&quot; part when I tried to use React. On the contrary, it felt like I&#x27;m writing a giant pile of boilerplate code &quot;just to use React&quot;, where there shouldn&#x27;t be any.<p>A simple, almost ToDo-like form quickly grew to 7 files, averaging 100 SLOC each, with a air-filled boilerplate-feeling classes (yet not lacking works-by-convention magic) that juggle data through those render -&gt; onClick={e =&gt; this.onItemAdd(e)} -&gt; onItemAdd -&gt; addItem -&gt; update -&gt; UpdatePromise -&gt; handleUpdateItems -&gt; render loops.<p>Sure, everything&#x27;s logical but that feels like I&#x27;m deeply stuck in the wheel of Samsara, writing code for its own sake and not attaining any Enlightenment. ;)
评论 #11187526 未加载
评论 #11188029 未加载
ridiculous_fish大约 9 年前
React has been quite nice, and very fast to work on. But there&#x27;s one aspect that&#x27;s concerning.<p>You have state and props, and the React tree diffing algorithm attempts to make some minimal set of changes that preserves state. However this algorithm is a heuristic, and so it&#x27;s possible to hit a case where your component gets a different component&#x27;s state.<p>For example, say there&#x27;s a text field which has keyboard focus. Another text field is added above it: the keyboard focus should stay in the bottom text field. But React has no notion of identity and doesn&#x27;t know whether the top or bottom text field is new. All it sees is a diff from one text field to two, and who knows which one will get focus!<p>React&#x27;s answer to this is to introduce identity by assigning each component a key, and that works. But this is reactive: I notice a bug, and fix that case by assigning a key, but still most elements do not have a key and it is not reasonable to add one. I&#x27;m stuck hoping that the opaque tree-diffing heuristic is correct enough for my case.<p>How do other React users handle this? How do you go from &quot;seems to work&quot; to &quot;I am certain React&#x27;s tree diff will assign the right state to the right components in all cases?&quot;
评论 #11187598 未加载
评论 #11186655 未加载
评论 #11186657 未加载
评论 #11187515 未加载
jorgecurio大约 9 年前
one of the biggest changes was accepting that React is different from old way of doing things like with jquery.<p>I used jQuery to build 4k loc applications. It&#x27;s a fucking blast when you are just wiring up the template and watching the UI come alive...to me that was the power of jQuery. No need to think, just go and make everything stick like glue.<p>Angular.js was also right in that regard....add annotation to HTML. but this shit doesn&#x27;t scale when application grows.<p>I&#x27;m still frustrated that I can&#x27;t write shit in jQuery anymore because HN have collectively ruled against it and I guess at 4k loc it has become very hairy.<p>But I still argue if your needs are pretty small, like make a small widget app that has two buttons and makes ajax request to an endpoint, no other frontend framework can even touch jQuery in this territory....<p>In fact the overhead of having to think about states, structures, components organized in hierarchy...this shit adds to my stress and I can&#x27;t experiment fast...but then also was the stress from not being able to add new features because the jQuery app grew in complexity....<p>difficult times gentlemen difficult times. I&#x27;ve been holding on to jQuery since 2009...maybe it&#x27;s time to venture out entirely with React.js? Or should I crawl back to the comfortable cave that is jQuery where I can make <i>anything</i> very quickly.
评论 #11186531 未加载
评论 #11186483 未加载
评论 #11186723 未加载
评论 #11186639 未加载
评论 #11189692 未加载
评论 #11187570 未加载
评论 #11186562 未加载
philmander大约 9 年前
It&#x27;s clear why using React in your Backbone views is beneficial, but I&#x27;d be genuinely interested to know what tangible benefit moving the models (and, thus, entirely from Backbone I guess) to flux&#x2F;redux etc brings you, besides just keeping up with the latest conventions.
评论 #11186580 未加载
phat4life大约 9 年前
Personally, I prefer more web-component like frameworks. Vue.js is more usable, and easier to understand than React, but stuff like React Native is why React.js is worth learning.<p>I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I would like my to write my components as dom nodes, like with Vue.js, Riot. The way that react.js handles css, is also messy. I would rather just defined a &lt;style&gt; tag like in Vue.js.
评论 #11186347 未加载
评论 #11186329 未加载
评论 #11186318 未加载
评论 #11189591 未加载
pmlnr大约 9 年前
<a href="https:&#x2F;&#x2F;www.instacart.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.instacart.com&#x2F;</a> -&gt; among the JS loaded: static-react-base-{id}.js 273KB. It it just me thinking that ~300KB of code, about to be evaluated in the browser is a bad idea?
评论 #11187945 未加载
Kiro大约 9 年前
I&#x27;m interested in learning more about reusability. One problem I have with React is that I&#x27;ve made this component called Product and then I need another Product component but in a different context, for example in a listing with a thumbnail. Much like the carrot example. How do you approach this exactly? Shouldn&#x27;t it be based on the same component somehow?
评论 #11187470 未加载
评论 #11186954 未加载
评论 #11187076 未加载
评论 #11186968 未加载
ezequiel-garzon大约 9 年前
As I go over the impressive list of big sites adopting React [1] I feel there must be something wrong with this current survey [2], which states a mere 67 of the top 10000 sites are using it. Any insight will be welcome.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;wiki&#x2F;Sites-Using-React" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;wiki&#x2F;Sites-Using-React</a><p>[2] <a href="http:&#x2F;&#x2F;trends.builtwith.com&#x2F;javascript&#x2F;javascript-library" rel="nofollow">http:&#x2F;&#x2F;trends.builtwith.com&#x2F;javascript&#x2F;javascript-library</a>
评论 #11186716 未加载
b34r大约 9 年前
The forceUpdate API is murderous for performance, since it causes the entire tree to do a vdom rerender, bypassing shouldComponentUpdate() checks. Should really try and find another way to trigger a re-render.
评论 #11186550 未加载
评论 #11186460 未加载
评论 #11186637 未加载
Aleman360大约 9 年前
As a C++&#x2F;XAML mobile app dev, I&#x27;m baffled by how a common UI like this (lots of lists?) requires such a deep dive.
评论 #11208171 未加载
评论 #11187566 未加载
kzhahou大约 9 年前
Dominic, when did you start rolling out this change, and how long have significant parts of production been on it?<p>I&#x27;d be very interested in a follow-up in a year, once it&#x27;s grown to the size of the backbone app it&#x27;s replacing, and been battle-tested (in prod and in development)
评论 #11186663 未加载
aioprisan大约 9 年前
I was checking out their careers page and they&#x27;re looking for a senior engineer to lead 5 engineers, but they require masters degrees? Really? Newsflash: a one year degree isn&#x27;t what&#x27;s needed to be a successful team lead.
评论 #11187998 未加载
capkutay大约 9 年前
&gt; As an experiment, we tried writing a separate app to try out the popular Flux library.<p>Is there one &#x27;popular Flux library&#x27;? Perhaps they meant redux? No other mention of it in the article.
评论 #11186400 未加载
评论 #11186454 未加载
partycoder大约 9 年前
Saying CoffeeScript is simpler than JavaScript is the same as saying: I am going to make traffic simpler by removing lane delimiters, traffic signaling, lights, street names. You end up with a &quot;simpler&quot; language, but it is also less safe to use. Python will throw you an error with inconsistent indentation, but that&#x27;s not the case in CoffeeScript. So any little messing with the whitespace, which is impossible to infer automatically, and you have a bug.<p>Then, you can massively auto-format JavaScript, use great tools that inference type information from documentation, etc... but with VomitScript, you are pretty much on your own. In fact using an advanced editor and nano will probably make no difference.<p>&quot;Duh but I want to type less&quot;... NOBODOY CARES about you typing less. If you care about typing less use templates in your editor and autocomplete.
carsongross大约 9 年前
Peguy&#x27;s quote:<p><i>&quot;And it will never be known what acts of cowardice have been motivated by the fear of looking insufficiently progressive.&quot;</i><p>becomes more and more relevant to the tech world.<p>We are managing a few lists. How is this so complicated?
评论 #11187800 未加载
ausjke大约 9 年前
for newcomers is it too hard to find all the pieces that need to work with React to make a final product? I just started with Angularjs 1.x, while it has its faults I found it&#x27;s easier to get started.<p>maybe React is better suited for the experienced who knows how to bootstrap all the components? I&#x27;m interested in learning React _after_ I get more familiar with the javascript-ecosystem, and it seems to start with angularjs will be a good approach?
ConAntonakos大约 9 年前
What is Instacart using for its routing logic?
评论 #11188494 未加载
kensign大约 9 年前
No matter how I try to accept it, it is a really bad idea to embed views into business logic. You have no clear separation of concerns and this can create a lot of headaches as the sophistication of the application grows. Instacart is a great product, but it has a lot of room to grow still. What happens when you get into some deeper aspects of UX? I presume you do your own UX research and these highly segmented views are going to be a pain to manage.<p>You&#x27;ll also need to worry about how you run BDD tests for specifications and scenarios. How can this be achieved in React as you write test suites for user stories and non-UI acceptance tests? How will this impact your continuous delivery&#x2F;integration systems as well? You&#x27;ll have to rewrite all your test suites into Jest, right?<p>There are architectural trade-offs for sure. Can you definitely say you&#x27;ve performed a thorough analysis before making this decision? There&#x27;s a difference between having a clear strategy to move from one tech to another and knowing that the migration will not just bury you into a deeper whole than the one you think you&#x27;re escaping.<p><a href="http:&#x2F;&#x2F;aurelia.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;aurelia.io&#x2F;</a> is based on webcomponents (MVVM), ES6, and current web standards. It&#x27;s amazingly simple and good architects can use their own structural patterns to create code that can actually scale with the product. DDD and BDD methodologies mesh perfectly into the development workflow, especially with Agile product development.<p>I wish you well, but I really think React is a short sell with dire consequences.
评论 #11186679 未加载
评论 #11186833 未加载
评论 #11186998 未加载
评论 #11186766 未加载
评论 #11187549 未加载
评论 #11186727 未加载