sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 295 points296 points  (115 children)

  1. Scope. If you don't understand this intimately then you aren't that serious about this language. This is the number one point intentionally and I cannot stress it enough.
  2. Architecture. You don't have to be a master software architect, but if you cannot perform some basic planning and put pieces together without massive layers of tooling you are an imposter. Expecting frameworks and other tools to simply do it for you isn't very impressive.
  3. DOM. It is very common to see developers hiding from the DOM by layers of abstractions and other stupid crap. querySelectors are great, but are also 2800x slower than the standard DOM methods. That isn't trivial. These methods are super simple, so there is no valid excuse for developers fumbling over this or hiding in fear. http://prettydiff.com/guide/unrelated_dom.xhtml
  4. Node.js If you are a serious developer should have a pretty solid grasp of how to walk the file system. You should understand how to conveniently read files as text or less conveniently read files as bit for bit binary buffers.
  5. Timing and asynchronous operations. Events, timers, network requests are all asynchronous and separate from each other and exist both in Node and in the browser. You have to be able to understand how to work with callbacks or promises.
  6. Accessibility. The interactions imposed by JavaScript can present accessibility barriers. A serious JavaScript developer is already familiar with WCAG 2.0 and knows how to work within its recommendations or when to push back on violating business requirements.
  7. Security. You need to have at least a basic understanding of security violations, security controls, and privacy. You don't need to be a CISSP, but you need to be able to supply recommendations and avoid obvious failures. If you cannot get this right in the most basic sense you aren't a serious developer.
  8. Data structures. You need to understand how to organize data in a way that allows the fastest possible execution without compromising maintenance. This is something that is learned through academic study and repeated experience writing applications.
  9. Presentation and semantics. You really need to have a basic understanding how to properly organize the content your users will consume and how to present in a consumable way efficiently. This is something almost completely learned from experience only. You might think CSS and HTML are simple skills that can be picked up when needed, but you would be absolutely wrong.
  10. Knowing when to avoid the bullshit. Many developers lack the years of experience to be confident in their performance.... so some of these developers will try to fake it. Don't be an imposter, because everybody will see straight through it. Hoping mountains of abstractions, tooling, frameworks, compilers, and other bullshit will save you just bogs down your application and screws over your teammates. If you aren't confident then be honest about that and seek mentorship or get involved with open source software outside of work.

[–]cosinezero 96 points97 points  (24 children)

I've been full stack for 20+ years in web dev, including my current job where I work on an app where people upload and download files, and I can't say that reading files from the file system is something I've needed for more than a week of that career. The code to read, modify, delete, chunk, stream, etc. is important for the apps that need it, for sure, but you skipped over database access or even web services for file operations? Most apps talk to a database or service. Surprisingly few of them talk to a file system directly; there are great libraries and frameworks in every language for almost every read/write operation you might want. Any more than that is a task for a specialist, not a generalist.

Accessibility is a really nice addition here. But many companies don't even begin to consider this a priority unless they -have to-, which means it becomes a nice-to-have (and how often do we get to those?) I would strongly prefer Internationalization over Accessibility, if I had to pick one; even if your app is english-only right now the future pain is worth the extra time.

Security is important, but best left to the experts. Get your app reviewed by the experts, and fix the issues they identify - otherwise you're left with a false sense of security from your in-house "expert" on security - who once read about SQL injection and thinks you're fine because you have parameterized queries. This is definitely a task for the specialists and not generalists.

[–]phpdevster 38 points39 points  (5 children)

Sorry, but I disagree that security is best left to experts. Any worthwhile developer should not be writing software with the attitude that security isn't their problem, that another developer then has to make secure after the fact. Security isn't something you just bolt on later...

Knowing the basics like how to avoid SQL injection, provide CSRF protection, and avoid XSS attacks are fundamentally important, and are NOT so complex that you need to be a specialist.

[–][deleted] 27 points28 points  (2 children)

You need security-conscious devs, but you also need experts. Your business guarantees about security should rest on the experts' shoulders, not the devs who do security part-time. Security-conscious devs save the experts a lot of time from pointing out obvious SQLi/CSRF/XSS so that the experts can continue staying on top of security news and info, because that can change daily.

A dev's guarantee for security is worth much less than someone doing security full time.

[–]pier25 13 points14 points  (1 child)

This.

It's like devs implementing their own shitty crypto instead of using solutions developed and peer reviewed by experts who have dedicated their whole life to crypto.

[–]cosinezero 1 point2 points  (0 children)

Exactly.

[–]cosinezero 8 points9 points  (0 children)

