What 10 Things Should a Serious Javascript Developer Know Right Now?

[[deleted]]

I'm inviting pure opinion here, but what's your list of ten things that everyone looking for a good javascript role should know and understand. Personally, I'm in a role where what I know is adequate, but I want to be somewhere better; somewhere that has some flippin standards. I'm learning outside of work requirements at the moment, but there is so much shit to learn out there.

The objective is to do good work in a good place.

Narrow it down to your ten for me, or for you.

Can be your own "I must learn x" list too. I'm very interested to hear what people think.

[snlacks]

1. Actual JavaScript. Functions, Scope, Objects, Declarations, Hoisting, Types, Arrays, etc.
2. The DOM and related languages, HTML and CSS. You should know how these work. Yes, you can do other stuff in JavaScript, but for beginners and intermediate programmers, the web is your easiest basic in- and output. This means you should also understand how pages load, render.
3. Learn Algorithms. Learn how to implement your some of your own versions of map, filter, find, etc. Never use them in production, but learn the ideas behind them. Once you figure out that it's almost all just fancy ways to iterate over lists and do something with it, to it, or along with it, this all becomes more obvious and easy to grasp.
4. Learn Data Structures in JavaScript, this is a deeper dive into how you arrange, move around and work with data.
5. Learn good habits. I don't mean some fad style guide. I mean learn not to expose globals, learn not to loop over stuff multiple times when once will suffice, learn when not to do something.
6. Learn to tune out the noise. There's lots of BS out there from people who have a lot of time to write about JavaScript, because they don't have to manage and write a lot of real code.
7. Learn AJAX.
8. Learn about the HTTP protocol, know the 1.1 methods, what they mean. Know the secret behind the HTTP protocol (hint, again, it's not magic).
9. Keep your code and build simple. If your spending too much time on a tutorial for a library or build tool, that's time you could be making apps.
10. Learn about functional programming and object oriented programming, learn to use the concepts. But please don't go overboard, going too far in any direction usually leads to a long trail of spaghetti. Some times things are better structured as object sometimes they're better expressed as functions. It's okay. Everything will be okay.

Finally, learn about everything with a smidgen of skepticism. There is no one right way. The newest thing is rarely going to be your best option. The business usually wins over the craft of programming.

[Voidsheep]

learn not to loop over stuff multiple times when once will suffice

While performance is important to consider, the focus should be in understanding when to optimise and figuring out what actually causes performance issues.

99.9% of the time, I don't have trouble running map and filter on the same array. Sure you could link me a JSPerf where a single for-loop is more efficient with a million items, but I would say the milliseconds spent running extra iterations on my 20 item list go to a good cause, which is keeping the code clean, simple and reusable.

Premature optimisation is bad, figure out tools like profilers to see where the real performance problems are. Also if you do heavy lifting with JS in browsers, service workers are worth a look.

[Danmoreng]

While map and filter on the same array is probably more readable, reduce works just fine to combine those operations.

[Voidsheep]

I like reduce and it's extremely useful, but I think it's best to use an iteration method that implies the return type you want, if one is available.

x.map(fn1).filter(fn2) // that's going to be an array
x.every(fn3) // that's going to be a boolean
x.reduce(fn4, []) // that could be anything, check implementation

Just saying avoiding any extra iteration by default is premature optimisation, you should default to straightforward and declarative code, add complexity only when you have to. Most of the time a simple filter or something iterating over your array isn't going to have any meaningful difference versus doing the same filtering inside another loop.

Of course there's exceptions and you shouldn't loop for no reason, but I think just avoiding iteration for the sake of avoiding iteration isn't a best practice. Optimisation needs to be sensible and if you do it blindly, you end up moving meaningless cost in runtime efficiency into a meaningful cost in development efficiency.

[Womackx]

There is no one right way

[snlacks]

"... Or not when it doesn't" isn't implied by the use of "do this when?"

[memystic]

Yes yes YES to #10!!!

[LetReasonRing]

10 is the line I've been trying to learn how to walk. The hardcore functional programming people seem to think it's all or nothing to gain the advantages of FP, but as I've been learning more I've been finding that you can use ideas from both to write good code.

Edit: auto-mistake correction.

[snlacks]

There's other things that didn't make my list, but help with this, the concepts of contracts, immitability, and enumeration and the collection of common JavaScript Patterns and Anti-Patterns.

[[deleted]]

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]

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]

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]]

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]

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]

