Why It’s a Good Idea to Be a JavaScript Developer, and What it Takes to Be One
clientcide.com
clientcide.com
Because that would suck. I don't like the waste bin. It smells funny.
I think this makes me more of a pony with an ice cream cone duct taped to its forehead.
In seriousness, some tips that I find help:
* Learn & use Bootstrap. A manager actually told me to use Bootstrap instead of a custom webapp design created by his in-house designer once. The defaults are fine for a surprisingly wide range of projects.
* Learn some design basics, like the rule of thirds, typography and picking palettes from colour wheels.
* Don't be afraid to copy other people's designs. Conversely, if you're copying whatever is in fashion right now (I'm looking at you, long, scrolling pages split into sections of type/images...), then you might be better off just using Bootstrap.
Finally...
* Hire a designer.
Seriously. Design is easy: 1) Typesetting. Just put the text where it should go. 2) Colored backgrounds! Everyone likes color. 3) Responsive. Make it look good on mobile as well as many resolutions (max-width the main content area, use a framework).
* The money to pay a junior developer who won't be productive until they're trained (probably a few months).
* The money to pay a more experienced developer to train someone rather than working on your app.
* The wiggle room on your deadlines to be able to slow things down for training.
* The stomach to live with the fact that an experienced developer may become available two weeks after you've hired a junior dev.
A bootstrapped startup is almost never going to have the capital to make this feasible, but a big company might.
Java developers are easy enough to find, so it rarely makes sense to spend months training someone. Ruby developers are a bit harder, and the training is almost mandatory if you're looking for Haskell developers.
That said, I would like to see big companies take a leadership role in this stuff. My company is always complaining about how hard it is to find qualified people. We've got the time and resources to run a bootcamp-style training course. We could bring in 30 people and train them for a few weeks and offer junior positions to the people who performed best. The people who were passed over still have valuable skills they can use to be hired by other companies.
But I feel exactly like you.
/the author
Companies encourage people to become a front-end dev because they don't want to do it.
basically: you use a language that is the envy of noone, to work with things like web browsers, the DOM and CSS. Anyone would want good money to do that...
Manual server management: Not even once.
Hopefully this internet thing will just fade away soon and we can all go back to real development.
I disagree that catering to that fills one's day with misery. In fact I think it's fun and I wouldn't enjoy working on a library, thick client or compiler quite as much. That's ok, development is big enough for us both to find something we like doing, without needing to denigrate what we don't like.
Also, even for a front-end person, those don't have to be mutually exclusive options.
Case in point: this week I am working on both heterogeneous end user-facing UI stuff AND [relatively] controlled-environment node-based webdev tooling for our FE team. I enjoy both types of challenges and think its healthy not to get too pigeon-holed into one such context or the other.
/$.02
I've been dealing with browser quirks since the mid 90's... there's never been a better time to be a web developer. That said the browser tech alone has exploded with CORS, Web Sockets and WebRTC ... that's not counting the ground gained with node.js, mongodb and others...
The landscape is rapidly changing, so who knows what the near, and the next couple of years will bring to the table. Golang, docker.io and coreos are other things to keep an eye on.
Stay away from any job posting that asks for ninjas, rock stars or bad asses.
To get to the level the author is talking about is quite daunting. I feel that JS is sort of a second class citizen to most back-end developers. Web projects which are touched by an HTML / CSS developer, a designer and a back-end developer are common (not always a team, maybe they are all contracted to do their bits as needed and don't work closely together.) Often the heavy lifting with the JS goes to the back-end dev because the HTML / CSS dev isn't really a programmer beyond Googling for Jquery snippets. The problem is, the back-end developer usually isn't a JS wizard either. A lot of developers I come across make a mess of copy and paste in the JS. And I don't spend enough time in JS for it to feel natural to me. If I could add one superpower to make my life way easier, it would be the things the author is talking about.
I see a lot of threads with people asking what to learn. If you are going to be a web developer, then JS is always a damn good answer (or if you already know JS, go back and level up.) I really love to spend time on the server side. I want to put my time into Linux, spend a lot of time in Go and learning other languages. But that doesn't make a lot of sense for a freelance web developer.
ETA: Actually, high in demand is probably the wrong way to put it. You don't have to be in high demand. Small markets can be as lucrative or better than much larger markets. And then there the fact that there is a lot more to being a successful web developer than being a code-monkey. But the things the author described is certainly a super power in web development.
I'm not what one might consider a back-end developer (or a web developer at all, for that matter), but the overgrowth of web tools in the web 2.0 aftermath has made web tools somewhat hard to ignore as of late, so I had to sporadically develop what can be considered back-end code. Even front-end, which I have done grudgingly.
To me, JS -- and in fact the whole web environment -- is a second-class citizen. I come from a vastly different background (embedded and systems programming), and the fact that people manage to write anything useful with today's web technologies is astounding. I honestly admire the craftiness of web developers, although I have very few good words to say about pretty much anything else that comes out of their hands.
I cannot help seeing them as second-class citizens because:
1. They are simply tools made for different purpose. HTML is there to annotate the structure of some content, CSS is to annotate its appearance, JS is for some limited interaction. What people managed to build with these limited tools, compared to the crap we were writing the last time when I seriously touched web programming (let's just say that PHP wasn't yet popular when that happened), is astounding, but I cannot help wondering if the web wouldn't be a lot better if people had actually stopped to think about better tools for a moment. Every time I see yet another awesome demonstration of a JS game, my initial enthusiasm is chased away by the realization that thirty years later, people are still enthusiastic about stuff you could make on an Amiga, were it not for the gazillion cycles wasted between the hundreds of abstraction layers involved in painting a pixel and for the latency involved with pretty much every I/O operation.
2. It's shaggy. Dear God, it's shaggy, full of barely-documented hacks. If you want your webpage to have a drop-down menu, there's a thousand something.js packages that help you do that, but all of them have their own quirks, their own issues with styling, their own little manner of use and so on. It reminds me of writing X11 applications using nothing but Xlib, when everyone was using their own menu widget that worked in a slightly different manner from every other application. The Unix desktop was not too fun to use back then, and the fact that people not only consider that kind of behaviour to be OK now, but actually want it, is beyond comprehension to me. It doesn't help that a large portion of the community seems to struggle with even the most basic programming concepts, which makes reading source code or documentation a very unpleasant experience.
3. The tooling is terrible (but this one is becomming less and less of a grievance).
It would be better to hire 3 different amazing people on their field (front-end dev, back-end dev and designer) and most of the times you will get a better result. two heads thinks better than one.
One thing that I'm not seeing here is the long view. Sure, learn JavaScript, but recognize that due to its sub-standard nature it will be a transitional technology until a better run-time for web apps than web browsers comes along. JavaScript's popularity now is akin to the massive success of Visual Basic were a large number of adequately skilled programmers could crank out the needed business applications. JavasScript allows for much the same, and there's nothing wrong with that, it's just not something that will last into the future. So instead of learning JavaScript, learn how to program, how to develop software, and how to keep your fire alive so you want to learn the new stuff that will eventually replace what you're using now.
I sure as heck don't want to go back to Visual Basic, and I look forward to the day we don't have the HTML/CSS/JavaScript morass to build our software on.
Not that JavaScript isn't useful - it is, and it does allow you to get things done. But imagine the uncountable number of man years that have been wasted coping with JavaScript when it's clearly obvious that something better would have made our jobs a lot easier.
I think I'm a solid frontend developer, but I'm a few years professional experience away from the level he describes here. I know my way around HTML, CSS and the various browser quirks - though I'm still learning the idiosyncrasies he describes here. I've written a ~10000-line app in Angular.js, but my Javascript code is still sloppy, and is nowhere close to my knowledge of Ruby. I'm gradually picking up the basics of design and UI as I go, but that's a whole other mountain which I could climb for years.
"That guy I offered that car to (not really) took a job at a startup and he’s the guy. He’s THE front end developer for their product which doesn’t exist yet. He gets to point to that thing, a year or two from now when it’s worth a bazillion dollars (I do wish him luck, after all) and say, “I did that.” There are people out there, right now, who get to point at Twitter, Facebook, Gmail and Google Maps, at the Iphone’s UI, at Github, at the YouTube player – stuff used by millions upon millions of people – and say, “I did that.”"
Thing is, few products are built by one superhero. I'm wondering if, rather than transform yourself into a magical-unicorn designer/hacker - it might be better to get solid at development, solid at design, but aim to only get good enough that you can manage people who are better at you in those areas?
> I'm wondering if, rather than transform yourself into a
> magical-unicorn designer/hacker - it might be better to
> get solid at development, solid at design, but aim to
> only get good enough that you can manage people who are
> better at you in those areas?
Note that "we're still figuring out what this product is" stage startups really hope to find these "superhero" types, as they can litterally breathe life into a product by themselves. Larger companies can't depend on hiring people with all skill sets, as they're too rare.
I'd say rather than chase after things for their perceived value, do what you love. A lot of that esoteric knowledge is just the byproduct of doing what you like to do for years on end. If you like what you're doing now, keep doing it, get better, learn more.
As for few products being built around one superhero, that's absolutely true. But it's often the case that when products get created, there's only one UI developer at the start. In the article, the guy I'm referring to was one of the first developers at simple.com - how cool is that?
A lot of these things someone will figure out when they get stuck with a 5 second google search.
A lot of these things won't matter as legacy browsers fall out of scope.
A lot of these things won't matter if someone's utilizing some form of frame-work to help them glue code together.
Maybe this level of detail would be important if you're building custom JavaScript frameworks, or whatnot, but for 99% of the UI code out there....
...meh, I don't feel not immediately knowing a lot of these things would prevent anyone from developing a solid UI application.
(I'm going to write later how to get the most out of a team of typical web devs who aren't gurus or rockstars or ninjas, but yet manage to make compelling applications that make customers happy.)
EDIT: I'm only commenting on the first couple of items in the story, because I'm not even going to address the separation of front/back, and manageable team sizes.
As an engineer whose recent focus has been front-end, I wish this was true.
The iOS7 rollout is what's been on my mind lately. That version of Mobile Safari had a number of new quirks/bugs which caused some significant usability issues on the site of a major automaker that I've been working on most of this year.
After poking at one of the biggest problems for two weeks, we eventually came to the conclusion that there was no fix available, and the choices were (a) live with the problem (b) entirely re-engineer some components just to accommodate iOS7, or (c) gracefully degrade for the newest version of what is likely the most significant mobile browser.
I've enjoyed watching and participating in a lot of the progress and excitement on the front-end over the last 10 years. But this development really depresses my enthusiasm. It was kindof understood years ago that, sure, for now we might have to make sure we knew the quirky minutia of each of the major 3-4 rendering engines, but the promise was the quirks would fade, browsers would converge on standards, we'd paper over whatever Microsoft couldn't/wouldn't manage to fix themselves, and eventually get on with the actual engineering.
Watching another major vendor introduce new quirky minutia in 2013 makes me wonder if front-end engineering will always mean that you'll have to fill up your head and your time with ephemeral, non-generalizable knowledge that will never really help you grow into a better problem solver.
I've been pushing for node.js and MongoDB for over three years now, and finally seeing them gain a lot of traction. Right now I'm pulling for docker.io and CoreOS to gain the same kinds of traction (and learning go).
I don't think what the author is asking for is impossible.. but I would be more interested in either stronger core development skills or stronger design skills, you won't likely get both. I started off doing more design and that was over a decade and a half ago. Today, I reach for balsamiq if I want to mock something up, and tend to go very basic and neutral for UI to start with. You can add more later, especially if you have an artist at your disposal.. Beyond this, clean design is finally gaining ground anyhow, though I am getting tired of very bootstrap like sites.
I've seen the good and bad, to very bad.. you deal with the issues you have come across personally, and likely won't know how to fix a specific issue you haven't come across... today, I'd say a JavaScript developer should know at least one test framework, and one module framework. Should at least understand closures, and some of the ES5 extensions (especially to arrays), understand how currying techniques work... and experience with node.js and mongodb is really important.
Knowing another server-side framework is important, but dogma from a various server-side frameworks tend to cloud how development works in the JS mindset... There's a lot of changes happening in the past 2-3 years (a lot driven by node.js), and more to come... just being open minded and trying to understand some functional concepts is important a well.
Personally, I'm tired of some of the recruiter emails that I get.. generally a few a day, and mostly either distant locations I have little interest in and/or for salaries I wouldn't consider.
Though I do agree the subject of this article would be more suitable if it were Front End Web Developer as opposed to JS Developer.
They tested me on front end shit. And thinks that javascript is only front end.
While there are many down falls with node.js it still pay the bill, interest tech, and I wish people would realized that just cause you program js you doesn't imply that you want to do front end.
I hate front end. It's just not for me.
In general node.js combined with npm bring a lot less friction to development than other languages. Using node to create shim services for a front end communicating through to different backands is brain dead simple as well. In fact there's been a few times that creating a service in node.js to communicate with an ill-defined backend was so much easier in node compared to the static language the main application was working in it was a no brainer.
Utility scripts in JS can also be pretty useful.. any kind of stream manipulations work well in node.js too.
This doesn't even mention that JSON (current data transmission structure du jour) is native to the environment. And storage systems like MongoDB (couch, rethinkdb and others) is really transparent to node.
I couldn't even begin to all list the advantages, but here are a few.. the event loop system, libuv library bindings internal to node.js, language singularity, the npm system and over 40k modules...
You have this event loop where if you screw anything up your whole app immediately comes to a grinding halt.
You don't have any mature standard library. Instead you have 8 gazillion libraries in different versions...
Just overboarding complexety, unfindable bugs, dependency hell. And then you do all of it in JavaScript.
There's no need for a mature standard library. Things move faster nowadays and you can't wait for things to get standardized. Node embraces the open-source spirit and trusts that the best libraries will rise to the top eventually.
And then you do all of it in JavaScript.
JavaScript is actually a top notch language. Cream of the crop. Lambdas, higher-order functions, apply/call, and OO. What more could you ask for from a dynamic language?
Both require their own specializations. I wouldn't say they're mutually exclusive, just that while the constant is Javascript the language, the environments are widely different.
Cyberduck + Textmate is a joy.
However, editing live is bloody idiotic. Use git locally and live-deploy based on tags/branches.
Though I still recommend using something like git, because at some point you will do something stupid and you probably won't find that backup :(
Those skills are important because the front end field is still in flux and while lists are a great starting point it seems unlikely that there is a good exhaustive list. (I'd love to see one if there was.)
I think what the recruiter meant when he said "those people don't exist" was really "those people aren't available to you." In a highly competitive job market, these "unicorns" can get any job they want, or even stay independent, and both make more money and have a higher quality of life than most startups could provide. Recruiters know this as they are the ones trying to locate these people, but hiring managers might not have this perspective.
Article content: Why it's good to be a JavaScript developer who is also a back-end developer who is also a systems administrator who is also a designer who is also a ...
This guy wants to hire people with 15-20+ years of experience, and I'm willing to bet he's not willing to pay for it.
where X - any mainstream technology, Y - market level rate
And for a experienced JS programmer, it will be very easy to code in CoffeeScript.