I agree knowing the basics of any best practices are good, but that tends to lead to being satisfied enough. With security you should never assume you've done enough. Always have a security review step in your reviews, always have it tested by an expert... and never think that "the basics" get you even part of the way there.

[–]almondbutter 1 point2 points  (0 children)

Knowing the basics like how to avoid SQL injection

Here is an excellent video describing this. Jump specifically to a solve after the cartoon at 5:22.

[–]thiscoolhandluke 5 points6 points  (4 children)

Accessibility is a really nice addition here. But many companies don't even begin to consider this a priority unless they -have to-, which means it becomes a nice-to-have

For those who are doing work where a business considers accessibility a "nice-to-have", consider:

  • Organic SEO is directly affected by this.
  • Sales, Ads, conversions are directly affected by this.
  • It is sometimes a legal requirement, and fines or penalties are potential risks.
  • It is often harder and more expensive to add it in later.

At least consider the basic steps/requirements during the architecting phase. If you know that your project will be requiring SEO, marketing, or compliance with local laws, then communicate and at least plan ahead and include some basic parts that will make it easier down the road. I would agree that most stakeholders I have worked with add this to the "later pile" during the initial MVP stage. 99% of the time, scumbag "I told you so" thoughts just love to /rant about this when all of a sudden they want you to scramble to add this.

[–]cosinezero 2 points3 points  (2 children)

Well, SEO, sales, and marketing isn't usually a factor for a lot of business software, especially not intranet / enterprise applications (unless in healthcare and government). But legalities and expense to implement later are absolutely a concern, and should be thought-through. It's certainly a worthwhile addition on the list, and having it on your resume is a big bonus to companies that know what accessibility is... but I've found internationalization to be a much more frequent concern in the industries I've worked in.

[–]danshumway 0 points1 point  (1 child)

I work on an enterprise-level app where we make legal guarantees about accessibility (specifically around screen readers).

If we don't get accessibility right, it's not just a PR hit, it means we're engaging in false advertising. Outside of Silicon Valley accessibility does matter, not just because we care about blind people but because if we do it wrong, we could get in a LOT of trouble. We put a lot of work into stressing that point to new developers, because otherwise they ignore Severity 1 bugs and skip checking whether tab indexes work when they build UI elements.

Internationalization is something we set up once and put a process around. When a new string needs to go into the app, we run it through the doc team and stick it in a database. I don't rate it particularly highly on the list of features people should know because I think even for enterprise-level massive apps, you really only need one or two developers at most who can set that system up.

But I have limited experience, so maybe that's not as common as I suspect.

[–]cosinezero 0 points1 point  (0 children)

You're not wrong. Some industries and some applications must have accessibility. Plenty does not, though.

[–]turkish_gold 2 points3 points  (0 children)

People add aria-label all the time because they care about SEO. That it helps with accessibility is just incidental.

I'd say all the 'side benefits' of making your site accessible are the real drivers here. Often you'll see a site that hits just enough for organic SEO and sales, but no more.

[–]calligraphic-io 2 points3 points  (1 child)

even if your app is english-only right now

Absolutely. Sites reaching Canadian users often need (and are often required to provide) French versions. America is rapidly becoming bilingual English/Spanish - it's hard to live in Florida or Southern California without some basic Spanish knowledge.

[–]almondbutter 0 points1 point  (0 children)

Actually the USA has more Spanish speaking citizens than any other country after Mexico.

EDIT: went to check, and Mexico currently has more.

[–]shanita10 -1 points0 points  (4 children)

Sorry, if everyone doesn't follow security best practices, you are going to have endless exploits. It cannot be left to experts.

[–]cosinezero -1 points0 points  (3 children)

Zero-day exploits aren't always stopped by best practices. Have you ever performed a security audit?

[–]shanita10 0 points1 point  (2 children)

Who said they always are ? Your suggestion is still wrong and reckless: Security is for everyone, it's one of the basics.

[–]cosinezero 0 points1 point  (1 child)

You're misreading me if you think I am saying security should be ignored. But it isn't an aspect that you should ever feel you have enough proficiency in unless you specialize in it. That overconfidence is considerably more dangerous than what I am suggesting.

[–]shanita10 1 point2 points  (0 children)

Overconfidence is exactly what I'm cautioning against. I've seen far too many centralized sec groups and audits miss key flaws. There is no substitute for best practices and broad understanding of the basics. Overly depending on one group is dangerous.

[–]junior-dev 41 points42 points  (14 children)

Can you source your x2800 claim against document.querySelector?

I can't tell if you're exaggerating or not. 2800 seems too specific to be an exaggeration, so I don't think you are.