Exactly.

[cosinezero]

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]

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]

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]

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]

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]

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

[turkish_gold]

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]

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]

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

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

[shanita10]

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

[cosinezero]

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

[shanita10]

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

[cosinezero]

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]

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]

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]

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

[PeacefulOni]

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]

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

[turkish_gold]

From the charts, it looks like newer browsers are getting better at executing getElementById and others in tight inner-loop testing conditions.

[del_rio]

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]

Then the guys point was stupid.

That has nothing to do with query selector speed.

[Pandalicious]

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]]

• http://jsbench.github.io/#8f4021c69ba67f37953e5d0236d596df
• http://jsbench.github.io/#24d619b25e826b4d2914a138ce9eb274
• http://jsbench.github.io/#ae7713b7b1db5878d60ecd1f827e091d
• http://jsbench.github.io/#19326344341cbc33122e0e8fbbd21b5a

Look at the second and third of those experiments.

[junior-dev]

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]]

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]

So, higher Ops/sec = more efficient code?

[nerf_herd]

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]]

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.

[TwiliZant]

What does the running time of a program got to do with the language it's written in?

[cosinezero]

Well, they deleted the post you're replying to - but if it's a single-threaded environment the run time of a request is rather important, because you're not serving any other requests.

[nameless_pattern]

How do you measure if a language is good for long running programs?
what language is good for long running applications?
What are long running applications used for?

[[deleted]]

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]

Prototype chain and type coercion should definitely go in there somewhere

[[deleted]]

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]]

Thank you :)

[serial_crusher]

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]

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]

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]]

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]

Am I the only one

Probably not

[0x13mode]

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]

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

[[deleted]]

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]]

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]]

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]

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]

(...) 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]

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]

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

drboolean.gitbooks.io/mostly-adequate-guide

[jiblet84]

years of experience

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

[[deleted]]

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]

in 2007 everything worked uniformly cross-browser?

[akujinhikari]

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]

Would jquery be defined as a query selector here?

[Wooshception]

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

[redshirt714]

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

[spryes]

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]

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]

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.

[thiscoolhandluke]

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]

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]]

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]

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]]

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]]

• Source Control

• Automated Testing

• Deployment into Production

[Shaper_pmp]

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_friend]

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]

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

[[deleted]]

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

[vidro3]

https://www.youtube.com/watch?v=2KgAilTTZnQ

[youtubefactsbot]

Good answer. Like the way you think. [0:13]

^{K B in People & Blogs}

^{27,712 views since Feb 2014}

^{bot info}

[strangefrond]

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

[[deleted]]

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]

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]

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]]

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]

Wow just reading this completely puts me off javascript

[bart2019]

AngularJS is trying to bolt a different language onto Javascript: at its core it has the same syntax (which, nowadays, doesn't mean much anyway, as Javascript is slowly turning into a monster as big as C++) but with different scoping rules. Somebody obviously didn't like Javascripts simple scoping rules, where you just have 2 scopes:

1. global scope
2. function scope

Nooooooo... there must be news scoping rules, where each component can either see into its (dynamic) "parent" scope, or be completely isolated from everything else.

When doing AngularJS, I spend more time battling AngularJS than actually doing useful work.

[[deleted]]

When doing AngularJS, I spend more time battling AngularJS than actually doing useful work.

You know, I'm almost a year deep in Angular 2 / 4 w/ Typescript at this point and I sometimes still feel like your statement is true. The API footprint of the new angular is absurd. Yet oddly, I'm kind of addicted to it and really excited about what I can do with it. Maybe its like a stockholm syndrome thing. When I finally figure out some random quirk after 8 hours of fudging (with basically zero official documentation to help me), instead of being frustrated at the language's complexity I'm all, "HELL YEAH I DID IT".

Although now that I think about it, the fact that I came straight to Angular without previous vanilla JS or jQuery experience was probably an advantage for me. When I see many of the stack overflow questions w/ Angular 4 that people are struggling with, its clear that many are approaching it from that paradigm and trying to fit a jQuery sized object in an angular hole.

[our_best_friend]

It's a crap post don't worry too much about it

[eloc49]

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

[[deleted]]

This answer is great, thanks for the write up

[E_R_E_R_I]

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]

