r/javascript • u/[deleted] • Jul 11 '17
help What 10 Things Should a Serious Javascript Developer Know Right Now?
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.
299
Jul 11 '17
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
97
u/cosinezero Jul 11 '17 edited Jul 11 '17
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.
40
u/phpdevster Jul 11 '17 edited Jul 11 '17
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.
29
Jul 11 '17
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.
15
u/pier25 Jul 11 '17
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.
2
9
u/cosinezero Jul 11 '17
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.
2
u/almondbutter Jul 12 '17
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.
6
u/thiscoolhandluke Jul 11 '17
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.
4
u/cosinezero Jul 11 '17
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.
1
u/danshumway Jul 15 '17
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.
1
u/cosinezero Jul 15 '17
You're not wrong. Some industries and some applications must have accessibility. Plenty does not, though.
3
u/turkish_gold Jul 12 '17
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.
2
u/calligraphic-io Jul 11 '17
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.
1
u/almondbutter Jul 12 '17
Actually the USA has more Spanish speaking citizens than any other country after Mexico.
EDIT: went to check, and Mexico currently has more.
0
u/shanita10 Jul 12 '17
Sorry, if everyone doesn't follow security best practices, you are going to have endless exploits. It cannot be left to experts.
0
u/cosinezero Jul 12 '17
Zero-day exploits aren't always stopped by best practices. Have you ever performed a security audit?
1
u/shanita10 Jul 12 '17
Who said they always are ? Your suggestion is still wrong and reckless: Security is for everyone, it's one of the basics.
1
u/cosinezero Jul 12 '17
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.
2
u/shanita10 Jul 12 '17
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.
0
Jul 11 '17
[deleted]
2
Jul 11 '17
I started working as a front-end developer 10 years ago, and it was firmly established by then.
I'd say there was merit in separating the roles since css 2 came out.
4
1
u/cosinezero Jul 11 '17
Ummm... yes, "full stack" existed 20 years ago. I was writing ASP in '97, connecting to ODBC sources. We even had client-side rendering with "Dynamic HTML" and ActiveX controls in IE, though arguably "full stack" does not require you to render in the client.
Backend and frontend were most definitely separated long before 5 years ago.
0
Jul 12 '17
[deleted]
1
u/cosinezero Jul 12 '17
It isn't "wrong", the number of non-english speakers vastly outnumber the blind, even in any given country. And especially using applications that cannot possibly serve the blind, like instagram or even photoshop.
42
u/junior-dev Jul 11 '17
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.getElementById``document.getElementsByTagNameanddocument.getElementsByClassNameare faster thandocument.querySelectoranddocument.querySelectorAllrespectively -- 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.
26
u/slapfestnest Jul 11 '17
duuuudee, don't be An Imposter!! /s
2
u/PeacefulOni Dec 09 '17
LOL I chuckled at that too. I don't think I've actually heard someone say the term imposter outside of saying imposter syndrome.
8
u/tylercamp Jul 11 '17
It definitely sounds fishy since I imagine it's just a wrapper over the more specific DOM methods with a simple parser on top
1
u/del_rio Jul 11 '17
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.
12
u/leeharris100 Jul 11 '17
Then the guys point was stupid.
That has nothing to do with query selector speed.
6
u/Pandalicious Jul 11 '17
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.
1
Jul 11 '17
2
u/junior-dev Jul 11 '17
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.
2
Jul 11 '17 edited Jul 12 '17
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.
1
1
Jul 11 '17
[removed] — view removed comment
1
u/turkish_gold Jul 12 '17
From the charts, it looks like newer browsers are getting better at executing getElementById and others in tight inner-loop testing conditions.
18
u/nerf_herd Jul 11 '17
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.
4
Jul 11 '17
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.
-1
u/pier25 Jul 11 '17
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.
0
Jul 11 '17
[deleted]
7
u/TwiliZant Jul 11 '17
What does the running time of a program got to do with the language it's written in?
1
u/cosinezero Jul 12 '17
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.
1
u/nameless_pattern Jul 12 '17
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?7
Jul 11 '17
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.
6
5
Jul 11 '17
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!
1
8
u/serial_crusher Jul 11 '17
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.
4
u/myownredditname Jul 12 '17
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?
2
u/alinnert Jul 14 '17
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.
6
Jul 11 '17
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.
1
0
u/0x13mode Jul 12 '17 edited Jul 12 '17
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.
10
u/sittingprettyin Jul 11 '17
This answer feels like the only good one. Most the others are literally saying "learn XX tool" and "stay up on trends" LOL.
3
Jul 11 '17 edited Jul 11 '17
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.
6
Jul 11 '17
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.
3
Jul 12 '17
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:
Their C# applications takes more time to load and has an actual bootup image
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.
7
u/HeathenForAllSeasons Jul 11 '17
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.
19
u/alinnert Jul 11 '17
(...) 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.
-16
u/zayelion Jul 11 '17
Maybe you just shouldnt code with Babel, its edge enough to cut you.
3
u/alinnert Jul 11 '17
After writing my comment I noticed a mistake: Babel doesn't transpile anything. It's fueled by plugins. So it can even be used to transpile JSX or TypeScript or whatever the future might bring. There also are plugins for minification. So I wouldn't be surprised if there are some that do performance optimization and what not. So it's extremely versatile.
-10
u/zayelion Jul 11 '17
I've only seen it complicate shit in the field. Its highly misused and needed to fix problems which shouldn't exist.
6
u/alinnert Jul 11 '17
This reminds me of the people who say Webpack is way too complicated. And I'm like: Here's my entry file, there's my output file, these are my loaders. And it works. Hooray!
I totally understand that you can gather bad experiences if you stumble over tutorials you don't get or get errors by reading the wrong part of the documentation or whatever. But that doesn't make the products bad.
I made bad experiences with RxJS, but I know it's my fault since other people can use it.
I use Webpack and Babel in almost every project and they just work. No problems here. And yes, they do help me. Namely organizing my project files, shorten my code and make it slightly more readable.
-3
u/zayelion Jul 11 '17
Im getting at when people use layers of frameworks on top of each other. A leftpad situation. https://github.com/webpack/webpack/issues/1914
After 8GB it should compile right? well why are you compiling, because typescript, well why are you using typescript, because I need type... no learn ES6 proper.
Webpack is a good tool, Im not saying that it isnt.
→ More replies (2)7
u/phoenixmatrix Jul 11 '17
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.
1
u/deletive-expleted Jul 12 '17
Here's an excellent guide to currying and more in functional programming
2
u/jiblet84 Jul 11 '17
years of experience
For someone with the propensity and dedication how many years would that be?
3
Jul 11 '17
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.
5
u/slapfestnest Jul 11 '17
in 2007 everything worked uniformly cross-browser?
1
u/akujinhikari Jul 11 '17
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.
2
u/redshirt714 Jul 11 '17
Would jquery be defined as a query selector here?
3
u/Wooshception Jul 11 '17
I assumed the OP was referring to the W3C Selectors API, but their point applies to jQuery as well.
1
u/redshirt714 Jul 11 '17
Interesting, so at the end of the day, using the getElementByXX methods will be your fastest and best bet?
4
u/spryes Jul 12 '17 edited Jul 12 '17
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.
1
u/redshirt714 Jul 12 '17
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.
2
u/Wooshception Jul 13 '17
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.
-1
2
u/thiscoolhandluke Jul 11 '17
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.
2
u/Splynx Jul 12 '17
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
1
Jul 12 '17
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.
2
u/chrissilich Jul 12 '17
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.
2
Jul 15 '17 edited Jul 15 '17
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.
2
2
u/Shaper_pmp Jul 11 '17
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.
2
u/our_best_friend if (document.all || document.layers) console.log("i remember..") Jul 12 '17
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?
1
u/tylercamp Jul 11 '17 edited Jul 11 '17
What are some security issues that ALL JS devs should be aware of aside from the obvious string sanitization and XSS?
2
Jul 11 '17
The OWASP Top 10 is a good place to look: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
1
u/vidro3 Jul 11 '17
1
1
u/strangefrond Jul 11 '17
This seems like a solid list! Any recommendations for the best way to learn about architecture?
4
Jul 11 '17
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.
1
u/nate250 Jul 11 '17
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
thisactually works in javascript.1
u/vidro3 Jul 11 '17
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?
2
Jul 11 '17
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.
1
0
u/eloc49 Jul 11 '17
The only time I've thought of scope was in my implementation of programming languages class in college.
0
0
u/E_R_E_R_I Jul 12 '17
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.
-1
-1
u/monsto Jul 11 '17 edited Jul 11 '17
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
thisand 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
whileandletand 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.
1
Jul 11 '17
Before you wonder too far down this path I just want to say that
thisis not directly related to scope. In standard functions thethisreference always points to that which called its given function, the callee. If the function is an event handler thenthispoints to its event. If the function is a method thenthispoints to the object on which the function hangs.If you use
apply,call, orbindmethods on a function you can reassignthisto be something different. In arrow functionsthisis a lexical reference, which means it points to that which contains the function by scope.I have no idea what
thisdoes 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.
-1
0
Jul 12 '17
[deleted]
1
u/bart2019 Jul 12 '17 edited Jul 12 '17
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:
global scope
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.
2
Jul 12 '17 edited Jul 12 '17
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.
1
u/our_best_friend if (document.all || document.layers) console.log("i remember..") Jul 12 '17
It's a crap post don't worry too much about it
12
u/Vizer20 Jul 11 '17
There are only two from me:
patience to read/listen about new silver bullet framework/library/tool/whatever
know how to implement left-pad
9
Jul 11 '17
ALERT: left pad made it into the new spec
String.prototype.padStart( maxLength [ , fillString ] )2
0
Jul 11 '17
[deleted]
3
6
u/kaz3work Jul 11 '17
He probably means be able to write a left-pad yourself, rather than relying on a third party.
1
2
3
u/AceBacker Jul 11 '17
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_
1
13
u/deadcell Jul 11 '17
How to control your alcoholism. /s
4
2
u/ThrowingKittens Jul 11 '17
Wow, that title. Are people already starting to ask questions in buzzfeed style headlines?
7
3
u/nameless_pattern Jul 12 '17
top ten ways people are becoming buzzfeed articles, you won't believe number 7!
Personal space
Personal space
Stay out of my personal space
Keep away from my personal space
Get outta dat personal space
Stay away from my personal space
Keep away from dat personal space
Personal space
Personal space
click to continue >
1
Jul 15 '17
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.
1
Jul 17 '17
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.
1
Jul 18 '17
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 !
18
u/ArcanisCz Jul 11 '17 edited Jul 11 '17
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
12
u/cheekysauce Jul 11 '17
ES8 was released today, get with the times 😛
7
u/nameless_pattern Jul 11 '17
I used to get excited for new features in js. now I'm like SLOW DOWN PLEASE.
7
1
u/oculus42 Jul 12 '17
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.
4
u/pier25 Jul 11 '17
ES6/next
or
be informed about current trends
Pick one.
1
u/ArcanisCz Jul 12 '17
I meant not only language trends, but patterns and/or best practices, tools and so.
Web development is aggresive enviroment
2
1
Jul 12 '17
A serious javascript developer will know the things they need to know to do their job because that's what you get paid for.
1
Jul 12 '17
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.
4
u/tencircles Jul 12 '17
learn how to learn. refining your methodology for solving a code problem will help you more than anything else.
question everything. "because it's convention" is the most common excuse I see for bad code.
be clear. write variable names that strike a balance between explicit and terse.
plan. weeks of coding will save you literally hours of planning.
communication. call a REST API from client-side, write a rest API.
security. learn the basics at the very least.
eliminate dependencies where possible. this boils all the way down to point-free programming.
never take short cuts. they will get you fired.
seriously, read the fucking spec
2
u/noodle-cats Jul 12 '17
Progressive Web Apps - this is the future for many sites
HTTP 2, HTTP push
Node.js or similar, being full stack is really helpful
Redux with or without React, just a great way to manage application state on the UI
Functional Programming concepts
How to test your application with Mocha, Chai or similar
DevOps for your application, understanding every part of your project will make you stand out and will make you a better developer
Webpack
Caching headers
Browser APIs like background sync, web payments and generally keeping on top of new things coming out
2
u/dead_chimp Jul 14 '17
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.
1
u/gobi301 Jul 31 '17
some fundamental stuff missing: event-loop functional style (composition etc.) typing (flow, typescript)
-5
u/darrenturn90 Jul 11 '17
Babel / JSX and the "react toolchain" / webpack
At least one unit testing framework (Jest / Mocha etc)
ES2017 / ES6 coding - incl destructing, spread, rest, arrow functions
(nice to have) Functional programming concepts in javascript (Ramda)
(nice to have) Observables
(nice to have) A CSS Modules system (Styled Components etc)
Basic information re: WebAssembly
Backwards Compatability / Polyfills and Minimum Browser Requirements
Web Security and concepts related to where and how to store sensitive data
React Performance optimizations
17
u/FlenserSteel Jul 11 '17
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.
3
3
u/darrenturn90 Jul 11 '17
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.
0
Jul 11 '17
[deleted]
2
Jul 11 '17
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.
2
u/pier25 Jul 11 '17
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.
2
u/darrenturn90 Jul 11 '17
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)
7
u/00mba Jul 11 '17
You should also be able to build a web app on your own, without any framework whatsoever.
Wait, you can do that?
10
u/ArcanisCz Jul 11 '17 edited Jul 11 '17
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.
0
Jul 11 '17
[deleted]
4
u/i_pk_pjers_i Jul 11 '17
This isn't /r/programmingcirclejerk, we're in /r/javascript.
7
2
u/MarcusPope Jul 11 '17
Don't worry... ALL of this content will make it over to PCJ in the next couple of hours...
3
u/pier25 Jul 11 '17
No you can't. Even if you don't use React you will use the Vanilla Framework. /s
2
u/our_best_friend if (document.all || document.layers) console.log("i remember..") Jul 11 '17
React : 2017 = Jquery : 2009
3
u/HomemadeBananas Jul 11 '17
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.
3
u/bits_and_bytes Jul 11 '17
You should know it exists, but it's not in the "top 10 things every JS dev should understand" list.
-1
u/HomemadeBananas Jul 11 '17 edited Jul 11 '17
I mean, unless you're just getting started learning the basics of the language, it's pretty high on the list of things you should have some exposure to these days.
1
u/djslakor Jul 11 '17
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. :-/
0
Jul 11 '17 edited Jul 11 '17
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.
5
u/alinnert Jul 11 '17
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. :)
2
Jul 11 '17
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.
1
u/alinnert Jul 11 '17
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.
1
Jul 11 '17
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.
1
u/alinnert Jul 11 '17
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 :)
2
u/our_best_friend if (document.all || document.layers) console.log("i remember..") Jul 11 '17
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...
1
u/zayelion Jul 11 '17
I think the priorities are wrong in that list and its missing nodejs
2
u/darrenturn90 Jul 11 '17
I didn't list them in order of priority. And indeed it is
1
u/zayelion Jul 11 '17
"Functional programming concepts in javascript" isnt a nice to have, its a fundamental. "React Performance optimizations", is a "nice to have"
1
-15
u/icantthinkofone Jul 11 '17 edited Jul 11 '17
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.
55
1
u/calligraphic-io Jul 11 '17
Stay off reddit. Never come here for advice
Slashdot's much better for getting thoughtful && helpful advice. YMMV.
6
-5
u/johnmadison Showoff Saturday Jul 11 '17 edited Jul 11 '17
Jquery selectors and jquery methods.
Arrow functions. but remember that "this" is bound differently
PHP. Its good to not be limited to one language. Sometimes PHP is easier to "get the job done."
Datatables. A great plugin for the web to make table formatting way easier.
Know the differences between Node and the browser.
Promises, and async in general.
Learn SOME kind of db structure/engine/etc. Lowdb is a cool json based one.
JSON. learn to think in it, as it is the Rosetta stone of the interwebs.
Array.filter(). One of the most useful methods in existence. Works pretty much the same in php as array_filter().
the MVC design pattern. Most frameworks are moving this way, React, Vue, Codeigniter, etc.
6
u/jacobedawson Jul 11 '17
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 :)
3
u/alinnert Jul 11 '17
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.
1
u/pgrizzay Jul 11 '17
PHP
guess I'm not a serious JavaScript developer...
1
u/johnmadison Showoff Saturday Jul 11 '17
In a perfect world, we would only use JS. This is not a perfect world.
3
2
u/pgrizzay Jul 11 '17
I have never done PHP, but have been working as a JS developer for the past 6 years.
Would you label me "not serious?"
1
1
1
1
-1
8
u/ProdigySim Jul 12 '17
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:
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.
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.
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.