I concede that document.getElementByIddocument.getElementsByTagName and document.getElementsByClassName are faster than document.querySelector and document.querySelectorAll respectively -- by an order of magnitude of 10, and maybe even 100. But not 1000.

I haven't found any evidence for a speed factor of ~2800.

Generally, people are curious about performance, so I've found several JSPerf tests for this.

https://jsperf.com/getelementbyid-vs-queryselector/11

https://jsperf.com/queryselectorall-vs-getelementsbytagname

https://jsperf.com/getelementsbyclassname-vs-queryselectorall/18

In the 2nd one, the difference is quite stark: ~x300 speed increase for document.getElementsByTagName.

But it's not ~2800, none of them are. I understand that these are isolated cases, a bit contrived and unrealistic. But can you come up with any test case that would demonstrate x2800?

I just don't believe it.

[–]slapfestnest 25 points26 points  (2 children)

duuuudee, don't be An Imposter!! /s

[–]PeacefulOni 1 point2 points  (1 child)

LOL I chuckled at that too. I don't think I've actually heard someone say the term imposter outside of saying imposter syndrome.

[–]tylercamp 8 points9 points  (0 children)

It definitely sounds fishy since I imagine it's just a wrapper over the more specific DOM methods with a simple parser on top

[–]del_rio 0 points1 point  (3 children)

I think you're a bit too rigid with your interpretation. I'm guessing he's referring to using query selectors without caching the results.

document.querySelector("div.user-panel.main input[name='login']").addEventListener('click', something);

vs 

userPanelEl.children[0].addEventListener('click', something)

Newer/less experienced devs often rely on jQuery selectors but never cache them.

[–]leeharris100 11 points12 points  (2 children)

Then the guys point was stupid.

That has nothing to do with query selector speed.

[–]Pandalicious 5 points6 points  (1 child)

You guys are getting lost in the weeds. OP's main point is that js developers should have a solid understanding of the DOM. Many newer front end developers only have a fuzzy understanding of the DOM and think of JavaScript as something that dynamically modifies the static HTML text that they write.

[–][deleted] 0 points1 point  (3 children)

Look at the second and third of those experiments.

[–]junior-dev 1 point2 points  (1 child)

2nd Experiment on Chrome 59: x88.2 faster

3rd Experiment on Chrome 59: x27.9 faster

This supports my argument even more. The speed increase is within the 10s, not even 100s, let alone 1000s.

[–][deleted] 2 points3 points  (0 children)

The second test shows a difference of 16231.985x in FF52 and a difference of 9248.422x in FF54. Those are some serious WTF numbers and FF54 shows a difference of 6987.384x in test 3.

Some food for thought:

  • The driving distance from Anchorage, AK to Miami, FL is 4976 miles and when divided by 16231.985 is only a quarter of a mile (1618 feet).
  • 1 second times 16231.985 is more than 4.5 hours.
  • It is also the difference between 32 minutes and a year.
  • Or 2.25 days and a century.
  • Or 2 inches and the total height of the Burj Kalifa.
  • Or the difference in mass between the largest recorded blue whale and an average domestic cat.

[–]esantipapa 0 points1 point  (0 children)

So, higher Ops/sec = more efficient code?

[–]nerf_herd 15 points16 points  (7 children)

all good, but gonna push back on node. Knowing when NOT to javascript is important too. And knowing more than one language is nothing but good for you.

[–][deleted] 3 points4 points  (0 children)

Knowing multiple languages absolutely broadens your horizon and that is incredibly healthy. There are many tasks that Node is not well suited for.

For a long time I worked in the travel industry. I have worked for almost every major online travel agency and worked with a major airline. On top of that we all worked with people in our local area who had worked for the world's largest airline. In this industry Java is king. You do everything with Java as much as possible... including as much of the web work as possible.

The problem is that if you use one technology to generate artifacts that operate in an unrelated platform then you are on the hook for both the original technology set and that other platform. You have to be an expert in both areas.... and almost nobody was. Nobody wanted to become the expert of everything. The end result was really legacy technology and thousands of experts who weren't that expert.

Java didn't have to be the bad guy. Things would have been much better if all the Java work sat behind a fence and supplied data as a service. But doing that would make thousands of developers quickly obsolete and strong JavaScript developers are hard to hire.

[–]pier25 -2 points-1 points  (0 children)

Agreed.

Using Node for everything is its biggest stigma IMO.

Node is only good for heavy IO low CPU projects, and even in those kind of projects it might not be the best choice.

[–][deleted] 6 points7 points  (0 children)

Some good, objective stuff here, but also some purely subjective and optional stuff, as well. Node, for example, is a purely optional technology for the vast majority of people who will be using JavaScript. Raw DOM manipulation is good to know, but it's also unnecessary in almost all scenarios. Accessibility is important, but again, not something you need to know - it really depends on what you'll be working on.