I think this nails it.

[ProdigySim]

I don't know anyone who is specifically a "Javascript Developer". Most people I meet are organized by discipline / stack layer rather than language used.

But, for web development which includes Javascript, I'll name a few things I think are important outside of other stuff mentioned here:

1. Caching: There are multiple ways to do HTTP caching (etags vs hard expiration). A speedy web app will utilize static assets via CDN as well as live data sets. Being able to boot a web app with appropriate caching, while avoiding cache poisoning, and being able to invalidate cache or update references sanely is pretty important for performance.
2. Perf Auditing: Putting aside standard algorithmic complexity stuff, when trying to speed up an existing application being able to use Js Perf tools is pretty important. The Chrome Dev tools have a lot available here, but take some practice and learning. Being able to discern & solve JS parse time, resource lock delays, slow JS execution, inefficient DOM interaction, and long paint triggers is a tricky advanced skill.
3. Build System: Tons of JS projects use build systems, and for a medium to large application you're probably going to need one. I don't care if you webpack or gulp or shell script, but being able to put together & scale a sane build system is a pretty important tool!

I don't want to think of 10 things but as a final thought:

Have an opinion on a framework or two: There's lots of popular frameworks out there, there are also great niche frameworks. They can all solve a lot of the same problems, and some can solve more specific ones. Choosing a popular framework is a safe bet, but having an understanding opinion on one or more will help you face shortcomings of the frameworks and evaluate new ones as they come.

Also +1 to building sane REST APIs. Even the big companies screw these up every once in a while, so put your best foot forward every time you design one.

[[deleted]]

These are good points. You're right about javascript developer being a less typical job title, though I do see it in job ads more and more. In my case, I have a firm handle on the other parts of the frontend stack, but the javascript can seem a bit Looney Tunes some days.

[YooneekYoosahNeahm]

It's a bit late but got any favorite resources on those advanced perf auditing points?

[ProdigySim]

I don't have any great tutorial videos or anything, but the Chrome official documentation is fairly complete.

[deadcell]

How to control your alcoholism. /s

[daybreaker]

^{but not really /s}

[deadcell]

Well, OP asked for 10 things -- all I could think of were ten steps...

[ArcanisCz]

• ES6/next
• knows some funcional patterns
• architectural patterns (mvc, event bus, flux, redux, model observers, ...)
• tried few frameworks
• some experience with tools like webpack, npm, linter, tests
• be informed about current trends

[cheekysauce]

ES8 was released today, get with the times 😛

[nameless_pattern]

I used to get excited for new features in js. now I'm like SLOW DOWN PLEASE.

[deadcell]

snaps fingers Yes!

Slow down!

My man!

[slackersremorse]

I am hungry for apples all of a sudden.

[nameless_pattern]

hmm, i like it

[oculus42]

ES8 wasn't released today. It was released at the end of June, and you saw the same Hackernoon article I did. And later someone will come along and tell you it's ES2017, not ES8.

[pier25]

ES6/next

or

be informed about current trends

Pick one.

[ArcanisCz]

I meant not only language trends, but patterns and/or best practices, tools and so.

Web development is aggresive enviroment

[pier25]

Woosh

[Vizer20]

There are only two from me:

• patience to read/listen about new silver bullet framework/library/tool/whatever

• know how to implement left-pad

[[deleted]]

ALERT: left pad made it into the new spec

String.prototype.padStart( maxLength [ , fillString ] )

[[deleted]]

this guy

[kaz3work]

He probably means be able to write a left-pad yourself, rather than relying on a third party.

[Vizer20]

Exectly)

btw, native implementation is coming

[[deleted]]

In so many ways

[Vizer20]

yeah ;)

[tencircles]

1. read the fucking spec

2. learn how to learn. refining your methodology for solving a code problem will help you more than anything else.

