3 ms·

A lot of posts on this thread about js library fatigue are advocating for... more libraries. Go figure. :) I advocate the opppsite: use as few tools as possible

by johnfn 10y ago

A lot of posts on this thread about js library fatigue are advocating for... more libraries. Go figure. :) I advocate the opppsite: use as few tools as possible, until you realize why a tool is necessary. With my current project, I started off with just Backbone and Typscript. Eventually, after hitting a few walls, I was like "ah, that's why React is necessary over Backbone". Then I realized why Redux was necessary. Then immutable. Then webpack. Each of these little revelations coming a month or two apart. The problem with instantly installing every dev requirement you think you might need is that you may not actually need as many as you think, and then you're burdened with unnecessary complexity. Along with, of course, the pain of learning and dealing with the intricacies of getting dependency each set up. Depending on the size of your project, Redux may not be necessary. Nor immutable, etc. But you won't know if they are necessary until you understand them, and that only comes after using them or feeling the pain of not using them. The only tool I believe is truly necessary for any web project is TypeScript. I could write a small novel on why, but the crucial reason here is that it enables you to do all the above refactoring with ease. Refactoring vanilla js is a nightmare.

agnivade 10y ago
> Refactoring vanilla js is a nightmare. Interesting. I think if ES6 is properly used, thats good enough. At least with the sizes of projects I have worked on. And I think the webpack is the single most awesome thing to happen for front end development. With webpack 2, things are just better than ever. With an overhauled doc site and good examples, its all of the good stuff.
- gibbitz 10y ago
  I guess since ES5 is the language spec I've used the longest, I find refactoring vanilla JS to be enjoyable since most frameworks exist to clean up ugliness. Many frameworks add boilerplate and foreign patterns that can make this difficult, though. When I run against this, however, I have to re-assess the value of the framework I'm adding and if it still exists, refactoring is not what's needed as much as a re-write. This is the primary reason for writing code that is modular on as many levels as possible. I worry about the React/Flux patterns at this point in that they are creating codebases where modularity is specific to their pattern which could be tomorrow's anti-pattern (Prototypejs anyone?). I suspect we'll be cursing refactoring these codebases soon.
whytaka 10y ago
>I was like "ah, that's why React is necessary over Backbone" >Then I realized why Redux was necessary. >Then immutable. >Then webpack. I'm eager to learn. What were those revelations exactly? If you could provide an example, it'd be really helpful.
- 9935c101ab17a66 10y ago
  I hope I can provide some insight for two of your points, though I'm not the most experienced dev in the world: Redux: Though it is complicated to grasp the tenants of redux, and it sometimes does involve writing a lot of boilerplate, it adds value by containing the entire state of a web app in a single object. To achieve a change in state, you dispatch an action that should describe the change being made. When an action is dispatched, a reducer is called on the existing state object, which returns a NEW object representing the new state for the web app. You do not modify the existing object. By representing all state in a single object, dispatching actions (that should describe the change occurring), and using reducers to return a new object to represent the state, the state of complicated web apps should be much easier to understand and reason about. By using tools like the redux dev tools, it is even theoretically possible to 'time travel' through a users journey on your site (if, say, they hit a bug you are having trouble reproducing). You can see every action they dispatch and how it modified state. Immutable: In my experience, Immutable.js is often used in combination with redux to insure that you are not inadvertently modifying the state object. Inadvertent in place modifications happen very easily, and it can be difficult to write good tests with basic redux to catch all these unwanted behaviours. Using immutable extensively prevents these unintended modifications, and confirms you are returning a new state object rather than modifying the existing one. If anyone has any issues with what I've written, please let me know. I'm newer to JS/React/Redux.