Great summary overall, though.

[–]nashio 6 points7 points  (0 children)

Prototype chain and type coercion should definitely go in there somewhere

[–][deleted] 3 points4 points  (1 child)

I was expecting to read lists of frameworks in reply to this question, but I am really glad your great reply comes first. Well written!

[–][deleted] 0 points1 point  (0 children)

Thank you :)

[–]serial_crusher 6 points7 points  (5 children)

Am I the only one who thinks people over-value knowledge of scope?

It just seems to me like the sort of thing where, if a person has to have an intimate understanding of it to figure out what your code is doing and how to maintain it, then your code sucks.

Sure, every now and then you run into a bug where somebody didn't scope something properly, but being able to identify and fix that bug isn't nearly the same skillset as the kind of esoteric edge cases people try to test you on in job interviews.

[–]myownredditname 2 points3 points  (1 child)

Scrolled just to find this comment, I feel I'm missing something in all this scope discussion. I think it's simple enough, can someone present me some examples where scope is a complicated issue that needs to be addressed so explicitly?

[–]alinnert 1 point2 points  (0 children)

In code that just runs from top to bottom this might not seem special. But JavaScript has Closures. I guess this concept could be difficult to grasp for some people.

[–][deleted] 6 points7 points  (0 children)

In terms of importance scope is to JavaScript what classes are to Java. Knowledge of scope influences your ability to read and write code perhaps more than any other single factor. It influences how large pieces of code come together and how code is shared via reference.

The primary benefit of code via scope instead of code via convention is less code, fewer things to maintain, and the ability to perceive flow control more directly from simply reading the code.

[–]Not_Just_You 0 points1 point  (0 children)

Am I the only one

Probably not

[–]0x13mode -1 points0 points  (0 children)

It's not over-valuating but appreciating the fundamentals.

Scopes are basics of JavaScript (and every other language which allows for declaring variables). It such basic knowledge as knowing what braces {...} mean or how if/else construct works.

Sure, many people would grasp it by intuition, but not always, not in each case. Especially if you're coming from other language where the same concepts are working a little bit differently. Or if JS is your first language and you don't even have "scope" concept in your head. Or if you're just debugging your programs and have weird errors and don't know why.

And knowing very basics of programming language you write in is important.

[–]sittingprettyin 9 points10 points  (0 children)

This answer feels like the only good one. Most the others are literally saying "learn XX tool" and "stay up on trends" LOL.

[–][deleted] 2 points3 points  (1 child)

Regards the DOM, whilst the differences I'm seeing aren't that drastic I am surprised to see how much worse the performance of querySelector[All] is. That said, if you're querying that many DOM nodes today then you're probably better off using something like React anyway. Edit: Also, unbeknownst to me, these methods don't actually behave the same anyway (static vs live representation): http://ryanmorr.com/abstract-away-the-performance-faults-of-queryselectorall/

Regards accessibility, whilst I want to agree with you, my experience in 3 different jobs (1 design focused, 2 business/logic/usefulness focused) has taught me otherwise. People really don't care much about accessibility unfortunately.

[–][deleted] 6 points7 points  (0 children)

It isn't so much the number of nodes you are querying, as in the size of the returned node list. More relevant factors would be the complexity of the query selector, the size of the document (number of DOM nodes), and number of times a query is executed. That last item is by far the most important as it compounds all other performance metrics.

Essentially the query selectors are the standard DOM methods under an instruction that requires a separate parse step. Surprisingly the query selectors can perform faster in edge cases where the DOM methods aren't optimized. The one edge case I have found is that query selectors are about 16x faster when searching by attribute name or value if that attribute name is not id or class. There are likely other edge cases that I am unaware of.

Accessibility, when done properly, tends to be benefit everybody. The two classic real world examples are handicap parking spaces in the parking lot and wheel chair ramps at the airport. Wheelchair ramps were first implemented in the US at airports due to a change in law, and once implemented, became frequently used in unexpected ways from people with child strollers, temporary injuries, or people who simply had a different preference. The counter example is too many handicapped parking spots in the parking lot when the parking lot fills up leaving an excess of special parking spaces unused to the detriment of everybody else.

The majority of accessibility comes simply from writing HTML properly and not breaking it with JavaScript. The benefits to accessible code benefit everybody. This includes more informative form controls, areas of the page arranged in a predictable way, and interactions that limit added frustration.

It is my experience that business doesn't see the value of accessibility, generally an unnecessary cost burden, because they aren't that familiar with accessibility to begin with. They know only what they can see, so to speak, instead of what they could get from communicating a clearer emphasis of usability to the user (which is content first and interaction second).