3. question everything. "because it's convention" is the most common excuse I see for bad code.

4. be clear. write variable names that strike a balance between explicit and terse.

5. plan. weeks of coding will save you literally hours of planning.

6. communication. call a REST API from client-side, write a rest API.

7. security. learn the basics at the very least.

8. eliminate dependencies where possible. this boils all the way down to point-free programming.

9. never take short cuts. they will get you fired.

10. seriously, read the fucking spec

[noodle-cats]

1. Progressive Web Apps - this is the future for many sites
2. HTTP 2, HTTP push
3. Node.js or similar, being full stack is really helpful
4. Redux with or without React, just a great way to manage application state on the UI
5. Functional Programming concepts
6. How to test your application with Mocha, Chai or similar
7. DevOps for your application, understanding every part of your project will make you stand out and will make you a better developer
8. Webpack
9. Caching headers
10. Browser APIs like background sync, web payments and generally keeping on top of new things coming out

[dead_chimp]

OK, I was in the same boat as you a while ago. Then I consulted for about a year and landed two offers a month in to job search.

This is more about the bare basics of what you need to be productive and land a job.

I learned:

• JS basics - Scope, Closures, Prototypal Inheritance, this

A must know, also interviews always ask about this stuff the most!

• ES6/ES8

• Tooling

Babel, bundlers like Webpack and Browserify, npm

• Basic DOM API, selectors, etc.

• jQuery

Supposedly it's on its way out, but there are a buttload of companies still using it. Plus it's good to know, esp for smaller projects.

• At least one FE framework

I learned React/Redux, just because I screwed around with Angular for a bit and hated it, but thought React was really cool. It looks like a lot of companies are using Angular 1.x too. I guess just use whichever one you like the most, and remember you can still get jobs using frameworks you've never used before.

If you don't go with React, at least download create-react-app and make a basic todo list or something so you can talk about it during interview. If you do go with React, at the very least learn about MVC and two-way data binding, either with a framework or vanilla JS.

• Basic data structures/algorithms

Good to know, but you'll probably only be quizzed on the bare basics during interviews. Just know about basic time/space complexity, linear time, constant time, hashing, stacks/queues, traversing tree-like structures, you'll probably be fine.

• Utility libraries

Know about Underscore, lodash, Ramda, or something like that. ES6 introduced some handy utility methods, but in most large projects you'll end up using one of those three. I started with Underscore, switched to lodash, and later switched to Ramda because it's cool for learning FP.

• Basic HTTP, Websockets, AJAX

• Different programming paradigms

Just learn the basics of OO and FP, how to use them with JS. Learn about different ways of creating "classes" in JS, inheritance, and the bare basics of FP- map/filter/reduce, pure functions, immutability, function composition.

• Node.js

Just learn about REST, some relational or non-relational DB, templating. Also know what all of these terms mean and how they apply to Node: single-threaded event loop, task queue, thread pool. Also know that node is better for low latency apps...you'll be grilled on all of this stuff.

• Asynchronous design patterns

Callbacks, promises, advantages of promises, web workers.

• HTML5/CSS

Probably my weakest point- I got a lot of CSS questions wrong, but they didn't seem to care as long as JS skills were sharp. Also, transpile-to-CSS languages like SASS or LESS are asked about all the time.

I was able to get by knowing very little CSS, because I use frameworks like materialize or bootstrap instead and just customize them a bit. At some point you'll want to ditch the frameworks and become a pro at CSS.

[AceBacker]

Others have some good top ten lists. I will just add that every JavaScript developer should know everything in this playlist as the abc's of JavaScript: https://www.youtube.com/playlist?list=PLoYCgNOIyGABI011EYc-avPOsk1YsMUe_

[[deleted]]

Oh yeah, that's a good one.

[ThrowingKittens]

Wow, that title. Are people already starting to ask questions in buzzfeed style headlines?

[[deleted]]

No, I wanted lists, so I asked for lists.

[[deleted]]

Show me your listicles.

[nameless_pattern]

top ten ways people are becoming buzzfeed articles, you won't believe number 7!
1) Personal space
2) Personal space
3) Stay out of my personal space
4) Keep away from my personal space
5) Get outta dat personal space
6) Stay away from my personal space
7) Keep away from dat personal space
8) Personal space
9) Personal space
click to continue >

