I'm confident that all of this could fit neatly on 3 or 4 vertical scrolls (not 20+ as it stands currently)... Without making any compromise to readability, without the rainbow zebra bands.
JavaScript best practices
11–20 of 45 posts
Re: JavaScript best practices
#12Re: JavaScript best practices
#13Not sure why hoisting is listed under "the good parts"
Re: JavaScript best practices
#14Re: JavaScript best practices
#15Lots of dudes on the Who to Follow section? Anyone have any female JS experts to recommend?
This is to be expected from a field which is traditionally male-dominated. Personally I don't think gender matters at all - it is great to want to give exposure to minorities, but people should be valued for their skill, not genitalia.
Re: JavaScript best practices
#16Lots of dudes on the Who to Follow section? Anyone have any female JS experts to recommend?
This is to be expected from a field which is traditionally male-dominated. Personally I don't think gender matters at all - it is great to want to give exposure to minorities, but people should be valued for their skill, not genitalia.
This is to be expected...
Software isn't a 100% male field; maybe 80-90% in my experience. That means:(a) This list is missing great people, e.g. @ErisDS who was the lead engineer (now CTO) for the Ghost blogging platform
(b) This list is thoughtlessly unsupportive of the minority 10-20% in terms of role models. What's the effect of women being constantly portrayed as an underclass of developer by the lack of profile given to successful female devs?
Personally I don't think gender matters at all
That's exactly what someone who hasn't experienced any gender-related workplace problems would think.This utopian finger-in-ears attitude ignores the reality of the harrassment and the systemic uphill battle female devs face in terms of diminishing remarks ("Oh, you must be the designer") and community bias (events typically provide beer & pizza & mens t-shirts).
It's okay, you may not know about all this stuff, or have thought about it from that perspective.
I'm inviting you to level up. It's time.
Re: JavaScript best practices
#17Why do npm and bower both exist? What is the difference between UglifyJS and Closure Compiler? Do I want WebPack or Browserify? Should I use these standalone or should I use them together with Gulp, Grunt, or another build tool? Which of the hundreds or thousands of plugins for the build tools should I use (Gulp has 1,532 plugins and Grunt has 4,403!!)? Should I use CommonJS, ES6 modules, AMD, UMD, or something else? Don't even get me started on application-level frameworks like React, Angular, Ember, etc.
I have reasonably good answers to these questions in my head right now, but three days ago I had no clue. And it really is a maze, because while all of these projects have flashy web pages and nifty "getting started" guides, their docs rarely explain the role of their tool in the big picture, and its relationship to other tools, they just give you examples and point to recipes. And there aren't a set of best practices for setting up a project that cover 99% of common needs painlessly -- you really have to get your hands dirty and configure the tools, in my experience.
I mean, take a step back and writing JavaScript in 2015 is pretty weird. Writing JavaScript in Node.js involves writing things like require() that the browser doesn't understand at all. So you have to run code like that through a tool before you can use it in a browser at all. But what tool exactly? There are so many to choose from, all of which have their own way of being configured. To write JavaScript in 2015, you basically have to sit down and choose a language dialect design a compiler pipeline to match.
I mean, just look at the Babel "setup" guide and how many different variations there are in the instructions based on what tools/frameworks you are using! https://babeljs.io/docs/setup/#make
The point of all this isn't to criticize, but more to offer my experience of being extremely confused/overwhelmed.
Hopefully a lot of this will get better once ES6 is ubiquitous.
Re: JavaScript best practices
#18Re: JavaScript best practices
#19This is great, but what I think is sorely needed is a roadmap to navigating the maze of module systems, transpilers, preprocessors, packagers, etc. Why do npm and bower both exist? What is the difference between UglifyJS and Closure Compiler? Do I want WebPack or Browserify? Should I use these standalone or should I use them together with Gulp, Grunt, or another build tool? Which of the hundreds or thousands of plugi…
I would not say that it answers all of your questions, but I thought it was nice. I guess the short answer for me was CommonJS and thus Browserify on the front-end.
Note: I'm not a JS expert, but at work we have a number of repos written in JS, both "back-end" Node.js projects, and "front-end" JS and a Chrome extension (also JS). I know for a fact that I don't know what I'm doing (I am not going to take the time to learn about CommonJS, AMD, UMD, "Interop", etc., and I've just learned the basics of ES5 and am not eager to rush into ES6 or Babel) and when I find myself in such cases I like to take the simplest approach that seems to work.
Re: JavaScript best practices
#20JS best practices are questionable at best. As an example, when React came out everyone was saying how much of a terrible idea it was (with me being one of those people, unfortunately), and how templates and code should be kept separate... But then I tried it, and I realized just how wrong I was. It makes a lot of sense to keep related things together. Your component's logic / template can be in one place, and your application logic is kept elsewhere.
I read a lot about JS, and I get the impression a lot of people are just hacking together websites with JS sprinkled on top, or hackathon-style apps that they don't plan on maintaining for longer that a few weeks. So their "best practices" end up being questionable at best. Basically, who are you to claim that whatever you're doing is a "best practice"? It seems like a pretty bold claim, so I'd argue that it's not unreasonable to expect someone to back up their claims.
As a side-note, why don't people ever talk about testing? And not just linking to some tools, but actually talking about how you figure out what things are worth testing, and how you test em.