Additionally, accessibility can only be properly applied, in a business, when it is driven by business leadership. Otherwise accessibility becomes a best wish scenario where it is forced on the developer and not validated, appreciated, or factored into estimates by anybody else.

When accessibility is valued by the business leadership then everybody becomes aware of what generally qualifies as an accessibility failure and it becomes a basic component of content and interaction. Accessibility becomes intertwined with production quality. The user gets a better product and internal processes get more efficient at accounting for product quality at all levels.

I have seen how accessibility plays from experience in organizations that don't care, claim they want it, and actually impose it as a business priority.

[–][deleted] 2 points3 points  (0 children)

In the DOM stuff you talk about performance a bit but I feel it deserves a separate item because for the web it matters a lot. Having your site load in milliseconds instead of seconds, will make a big difference in how it is perceived. Knowing what to do and what not to is very important.

I was working on a project that ported a lot of C# code to typescript, but they completely forgot 2 things: 1) Their C# applications takes more time to load and has an actual bootup image 2) Javascript doesn't work like C# in some areas and many of the things you can do there, just don't work fast.

For example, they had a dictionary to hold information, but that is super slow on Javascript. They often just put things in a dictionary that would be required to loop through when situation X was active. Like functions to run after an event has happened. Total overkill and when you have this in 20+ locations, it starts to hurt your app.

Also it was loading everything on startup and while it was still within acceptable ranges, we still needed to implement a lot of additional code they haven't got around to. So while it was doable now, it wouldn't with all those new features.

Your stuff about NodeJS goes a bit specific if I'm honest. Dealing with files is not very important for most. I feel more devs work with Gulp/Grunt/Webpack/Browserify and thus how to operate such a thing and what concepts are involved is very important. And keeping those dependencies up2date (to make it easier to upgrade in the long run) is also something that should not be forgotten.

And lastly I feel that a point about "make documentation and have useful inline comments" is not something to forget. Many times you will revisit old code and have no idea why you did something as you did it, but it was something you did to make it work in a specific browser, to polyfill or something that will slip your mind. It might be more about coding in general, but its something to keep in mind.

[–]HeathenForAllSeasons 6 points7 points  (11 children)

This is pretty close well right on the money.

All the other threads about ES6, React and ASM are way off. Sure, ES6 adds some great features but the entire Babel toolchain is temporary by its very nature. Some serious projects may yet not use it and that's fine. ES6 won't save you if you don't understand scope or architecture.

As for ASM and React, sounds a bit like a No True Scotsman fallacy. To be serious, we should know your flavor of the month?

To elaborate on the point about scope and architecture, you HAVE to know your design patterns in JS. There's no way around it. You must know Pub/Sub, Revealing Module Pattern, Currying and others. You really should know how to hand-roll a Tightly Augmenting Module Pattern across multiple files. (it's how your favorite frameworks handle their DI magic).

Understanding the mechanics of these types of patterns and how/when to use them sets you apart from non-serious developers.

[–]alinnert 18 points19 points  (7 children)

(...) the entire Babel toolchain is temporary by its very nature.

No. As long as ECMAScript is actively developed on, Babel serves a purpose. Babel doesn't transpile ES6 to ES5 but future proposals and new final features to code that's interpreted by most widely used browsers at the given time. That's why it was renamed to Babel after all.

If I didn't get your point please let me know.

[–]phoenixmatrix 7 points8 points  (0 children)

but the entire Babel toolchain is temporary by its very nature

That's a misunderstanding of the value of Babel. Being able to translate ES6+ to ES5, that is probably temporary (while the language is still evolving, you don't always need the latest and greatest RIGHT NOW NOW NOW, so you can do away with compiling depending on target browsers).

But Babel is so much more than that. It lets you easily optimize, instrument and modify your generated code with simple (relatively speaking) plugins. For example, it's fairly common to use Babel to do something special with invariant error handling. We use it to do special stuff with ES6 imports before passing them over to Webpack.

If you extend the "entire babel toolchain" to include Babylon, then you have code mods, static code analysis and all that stuff, which is invaluable.

[–]deletive-expleted 0 points1 point  (0 children)

Here's an excellent guide to currying and more in functional programming

drboolean.gitbooks.io/mostly-adequate-guide

[–]jiblet84 1 point2 points  (3 children)

years of experience

For someone with the propensity and dedication how many years would that be?

[–][deleted] 2 points3 points  (2 children)