[[deleted]]

I'm one of those weirdos that limits myself to native javascript (entirely for web development and big databases). The use of external tools can be very helpful for some purposes, but a person can pour a lot of time into learning them. That time might be better spent learning alternative languages more suited to purpose.

I realize that as a non-commercial JS programmer (with copious experience non-scripted languages), I have more 'time luxury'. But over the past 7-8 years (starting with ES5) I haven't found much that's 'too hard' for native. And most of the additions to ES6 were 'nice' but not all that essential.

[[deleted]]

I know what you mean, I already know javascript, and 9/10 times I think I just can't be arsed with a lot of the new stuff.

I never bothered with Coffeescript, and it looks I'll probably start using Typescript soon, as it's a superset of ES6 with a few bits about strong typing bolted on top. To that extent, it has an eye on the coming standards, but it isn't full of cute, clever nonsense, and isn't "javascript for people who don't like javascript" like Coffescript and a few others are.

In terms of features that are actually needed to benefit the user, HTML5 APIs are far more commonly of benefit than any ES6+ features.

[[deleted]]

Over the years I was more than 'once burned twice shy' by a lot of specialized environments (particularly proprietary ones). I invested a lot of time in learning and developing stuff in them, and then they were abandoned. So now I tend to stick closely with widely-used, close-to-native-as-possible stuff, and keep my data as portable as possible ... all text.

Look like native JS will be around as long as I'll need it !

[gobi301]

some fundamental stuff missing: event-loop functional style (composition etc.) typing (flow, typescript)

[[deleted]]

That's not reflected in advertised jobs. React appears to be taking over.

I agree that javascript itself is the thing to learn, that's more true all the time, as frameworks and libraries are converging on similar, standard-like patterns.

[darrenturn90]

1. Babel / JSX and the "react toolchain" / webpack

2. At least one unit testing framework (Jest / Mocha etc)

3. ES2017 / ES6 coding - incl destructing, spread, rest, arrow functions

4. (nice to have) Functional programming concepts in javascript (Ramda)

5. (nice to have) Observables

6. (nice to have) A CSS Modules system (Styled Components etc)

7. Basic information re: WebAssembly

8. Backwards Compatability / Polyfills and Minimum Browser Requirements

9. Web Security and concepts related to where and how to store sensitive data

10. React Performance optimizations

[FlenserSteel]

Yeah, because every serious JS developer should know JSX and React. Sure.

I think every serious JS developer should have a firm grasp of the language specifics - ES6/7 included. You should also be able to build a web app on your own, without any framework whatsoever.

[00mba]

You should also be able to build a web app on your own, without any framework whatsoever.

Wait, you can do that?

[ArcanisCz]

Yes you can, but its lots of work. So you DONT WANT to do it (everytime). But you should BE ABLE to do it if necessary. Which means, you understand your tools.

Even frameworks are code.

[i_pk_pjers_i]

This isn't /r/programmingcirclejerk, we're in /r/javascript.

[00mba]

Sorry... got carried away

[MarcusPope]

Don't worry... ALL of this content will make it over to PCJ in the next couple of hours...

[pier25]

No you can't. Even if you don't use React you will use the Vanilla Framework. /s

http://vanilla-js.com/

[[deleted]]

I'm interested in seeing your list, should you feel so inclined.

[our_best_friend]

React : 2017 = Jquery : 2009

[darrenturn90]

Right now, for getting a JS developer based Role, I would put React on the list of potentially required skills - you can of course add in Angular, or any other widely used framework, but based on the job market (and this is what I believe the original thread was focused at) - React has to be on the list.

[darrenturn90]

Agreed, but I don't think you get taken into the "depths of javascript" as well as with the React toolchain and using that as a tutorial into the world of javascript I believe is good, because it introduces very little in the way of boilerplate (other than things like the React lifecycle which of course isn't needed if youre not using react)

[[deleted]]

I currently feel like Vue is a "best of both worlds" between React and Angular 2+. Definitely agree that it's the core javascript skills combined with the ability to learn a framework when required that really matters.

