7 ms·

How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion o

How would you suggest developers actually figure out what tools to use? It is next to impossible to make an informed decision without digesting a good portion of what the OP is talking about. You need to start somewhere.

drostie 10y ago
This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices. Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things. But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here. The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."
- murukesh_s 10y ago
  100% agree with the point "start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around."
cloverich 10y ago
Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one uses HTML anymore". There's nothing wrong with using those -- and frankly using plain old javascript and HTML is fine. Remember we reached for jQuery in the first place because the browser lacked features we wanted, and because it handled cross browser stuff for us. That is, it simplified things we were already doing manually. So the trap is bad advice like "use these 58 libraries" combined with an inexperienced person making the architecture choices. I'd say instead (if you're the inexperienced person) just start building stuff. Then every time you said "this is repetitive, I wish there was a library that did this for me" -- there will be. Go out and get it, and you'll then understand why it exists.
- mathgeek 10y ago
  I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.
  - snlacks 10y ago
    Yeah, it's true, but I've also been in interviews where I told them I was using a tool that I think they thought was too hipster and ended up just being ahead of the curve (Babel or TypeScript, don't remember which one, both were just picking up popularity) while still being looked down on because of jQuery. These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.
  - lloyd-christmas 10y ago
    Interview question: "iterate over an array": angular.forEach([1,2,3] ... $.each([ 1, 2, 3 ], ... [1,2,3].forEach(... One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own. This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.
lloyd-christmas 10y ago
"I want to study oncology" - On the biological side? Go learn biology. On the ML research side? Go learn basic python syntax before trying to train a neural network. I usually see 3 categories: - I want to learn Web Development. - I want to learn Web Development, but in all actuality I'm going to quit in 3 days. - I want to learn Web Development, but in all actuality I just want something working with no effort. None of these need an informed decision. The latter 2 don't matter anyway, and the first one is better off starting with a vanilla ajax request[0], and they likely know it. When it comes down to it, "I'm going to make an app today" means your decision likely doesn't have long-term consequences and an informed decision isn't all that important. Pick up jquery like the other 80% of the living internet[1]. [0] https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-with-vanilla-javascript--cms-25763 https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-... [1] http://trends.builtwith.com/javascript/jQuery http://trends.builtwith.com/javascript/jQuery
garysieling 10y ago
For Javascript I'd start from a project template (e.g. https://github.com/sahat/hackathon-starter https://github.com/sahat/hackathon-starter). This approach teaches you learn some useful defaults and how the pieces fit together, as well as where the defaults break down.
tunaoftheland 10y ago
I've found that settling on a fairly narrow set of tools that will cover most use cases is a good start. "Best tools for the job" is not a good advice in the JS app development... Rather, "Good-enough tools for most situation" has been what I've been telling myself. (The caveat is that I am the only developer in this case, or I am in a position to determine the technology stack for the rest of the team.) Personal anecdote: I chose React as a starting point as its component model and lifecycle API just clicked better with my mind. I tried Angular 1.x and, while I liked that it defined application structure more, I couldn't motivate myself to study its component model and lifecycle. Things might have changed since Angular 2.x, but I don't want to go through a technology churn again trying it out. Then I noticed React Native plus other spinoffs like React Native for Desktop. Those projects seem fairly active and appeared to be offering mostly consistent APIs (React, JSX) for a somewhat narrower but still large set of use cases for cross-platform application development. So at that point, I decided to freeze the searches and build out the rest of the choice around it, partly based on the React community's support of the libraries and tools (Redux, Webpack, etc.) I do catch myself getting distracted here and there checking out other libraries and tools, and they might genuinely be superior in the context of an objective, head-to-head comparison. But having built up some familiarity and skills using the current choices, I can't justify the time and attention span lost switching to another set of libraries. Afterall, by then, something even better will have come along. :) EDIT: I wanted to just add, "The fewer APIs I have to look up in the docs to use, the better" also has been a guiding principle as well. For example, I just use Webpack for build as well as bundling, as I don't want another API in the project for the builds (like Gulp, even though devs seems to like it).
marrs 10y ago
A good place to start is by writing productive code. As part of the development process, look back on what parts of the code are holding you back the most. Perhaps bugs keep appearing in this dialogue, or that list renders very slowly, or setting up the unit tests takes a lot of boilerplate. Something on the project will be impacting your delivery the most. Work out what it is if it isn't already obvious, then fix it. You might do this by using a pre-existing library, or you might write your own solution. Either way, by going through the problem solving process, you will develop some of the skills needed to recognise the motivation behind the solutions provided by 3rd party libraries and you will be in a better position to evaluate them.

drostie 10y ago

This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices. Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things. But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here. The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."

murukesh_s 10y ago
100% agree with the point "start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around."

cloverich 10y ago

Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one uses HTML anymore". There's nothing wrong with using those -- and frankly using plain old javascript and HTML is fine. Remember we reached for jQuery in the first place because the browser lacked features we wanted, and because it handled cross browser stuff for us. That is, it simplified things we were already doing manually. So the trap is bad advice like "use these 58 libraries" combined with an inexperienced person making the architecture choices. I'd say instead (if you're the inexperienced person) just start building stuff. Then every time you said "this is repetitive, I wish there was a library that did this for me" -- there will be. Go out and get it, and you'll then understand why it exists.

mathgeek 10y ago
I've been to more than one interview where I defaulted to jQuery and was immediately disqualified, based on the looks on the interviewers' faces. As a ruby developer, it certainly feels like keeping up-to-date on JS takes more work than the other 90% of languages that I'm familiar with.
- snlacks 10y ago
  Yeah, it's true, but I've also been in interviews where I told them I was using a tool that I think they thought was too hipster and ended up just being ahead of the curve (Babel or TypeScript, don't remember which one, both were just picking up popularity) while still being looked down on because of jQuery. These interviews usually end and then when I look up the company 3 months later they don't exist anymore or have pivoted.
- lloyd-christmas 10y ago
  Interview question: "iterate over an array": angular.forEach([1,2,3] ... $.each([ 1, 2, 3 ], ... [1,2,3].forEach(... One of these things is not like the other. I hire people that know javascript, not ones that only know the tool we use. The tool we use today may not be the tool we use 6 months from now. I've never asked a javascript question that required framework knowledge unless it was explicitly about concepts of the framework. Someone taking the time to include jQuery is instantly out the door. Walking through people's code demonstrates whether or not they default to other people's solutions than their own. This isn't to say your experience didn't happen, I'm just pointing out that there is a lot more that goes into it than just which framework the cool kids are using nowadays.

lloyd-christmas 10y ago

"I want to study oncology" - On the biological side? Go learn biology. On the ML research side? Go learn basic python syntax before trying to train a neural network. I usually see 3 categories: - I want to learn Web Development. - I want to learn Web Development, but in all actuality I'm going to quit in 3 days. - I want to learn Web Development, but in all actuality I just want something working with no effort. None of these need an informed decision. The latter 2 don't matter anyway, and the first one is better off starting with a vanilla ajax request[0], and they likely know it. When it comes down to it, "I'm going to make an app today" means your decision likely doesn't have long-term consequences and an informed decision isn't all that important. Pick up jquery like the other 80% of the living internet[1]. [0] https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-with-vanilla-javascript--cms-25763 https://webdesign.tutsplus.com/tutorials/an-example-of-ajax-... [1] http://trends.builtwith.com/javascript/jQuery http://trends.builtwith.com/javascript/jQuery

garysieling 10y ago

For Javascript I'd start from a project template (e.g. https://github.com/sahat/hackathon-starter https://github.com/sahat/hackathon-starter). This approach teaches you learn some useful defaults and how the pieces fit together, as well as where the defaults break down.

tunaoftheland 10y ago

I've found that settling on a fairly narrow set of tools that will cover most use cases is a good start. "Best tools for the job" is not a good advice in the JS app development... Rather, "Good-enough tools for most situation" has been what I've been telling myself. (The caveat is that I am the only developer in this case, or I am in a position to determine the technology stack for the rest of the team.) Personal anecdote: I chose React as a starting point as its component model and lifecycle API just clicked better with my mind. I tried Angular 1.x and, while I liked that it defined application structure more, I couldn't motivate myself to study its component model and lifecycle. Things might have changed since Angular 2.x, but I don't want to go through a technology churn again trying it out. Then I noticed React Native plus other spinoffs like React Native for Desktop. Those projects seem fairly active and appeared to be offering mostly consistent APIs (React, JSX) for a somewhat narrower but still large set of use cases for cross-platform application development. So at that point, I decided to freeze the searches and build out the rest of the choice around it, partly based on the React community's support of the libraries and tools (Redux, Webpack, etc.) I do catch myself getting distracted here and there checking out other libraries and tools, and they might genuinely be superior in the context of an objective, head-to-head comparison. But having built up some familiarity and skills using the current choices, I can't justify the time and attention span lost switching to another set of libraries. Afterall, by then, something even better will have come along. :) EDIT: I wanted to just add, "The fewer APIs I have to look up in the docs to use, the better" also has been a guiding principle as well. For example, I just use Webpack for build as well as bundling, as I don't want another API in the project for the builds (like Gulp, even though devs seems to like it).

marrs 10y ago

A good place to start is by writing productive code. As part of the development process, look back on what parts of the code are holding you back the most. Perhaps bugs keep appearing in this dialogue, or that list renders very slowly, or setting up the unit tests takes a lot of boilerplate. Something on the project will be impacting your delivery the most. Work out what it is if it isn't already obvious, then fix it. You might do this by using a pre-existing library, or you might write your own solution. Either way, by going through the problem solving process, you will develop some of the skills needed to recognise the motivation behind the solutions provided by 3rd party libraries and you will be in a better position to evaluate them.