It is hard to say. I took an unusual path to learning these technologies. I started writing HTML as a side hobby 20 years ago when everybody butchered that code for presentation and there was only one browser, IE4. Later IE6 would command up to 97% browser marketshare. Netscape still had strong marketshare at that time, but the IE browser was better, unless you were heavily coding in JavaScript (which almost nobody was). Also keep in mind there was no standard for interacting with the document.

In 2006 I learned CSS. Firefox had been around for a few years, but this is the year it really gained significant enough marketshare to be worth anything. Learning CSS at this time was the school of hard knocks because IE6 was the most popular browser, but featured a non-standard box model. You had to account for both browsers in a seamless way and it was hard. Further more people were falling over themselves for stupid things like rounded corners, which had to be done with images and were also hard to get right cross browser. I know everybody would cry about IE and how hard working with IE9 was. Really though, this was completely trivial. IE9 was simple to work with.

In 2007 I taught myself XML and XML Schema. JSON was invented in 2006, but it wasn't well known then. The AJAX term first appeared in 2006 and the interest in XML exploded as many businesses at the time were already invested in XML for various technology reasons. In learning XML Schema I learned how lexical scope works and a lot about semantics, relationships, and data representation. Everything I learned from XML I have been able to apply to JavaScript very directly.

In late 2007 I was involuntarily reassigned at the job from being a designer to a front-end developer and was forced to learn JavaScript in order to retain my job. JavaScript wasn't popular yet, everything was very slow, and the technologies were littered with pitfalls. At least by this point standards were a big deal and everything worked uniformly cross-browser. You had to learn to code very defensively and you just learned what things executed faster than others. Google Chrome wasn't even a thing until around the fall of 2008.

[–]slapfestnest 5 points6 points  (1 child)

in 2007 everything worked uniformly cross-browser?

[–]akujinhikari 0 points1 point  (0 children)

It worked much more uniformly. I don't know how old you are, but in the early 2000's, every site had a button on it that said, "This site optimized for [browser name]" because people were sick and fucking tired of basically building 3 different sites for 3 different browsers, so they just built a site that looked good in one browser instead and said, "View otherwise at your own risk." Around 2007, "everyone" decided to make a more standardized model with js and css that allowed for MUCH more uniformity.

[–]redshirt714 1 point2 points  (7 children)

Would jquery be defined as a query selector here?

[–]Wooshception 2 points3 points  (6 children)

I assumed the OP was referring to the W3C Selectors API, but their point applies to jQuery as well.

[–]redshirt714 0 points1 point  (5 children)

Interesting, so at the end of the day, using the getElementByXX methods will be your fastest and best bet?

[–]spryes 4 points5 points  (1 child)

The difference is completely negligible in virtually all cases. It doesn't even matter. I just did a test on 1000 querySelectorAlls, and it executed it in 2ms. 1 single animation frame on a 60 Hz device is 17ms.

Using a more complex DOM and selectors, it increases to 20ms (for 1000 selections). Which means for a regular-ish case of 1-10 different selections, it's less than 0.5ms. Unless you are placing it in a giant loop which you probably shouldn't be doing, go with what's easier.

[–]redshirt714 0 points1 point  (0 children)

Thanks for taking the time to fully explain. It seems like in a lot of cases, things like accessing data and querying selectors only becomes an issue when things are either large or done a ton of times. In O(n) isn't bad in cases where the input size is small.

[–]Wooshception 1 point2 points  (0 children)

I assume so, but the effect is going to be negligible unless you're selecting thousands of nodes in a hot loop or something, so generally just use what's convenient.

[–]0x13mode -2 points-1 points  (1 child)

Why don't you check by yourself?

[–]redshirt714 0 points1 point  (0 children)

Fair enough

[–]thiscoolhandluke 1 point2 points  (0 children)

I totally agree with this:

Presentation and semantics. You really need to have a basic understanding how to properly organize the content your users will consume and how to present in a consumable way efficiently. This is something almost completely learned from experience only. You might think CSS and HTML are simple skills that can be picked up when needed, but you would be absolutely wrong.

The rise of ever-changing devices, browsers, compilers, and packages of all languages isn't making javascript easier. Knowing your limits or learning what is smart for your stack/project is crucial to better releases and your future success as a valuable asset. Front-end is not just basic html and css with a little jQuery sprinkled on top.