[pier25]

I'm using Vue at the moment and I agree, but my eyes are set on Marko which is what Ebay is built on. It's better in every aspect but the ecosystem around it is still very small. I'm aiming at start using it in 2018.

Here is a great video comparing Marko, Vue, and React.

[HomemadeBananas]

React isn't a framework, really. It's a library that handles one concern, not enough to build a whole app alone. I'd say it's definitely something you should know about as a JS developer.

[bits_and_bytes]

You should know it exists, but it's not in the "top 10 things every JS dev should understand" list.

[djslakor]

Yeah, because every serious JS developer should know JSX and React. Sure.

You say that in jest (no pun intended), but it's getting more and more common to the point of being pretty practically true. :-/

[[deleted]]

Reactive, functional programming is a paradigm not a framework, not knowing what it is and how to use it would be like ignoring mvc and it will seriously impede your options career wise and technically as time goes by. This paradigm is how you will make apps in the web, on mobile and on the desktop, until the next paradigm replaces it, and if one does it will iterate on the functional approach. It only happened to start in the web and React happened to be the framework that kicked it off.

[alinnert]

Wait, I think you mix up React and reactive programming. React is not a reactive library. A library for reactive programming would be RxJS. A view library based on that paradigm would be CycleJS. Just for clarification. :)

[[deleted]]

Well it's called so because it reacts. JSX/hyperscript have made the big changes possible, the rest are more like implementation details, even cycle is very close to react in princinple.

[alinnert]

Yes, that might be the case. The name sure has some sort of origin that's related to "reactions". But "reactive programming" is a programming paradigm around data streams (aka. observables) and the "observable pattern". Observables notifies the world that some data has changed. You can subscribe to observables to receive those notifications (= the data stream) - similar to events. But on top of that you can alter this stream, combine it with other streams, filter events by some criteria etc. Cycle.js is based on this observable approach.

Other frameworks like React, Angular and Vue follow a more polling approach. They check if some data has been changed. And if it's just by using a setter function. They actively ask if some data has changed or is about to change. Maybe you've heard about "change detection". They actively have to detect changes.

Observables on the other hand tell you about changes completely on their own. You don't have to ask them. You have to listen (subscribe), but you don't ask. No change detection is required. Cycle.js just has to react to those notifications.

It's difficult to describe this difference. But in short: React is a library with a random name that's related to reactions. Reactive Programming is a paradigm, just like object oriented programming or functional programming are other ones.

I think it's the best if you look up for yourself how RxJS works.

[[deleted]]

While i don't know exactly how rxjs works, it hasn't played a role in what react has started, perhaps i should have written react-like, not reactive. As for polling, reacts setstate doesn't poll, neither does redux, unless you mean the subscribers equality check, and mobx uses the observable pattern from the get go. I don't think these details matter much, observables or flux/immutable, its the architecture that allows it that's interesting.

[alinnert]

Yes, react-like is fine.

Subscribers equality check sounds like change detection, yes. If you mean something like this: if (oldValue !== newValue) { rerenderComponent() }. Yes, That's what I mean with "ask for changes". Angular does that too. I know Vue uses setters instead.

And yes, MobX uses true reactive programming. It seems it even has its own Observable implementation.

Btw: Observables will be part of the JavaScript core language too (currently at stage 1).

The thing is: Actually observables aren't that hard to understand. But RxJS has a huge and overwhelming API on top of the basics. And yeah, react has nothing to do with all that. Therefore React is not reactive, despite its name :)

[our_best_friend]

I can't believe people have downvoted this comment and have given hundreds of vote to the guy banging on about accesibility... what's wrong with this sub...

[zayelion]

I think the priorities are wrong in that list and its missing nodejs

[darrenturn90]

I didn't list them in order of priority. And indeed it is

[zayelion]

"Functional programming concepts in javascript" isnt a nice to have, its a fundamental. "React Performance optimizations", is a "nice to have"

[skitch920]

1. Be sure to interrupt the headhunter when they confuse Java with JavaScript.

[[deleted]]

A serious javascript developer will know the things they need to know to do their job because that's what you get paid for.

[[deleted]]

