91–100 of 119 posts
This guy expresses a lot of opinions about React/Redux that I share, but he doesn't understand something fundamental about web development. The look and feel of the page comes first, and the structure and coherence of the code comes second. And you don't really need complicated, fast UI for most web projects.
Earlier quoted context omitted.
Immutable.js is just another complication with another 60k size penalty with a few new negative drawbacks that he would need more complexity to solve. Author is already arguing against this approach.
60k is hardly an issue, most hi-res images would be larger than that. Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers. Add to that tree-shaking (removing unused code) and the long term size of your app is looking good. I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoo…
It seems there's some minimum (think Greenspun) JavaScript necessary to have a working SPA that handles DOM manipulation, network communication, state management, module management, events, et cetera, somewhere between 50k and 100k. I would love to be proven wrong about this. Maybe as native ES6 (or WebAssembly) becomes the norm this will be less the case.
Somehow author jumps from the problem of convenient data structures updating and immutability to Redux which solves a different problem. There are several things about React, Redux and React based tech stacks: 1. React requires knowledge of basics of functional programming React looks like it's easy to pick up but if you don't know or want to learn at least basics of functional programming then it's not for you. With…
I find the highlighted article on Facebook's "reason" for inventing Flux/Redux very laughable. - This message unread indicator kept saying (1). And how it went away with bug fixes and came back...
Did they ever stop to realize they just had some really bad devs working on the chat app? Any re-write, whether they had to invent flux or not would have fixed that indicator. It's a false story.
Earlier quoted context omitted.
"there are no immutable primitives" Many array prototype functions work in an immutable way like map and reduce
Updating an array element arr[3] = 'New content'; Updating an array element immutably arr = arr.map((element, index) => { if (index === 3) return 'New content'; return element; }); It's possible, sure, but it feels terrible. JavaScript objects want to be mutated - it's the most idiomatic way of interacting with them. Whether functional programming paradigm is good (I certainly feel it is) is beside the point - JS was…
This can avoid boilerplate traditionally associated with immutable updates in JavaScript, because you just write
const copy = transform(original, stage => {
stage.someArray[index] = 42;
});
Earlier quoted context omitted.
if you use ES2015: arr = [ ...arr.slice(0, 2), 'New Content', ...arr.slice(3) ]
In my eyes this slice of code is even worse than the array map one, where there is 2.5 pieces of logic (map, if, and 2 return that makes for the .5). In the version you have 2 spread operators, an array construct and 3 hardcoded ints. I might not use the correct academic terms, and I might not be yet fully accustomed to es2015, but this way of writing stuff always make me pause and double check the code.
const arr2 = Object.values({...arr, 3: 'New Content'});
Earlier quoted context omitted.
60k is hardly an issue, most hi-res images would be larger than that. Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers. Add to that tree-shaking (removing unused code) and the long term size of your app is looking good. I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoo…
I was trying to get into ClojureScript a few months ago, intrigued by the tree-shaking of the Closure Compiler. I was thoroughly disappointed when my compiled hello-world yielded compiled code in the neighborhood of 70k. Surely I configured something poorly or didn't install the right leinegen packages, but coming from webpack this is a pretty discouraging out-of-the-box experience. It seems there's some minimum (thi…
Choosing libraries shouldn't require careful examination of their output file size, especially if you only want half the functionality.
Try using ES destructoring and spread operators plus a library like Kea ( https://kea.js.org ) to provide a framework over Redux and most of these arguments become irrelevant.
Not the author, but my opinion on the matter is that react already has too many abstractions and helpers, which just adds to the problem. React is difficult to grok on its own. Adding another framework to the tech stack just makes it worse if you don't already have a fluent understanding of the layers beneath. This is my experience with it, at least.
This guy expresses a lot of opinions about React/Redux that I share, but he doesn't understand something fundamental about web development. The look and feel of the page comes first, and the structure and coherence of the code comes second. And you don't really need complicated, fast UI for most web projects.
Yes, but I sense that he's in a similar boat as me right now. I just joined this team that's already using React/Redux, and the code quality is... very sad.
I'm one of the laggards - Over the years, based on staying around tech communities (esp. HN) I've learned not to invest time / effort into the hype that surrounds a newly launched tech. I did burn my finger a couple of times, especially with MongoDB back then, so these days I'm pretty cautious. I'm one of the very few who didn't invest in React. I waited it out and invested into Vue.JS, instead. This is no framework…
> ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: That's definitely not what's bad about React. In fact that's what great about React -- coherent widgets (components) that are defined in a single place. Not to mention that JSX in React it's all JS and properly parsed and checked -- the "HTML" there is just sugar. Such separation of H…
I get his point -- javascript object observation has been a pain, and causes the stated workaround.s With new API like Proxy [1], we should not be able to just modify data as needed, and any observers can be notified by handlers in the object get/set. This will lead to data being fully mutable. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...