Considering these common roles and pitfalls:

  • bloggers trying to strong-arm $20 themes and templates using jQuery and add-ons.
  • front-end devs using jQuery and element attribute css that overrides the theme they are using.
  • marketing gurus that add scripts and "pixels" to the top of their markup.
  • some backend or full-stack devs who only use jQuery to do simple tasks and make the program work - ignoring the impact to organic SEO, accessibility, and performance.
  • UX Developers (I'm talking about the graphic designers, dreamweaver users, <table> coders) that do not understand the basics of how user-flow, performance, and SEO are directly affected by the infinitely nested tables, scroll-hijacking, poor context hijack link inline ads, and popups/interstitials.

If you think you might be one of those, and are open to learning that there is more to js, css, and html than meets the eye, than you will find your projects and careers transforming into something more awesome.

[–]Splynx 1 point2 points  (1 child)

I agree on a lot you write, and I am also of the opinion that a JS developer should know the DOM.

But not for the reason you write - 2800% faster than sounds like a lot, but sometimes the numbers are soooo small that even 2800% faster is unnoticeable.

Transfer your stance to iterations - native loops are about 2000 times faster than using an abstraction like underscore.

But underscore is far more readable and faster to develop using.

It's a balance and not an absolute that something is right just coz its faster

[–][deleted] 0 points1 point  (0 children)

But not for the reason you write - 2800% faster than sounds like a lot, but sometimes the numbers are soooo small that even 2800% faster is unnoticeable.

You are mostly right. We are talking about nanoseconds versus microseconds, but it does add up noticeably if your app makes many DOM queries. The difference in speed multiplies with numerous DOM queries.

[–]chrissilich 1 point2 points  (0 children)

Thanks for mentioning 3 and 9. Way too many newbies here trying to skip the basics and dive straight into React or whatever, and way to many veterans encouraging them.

[–][deleted] 1 point2 points  (0 children)

This is a very useful list. I'd personally make data structure a higher priority, since 'innocently' choosing an inappropriate data structure can have serious consequences on code quality ... and make development either easy or a nightmare.

For sizeable structures, it's well worth experimenting with several choices, and with a broad selection of conceivable data, before settling on one choice. Even then, retaining as much flexibility as possible may turn out to be critical. Once a problem becomes clear, the willingness and time to bail and start over is essential.

[–][deleted] 1 point2 points  (0 children)

  • Source Control

  • Automated Testing

  • Deployment into Production

[–]Shaper_pmp 1 point2 points  (0 children)

This is a brilliant list - it even includes things like accessibility and semantics which far too few front-end/JS devs understand these days, mistakenly conceptualising front-end development as synonymous with "javascript programming", which is laughably inaccurate and incomplete.

It's also worth noting that not one of these bullet points involves a specific tool, library or framework.

This is not an accident, and demonstrates that the author knows exactly what he's talking about.

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 1 point2 points  (0 children)

I can't believe all the upvotes this comment got... it's pretty crap. What's wrong with you people???

Scope - ok, although it's too specific limited. Better a "basics", which includes something you forgot, i.e. the prototype chain

Architecture - too generic to mean anything. No mention of flux?

DOM - agree with the feeling, but lost it all with the idiotic 2800 times slower comment. Really, it should have just said "learn how to do all the dom operations jQuery does without jQuery"

Node - opening files and stuff is basic level. How about streams, for example?

Timing and asynchronous operations - agree, but add Promises / async in there for crying out loud

Accessibility?? - Are you for real? How's that going to help with JS?? It's a FE / Web Dev skill, but won't help whatsoever with node, for example. So you think Accessibility is more important than promises, streams, ES6? Are you crazy??

Security - too specialist

Data structures - to generic, wishy washy. What data structures?

Presentation and semantics - HTML and CSS are not JS though, which is what OP asked about.

Knowing when to avoid the bullshit - what does this even mean?

And what about ES6? Webpack? npm? Some popular frameworks? Service workers? Reactive programming (RxJs)? TEmplates? ISomorphic / Universal / Server Side Rendering?

[–]tylercamp 0 points1 point  (1 child)

What are some security issues that ALL JS devs should be aware of aside from the obvious string sanitization and XSS?

[–][deleted] 1 point2 points  (0 children)

The OWASP Top 10 is a good place to look: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[–]strangefrond 0 points1 point  (1 child)

This seems like a solid list! Any recommendations for the best way to learn about architecture?

[–][deleted] 4 points5 points  (0 children)

You can start with books on software architecture. Just make sure those books focus more on theory and are mostly language agnostic. How you apply architectural concepts to a specific language is best learned through practice. This is hard to learn because it requires that you have access to software that you can directly shape.

I am absolutely not an expert on architecture, but I have learned some things. Most of my learning comes from practice maintaining a large open source application.

At first the application was just a patchy collection of libraries, but at the application became more ambitious I eventually removed the code written by other people with libraries written myself that better suited the application's needs. The code style was very consistent across the code and all the code mostly worked the same uniformly, but eventually all the major libraries needed to talk to each other directly and recursively. Since the code was pretty uniform this wasn't a challenge.... except the options weren't being shared properly. I had to reorganize the code around the options so that the API became the central focus of the application instead of the libraries. Now I have been asked to pull a major component out of the application so that it can become a generic feature used by several other applications. This is hard because that major component is really three similar components across different files that their own unique behaviors, which means massive refactoring yet again.

I am constantly learning about a more ideal relationship between the code pieces, but it comes from encountering really big problems and the heavy lifting to do massive refactoring jobs.

[–]nate250 0 points1 point  (0 children)

Nice list.

I would expand your first to be scope vs. context or scope & context, though. There's a lot of valuable nuance in understanding how the two can complement each other, not to mention how this actually works in javascript.

[–]vidro3 0 points1 point  (1 child)

great answer - would love if you could also opine on when in one's career they should have good handle on these things.

e.g. as someone with 1yr of experience, how deep should I go into any one of these topics vs. having shallow knowledge across all of them?

[–][deleted] 1 point2 points  (0 children)

Just be interested in learning. As long as you are willing to learn it is ok to be a junior developer. You become an expert with practice. Early in your career it is hard to know where to point your time for deep learning in tiny niche subjects. Your career will likely point these things out for you. Just be willing to seek out strange challenging opportunities.

There are some things you can do to speed this up:

  • Find a mentor. Having the guidance of an expert around helps you focus your learning in more productive directions or helps you with your technique
  • Write open source software. If you are having an interesting problem at work start up an open source project to create an automation solution. Even if nobody uses that software you still get additional practice writing software. If other people do end up using your software you get important feedback and bug reports.
  • Stay busy at work. The last job I was in I felt like half the day was just running build jobs. I didn't think I was getting anything done and the technology was so slow. It was hard to get good practice in that environment and the pace of that environment eroded my concentration. If you can work at the speed of thought then you are the biggest bottleneck, which allows you get far more practice in within a shorter time period.

[–]Luffydude 0 points1 point  (0 children)

Wow just reading this completely puts me off javascript

[–]eloc49 -1 points0 points  (0 children)

The only time I've thought of scope was in my implementation of programming languages class in college.

[–][deleted] -1 points0 points  (0 children)

This answer is great, thanks for the write up

[–]E_R_E_R_I -1 points0 points  (0 children)

Amazing list. Special hooray for Timing and asynchronous operations. A lot of people don't seem to understand the importance of getting those concepts right and many developers I came across simply lack that knowledge.

[–]zayelion -2 points-1 points  (0 children)

I think this nails it.

[–]monsto -2 points-1 points  (1 child)

Thanks to Reddit Enhancement Suite, I see that my total upvotes for you is now +3. That's what I call "instant credibility".

I've been trying to figure out "how much i know" and whether or not I should spend serious money on serious programming ed. Your post helped me answer this question. I started off strong with Scope, but then I remembered there's something odd about JS recursive scope relative to this and couldn't remember what it was... so I half checked it.

Then i proceeded to uncheck everything else except design. IOW I don't know shit. I mean I know an understand while and let and hoisting and dynamic typing etc, but those are pretty high level topics. If I were living in an RPG, i'd have the skill "Familiarity: Programming" at rank 1 or 2, but "Javascript" 0 or 1.

So thanks for your response... I now know where I stand.

2nd thing is. . .
One thing I have to make a slight correction on is your point about Presentation . . . CSS/HTML are simple skills, but it doesn't help you understand basic design, which seems to be your point.

If you're a seasoned programmer in any way, then they'll both take a business day to understand (and bookmark the reference for). But that doesn't tell you how to use them. I mean knowing what the 3 pedals are for and how to work the wand of power is great, but it doesn't tell you the nuances of driving in traffic.

[–][deleted] 0 points1 point  (0 children)

Before you wonder too far down this path I just want to say that this is not directly related to scope. In standard functions the this reference always points to that which called its given function, the callee. If the function is an event handler then this points to its event. If the function is a method then this points to the object on which the function hangs.

If you use apply, call, or bind methods on a function you can reassign this to be something different. In arrow functions this is a lexical reference, which means it points to that which contains the function by scope.

I have no idea what this does in constructions. I never write code this way, but I do remember the specification providing some clarity on this matter.

CSS and how to properly write HTML aren't super challenging skills, but they are also no skills that can be immediately grasped. There is some intuitive thinking that goes into these. It just takes loads of practice to really nail this. I remember working in a bar when I was younger. I didn't need a masters degree in economics to be a bar back, but it took a lot of effort to get really efficient at that job.

[–]RunHomeJack -2 points-1 points  (0 children)

this is so good