- johnfn 10y ago
  Absolutely! React: React is necessary because when you're using a non-React library, you have a ton of code all over the place that updates the view. Example. Say you have up and down buttons for adjusting brightness. In both of those buttons you'd have to do $('brightness-div').adjustBrightness(newValue). Not so bad. Oh wait, you also have a button which automatically sets the brightness somewhere else, so you need more for that guy too: $('brightness-div').adjustBrightness(getAutomaticValue()). This is OK, but now what if you want to not only adjust the brightness-div, but also the brightness-span whenever the brightness changes? You now have to hunt through your code in n different places to update the code. That sucks. Much better is the React way, which would replace all the direct div access with an update of a shared model. Now you'd just go this.model.brightness = newValue in each of the 3 places. Then in the render() function, which gets called when the model changes, you'd set the brightness of your div appropriately. And when the DOM changes and you need to update more elements, all you have to do is update the render() method to set the brightness of the span as well. Redux: Redux solves the problem of deeply nested dependencies. Say you have a bunch of nested objects in your project - your App has a Menu Bar, which has a Menu Item, which has a Label. Now, the App has the filename, but the Label needs it, because it's a Save "Filename" label. The traditional way would be to pass down the file name from App to Menu Bar to Menu Item to Label, which works, but it's kinda crappy. You have to update 4 classes just to pass some data around. And if you want to refactor your Menu Bar, or move the Label somewhere else, you have to remember to pass the data a different way now. The best way to understand Redux is that it gives you a giant global variable of all the state in your app. ALL OF IT. Then you can slice it up and each component can take only the pieces it need. Now Label can simply tap into the global variable, grab the file name, and be done. (It also gives you some regimented ways of updating the global variable in such a way that everything doesn't descend into insanity, like stuff sometimes does with global variables.) This is why a lot of people don't get Redux - they don't have deeply nested dependencies, so it doesn't really change their code in any way, except to add boilerplate. But if you have reached the size where you do, it's a life changer. Seriously. Immutable.js: This one's easy - and yet curiously I've never seen my explanation for why immutability is necessary anywhere. People always start talking about data races and concurrency, which never make any sense to me because if you have a sequencing problem with mutable data, you're gonna have the same sequencing problem with immutable data. Immutable data is not a panacea! But I digress. Let me get to the explanation. Say you have a HashSet of Points. You put point1, point2, and point3 into the HashSet. Now, you say var p = Set.getFirstPoint() and then do p.x += 5. Does your HashSet contain p now? It's a trick question! Sets do comparisons by comparing hashes, and they do the hashing when you insert the point into the HashSet. The HashSet can't possibly know that the hash value of your point has changed, because you haven't touched the HashSet at all, just the point inside it. Even if it could, expecting a harmless line of code like "p.x += 5" to go off and update a bunch of HashSets intuitively feels insane! What does this have to do with immutability? Well, look what happens if Point is immutable. Now you can't just go and mutate your point directly to change it's position in the Set - you'd have to remove it from the HashSet, and add a new one. Now the HashSet knows that you changed its contents, because you removed and added a point. So the hashes are always consistent. Obviously immutability isn't just necessary for keeping hashmaps consistent, but hopefully this allows you to see how immutable data allows you to write data structures that don't get out of sync with each other. It eliminates some ways for that "out-of-sync"-ness to happen. Webpack: This one's the easiest of all. Eventually, you're going to need modules. So, you install Webpack. THE END. :D I avoided Webpack for a long time because the webpage makes it look hard to use, but it's actually very straightforward once you click through about 6 pages of why Webpack is the best thing ever. (Sigh.) --- I hope that all is helpful in some way!

by johnfn 10y ago

agnivade 10y ago

> Refactoring vanilla js is a nightmare. Interesting. I think if ES6 is properly used, thats good enough. At least with the sizes of projects I have worked on. And I think the webpack is the single most awesome thing to happen for front end development. With webpack 2, things are just better than ever. With an overhauled doc site and good examples, its all of the good stuff.

gibbitz 10y ago
I guess since ES5 is the language spec I've used the longest, I find refactoring vanilla JS to be enjoyable since most frameworks exist to clean up ugliness. Many frameworks add boilerplate and foreign patterns that can make this difficult, though. When I run against this, however, I have to re-assess the value of the framework I'm adding and if it still exists, refactoring is not what's needed as much as a re-write. This is the primary reason for writing code that is modular on as many levels as possible. I worry about the React/Flux patterns at this point in that they are creating codebases where modularity is specific to their pattern which could be tomorrow's anti-pattern (Prototypejs anyone?). I suspect we'll be cursing refactoring these codebases soon.

whytaka 10y ago

>I was like "ah, that's why React is necessary over Backbone" >Then I realized why Redux was necessary. >Then immutable. >Then webpack. I'm eager to learn. What were those revelations exactly? If you could provide an example, it'd be really helpful.

9935c101ab17a66 10y ago
I hope I can provide some insight for two of your points, though I'm not the most experienced dev in the world: Redux: Though it is complicated to grasp the tenants of redux, and it sometimes does involve writing a lot of boilerplate, it adds value by containing the entire state of a web app in a single object. To achieve a change in state, you dispatch an action that should describe the change being made. When an action is dispatched, a reducer is called on the existing state object, which returns a NEW object representing the new state for the web app. You do not modify the existing object. By representing all state in a single object, dispatching actions (that should describe the change occurring), and using reducers to return a new object to represent the state, the state of complicated web apps should be much easier to understand and reason about. By using tools like the redux dev tools, it is even theoretically possible to 'time travel' through a users journey on your site (if, say, they hit a bug you are having trouble reproducing). You can see every action they dispatch and how it modified state. Immutable: In my experience, Immutable.js is often used in combination with redux to insure that you are not inadvertently modifying the state object. Inadvertent in place modifications happen very easily, and it can be difficult to write good tests with basic redux to catch all these unwanted behaviours. Using immutable extensively prevents these unintended modifications, and confirms you are returning a new state object rather than modifying the existing one. If anyone has any issues with what I've written, please let me know. I'm newer to JS/React/Redux.
johnfn 10y ago
Absolutely! React: React is necessary because when you're using a non-React library, you have a ton of code all over the place that updates the view. Example. Say you have up and down buttons for adjusting brightness. In both of those buttons you'd have to do $('brightness-div').adjustBrightness(newValue). Not so bad. Oh wait, you also have a button which automatically sets the brightness somewhere else, so you need more for that guy too: $('brightness-div').adjustBrightness(getAutomaticValue()). This is OK, but now what if you want to not only adjust the brightness-div, but also the brightness-span whenever the brightness changes? You now have to hunt through your code in n different places to update the code. That sucks. Much better is the React way, which would replace all the direct div access with an update of a shared model. Now you'd just go this.model.brightness = newValue in each of the 3 places. Then in the render() function, which gets called when the model changes, you'd set the brightness of your div appropriately. And when the DOM changes and you need to update more elements, all you have to do is update the render() method to set the brightness of the span as well. Redux: Redux solves the problem of deeply nested dependencies. Say you have a bunch of nested objects in your project - your App has a Menu Bar, which has a Menu Item, which has a Label. Now, the App has the filename, but the Label needs it, because it's a Save "Filename" label. The traditional way would be to pass down the file name from App to Menu Bar to Menu Item to Label, which works, but it's kinda crappy. You have to update 4 classes just to pass some data around. And if you want to refactor your Menu Bar, or move the Label somewhere else, you have to remember to pass the data a different way now. The best way to understand Redux is that it gives you a giant global variable of all the state in your app. ALL OF IT. Then you can slice it up and each component can take only the pieces it need. Now Label can simply tap into the global variable, grab the file name, and be done. (It also gives you some regimented ways of updating the global variable in such a way that everything doesn't descend into insanity, like stuff sometimes does with global variables.) This is why a lot of people don't get Redux - they don't have deeply nested dependencies, so it doesn't really change their code in any way, except to add boilerplate. But if you have reached the size where you do, it's a life changer. Seriously. Immutable.js: This one's easy - and yet curiously I've never seen my explanation for why immutability is necessary anywhere. People always start talking about data races and concurrency, which never make any sense to me because if you have a sequencing problem with mutable data, you're gonna have the same sequencing problem with immutable data. Immutable data is not a panacea! But I digress. Let me get to the explanation. Say you have a HashSet of Points. You put point1, point2, and point3 into the HashSet. Now, you say var p = Set.getFirstPoint() and then do p.x += 5. Does your HashSet contain p now? It's a trick question! Sets do comparisons by comparing hashes, and they do the hashing when you insert the point into the HashSet. The HashSet can't possibly know that the hash value of your point has changed, because you haven't touched the HashSet at all, just the point inside it. Even if it could, expecting a harmless line of code like "p.x += 5" to go off and update a bunch of HashSets intuitively feels insane! What does this have to do with immutability? Well, look what happens if Point is immutable. Now you can't just go and mutate your point directly to change it's position in the Set - you'd have to remove it from the HashSet, and add a new one. Now the HashSet knows that you changed its contents, because you removed and added a point. So the hashes are always consistent. Obviously immutability isn't just necessary for keeping hashmaps consistent, but hopefully this allows you to see how immutable data allows you to write data structures that don't get out of sync with each other. It eliminates some ways for that "out-of-sync"-ness to happen. Webpack: This one's the easiest of all. Eventually, you're going to need modules. So, you install Webpack. THE END. :D I avoided Webpack for a long time because the webpage makes it look hard to use, but it's actually very straightforward once you click through about 6 pages of why Webpack is the best thing ever. (Sigh.) --- I hope that all is helpful in some way!