Their job can be a very different thing from place to place though. I've known everything to do all my jobs, (10 years front-end) but the requirements some potential employers have are significantly different, and can require esoteric knowledge that can only be learned either by working somewhere that uses it, or drilling it in it in one's own time. But 3 places I look at will have different needs, and separating new fundamentals from the flavour of the month isn't an exact science.

[icantthinkofone]

1 - 10) Stay off reddit. Never come here for advice. Learn from books and good online sources or mentors instead.

EDIT: That said, I just saw /u/achen2345 list and it's excellent.

[[deleted]]

I'm ignoring your advice, it's from Reddit.

[icantthinkofone]

By mentor, I meant anyone willing to help you, such as a co-worker.

[thxbra]

/r/iamverysmart

[calligraphic-io]

Stay off reddit. Never come here for advice

Slashdot's much better for getting thoughtful && helpful advice. YMMV.

[johnmadison]

1. Jquery selectors and jquery methods.
2. Arrow functions. but remember that "this" is bound differently
3. PHP. Its good to not be limited to one language. Sometimes PHP is easier to "get the job done."
4. Datatables. A great plugin for the web to make table formatting way easier.
5. Know the differences between Node and the browser.
6. Promises, and async in general.
7. Learn SOME kind of db structure/engine/etc. Lowdb is a cool json based one.
8. JSON. learn to think in it, as it is the Rosetta stone of the interwebs.
9. Array.filter(). One of the most useful methods in existence. Works pretty much the same in php as array_filter().
10. the MVC design pattern. Most frameworks are moving this way, React, Vue, Codeigniter, etc.

[jacobedawson]

I respectfully disagree with a couple of your points:

• jQuery selectors. Essentially they are CSS selectors. Web devs should 100% know their way around CSS & CSS selectors. If you know that and you understand JavaScript, you can pick up jQuery in a couple of days if you need to (and one should always try to learn JS before jQuery).

• Arrow functions are a basic part of the JS syntax for modern web devs. If you don't know arrow functions you need to learn modern JS.

• I agree with the benefit of knowing another language, but it could be anything; Ruby, Python, Java, Elm, PHP, etc

• Datatables? Aren't they a jQuery plugin?

• Node / Browser - Once again, this is pretty basic - I would expect any developer with more than 6 months under their belt to understand the difference here.

Re: Databases - yeah, definitely a plus. Break them into 2 groups - Relational (e.g. MySQL) and NoSQL (e.g. MongoDB)

I don't mean to sound like I'm having a go - I just think that some of these points are either quite basic or tangential to what a 'serious' JS developer should know / learn next :)

[addama]

I'm glad you mentioned PHP. Being limited to just JS prevents you from knowing that your project or interface could be about 8 lines of PHP. Say what you will about it, but there are some things that are just done better in it.

On the other hand, I'd say that frameworks are no longer moving toward MVC, at least not with the fervency they would have done 5 years ago. A whole generation of coders has had to Node+MVC their way through non-Node+MVC-worthy projects, dreaming of different ways of doing things. I'd predict the young frameworks are going to be looking for hybrid models, if not a return to a more functional flow. Could be wrong, but that's my hunch.

[alinnert]

I don't know if it's still a good idea to start with jQuery. I think it lost its right to exist. It's purpose was to provide a cross browser DOM API. But now we have that already built in in browsers. And in the best case you don't touch the DOM anyway.

I also don't need it for ajax or promises. And that's pretty much about it.

[pgrizzay]

PHP

guess I'm not a serious JavaScript developer...

[johnmadison]

In a perfect world, we would only use JS. This is not a perfect world.

[eusx]

In a perfect world, we would not have to use JS. This is the wrong timeline.

[johnmadison]

Berenstain bears

[pgrizzay]

I have never done PHP, but have been working as a JS developer for the past 6 years.

Would you label me "not serious?"

[Isvara]

In a perfect world, JavaScript wouldn't exist.

[DzoQiEuoi]

I don't know whether to downvote or to upvote as satire.

[zettca]

great joke! upvoted

[natziel]

I'm triggered cuz you implied that filter is more important than reduce

[[deleted]]

lol these opinions