13 ms·

A Baseline for Front-End Developers

311 points by thisisblurry 15y ago

mkmcdonald 15y ago
> This might go without saying, but simply knowing a JavaScript library isn’t sufficient any more. I’m not saying you need to know how to implement all the features of a library in plain JavaScript, but you should know when a library is actually required, and be capable of working with plain old JavaScript when it’s not. I'd like to think this is because ideas of proper scripting have slowly propagated from goldmines like comp.lang.javascript and into the mainstream. People like David Mark have pulled back the jQuery curtain and shown developers that education really is the solution, not mindless abdication of responsibility. > It wasn’t so long ago that it was entirely typical for servers to respond to XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the front-end dev community saw the light and started demanding pure data from the server instead. Client-side templating was and still is a sham. It requires either an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure (IE is very strict with `innerHTML` in particular). I've dubbed `innerHTML` the "eval" of the DOM as it exposes an external parsing engine to do the developer's dirty work. Server-side processing is still the best option, particularly because of powerful parsers and the ability to hide domain logic. OWASP has an article[0] that covers XSS and DOM scripting that's fairly interesting. [0]: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Che...
- chc 15y ago
  I'm confused by the contrast you're drawing. Aren't you going to be using innerHTML if the server sends back HTML? That's how I always remember seeing it done.
  - bmelton 15y ago
    I'm not terribly plugged in to the front-end developer community, so don't take this as authoritative, but my preferred (and more reliable) method of handling server input is generally to append new elements to existing, 'container' elements already present on the DOM. In context, I might have a 'tweets' div on the page that is empty on page load, but which will be populated by appending new div or li elements to.
    - chc 15y ago
      But how are you doing that if the server sends back HTML? Like, say you ask for a tweet, and the server sends back the following: <div class="tweet"><div class="header"><div class="username">rihanna</div><div class="retweet"><img src="retweet.jpg" alt="retweet"></div><div class="tweet-body">Check out my new tattoo of a woman getting a recursive tattoo!</div></div> You can't send that to document.createElement. Your only options AFAIK are innerHTML and writing your own DOM parser to build up a tree and use the DOM API to create the elements one by one (which will be OMGslow). And of course appending a new element doesn't make a lot of sense if your changes are transformative rather than additive (e.g. collaborative editing).
    - deleted 15y ago
      [deleted]
    - deleted 15y ago
      [deleted]
    - deleted 15y ago
      [deleted]
  - MatthewPhillips 15y ago
    Yes, there are only 3 ways to render HTML in a browser; through a page load, innerHTML, or DOM apis (mostly createElement and appendChild).
    - nivertech 14y ago
      and iframe, though it's also page load
- Raynos 15y ago
  Maybe you should take your opinions about not using client-side code back to 1998
- ebiester 15y ago
  So are you suggesting we give up entirely on single page apps and go back to a full refresh of the page whenever the search terms change on a page? I am not quite clear of what you are suggesting here. How do you build a system like gmail with it's great response times without innerHTML at some step?
- nene 15y ago
  So what's the big difference of doing it on server side v/s client side? You can get it wrong on both sides. Especially what's wrong with a templating system? A templating system on server side can help avoid casual escaping bugs by doing automatic escaping of everything by default. Exactly the same thing can be done on client side. OK, I think I found the quote that is troubling you: > It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. So basically we are talking about the case where users machine has been compromised? In such a case I don't really see how you can be sure of anything - that user is screwed. At the same time the article suggests multiple ways of encoding the data on client side... I'm a bit puzzled. Maybe what they really meant was that you shouldn't hope at server side that the client side correctly performed the encoding, like hoping the client will escape you database query arguments... but that's just basic everyday knowledge.
- ricardobeat 15y ago
  comp.lang.javascript was a very inhospitable place. David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned). > an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure They are as stable as the code using them, just like their server-side counterparts. The parser isn't any less stable when called from innerHTML. Would you mind expanding on security?
  - mkmcdonald 15y ago
    > comp.lang.javascript was a very inhospitable place. To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript. > David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned). It seems that you've turned a blind eye. His code's been available in a multitude of ways (I've used it myself as a learning tool). There's a GitHub repository[0] as well. > They are as stable as the code using them, just like their server-side counterparts. The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE). Fragment builders are hampered because they're either too dynamic for their own good or need to keep a laundry list of valid attributes. > Would you mind expanding on security? Apart from the OWASP article I linked earlier, it's more of a statement towards older environments. Browsers today escape input nicely, but that's meaningless for Joe Smith, government bureaucrat on IE 6. I prefer direct node creation patterns via `createElement` et al. for this reason (especially text nodes). [0]: https://github.com/cinsoft/My-Library https://github.com/cinsoft/My-Library
    - subsection1h 15y ago
      To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript. I agree with you about the usefulness of comp.lang.javascript, but I disagree regarding David Mark's contribution to education. I had to killfile him years ago, mostly due to his use of sockpuppets. Here are just two of his Reddit sockpuppets that I made note of years ago when I still visited Proggit: http://www.reddit.com/user/DeathFromAbove2 http://www.reddit.com/user/DeathFromAbove2 http://www.reddit.com/user/joesixpack3 http://www.reddit.com/user/joesixpack3
robin_reala 15y ago
I’d be interested to hear from Windows developers. I do most of the stuff on this list already, but I’m on a Mac and have been for a few years. Are the ecosystems noticeably different?
- billpatrianakos 15y ago
  I'm not a Windows developer but I've tried my hand and work with a lot of people who are getting into the things described in the article using Windows. Things really are harder and it's something I've been trying to explain to people I'm mentoring and they're finding it out the hard way. The thing about that statement is that a lot of times people will start a holy war over it. No one is saying Windows sucks here. It may or may not suck but that's beside the point. The reality of the situation today is that the majority of the open source community is creating things that will eventually be running on a Linux server. IIS is just not used all that much at all outside the corporate space and even they are moving toward Red Hat these days. But any time I explain to someone that they'd have a much easier time on a Mac or Linux distro they start an argument and give me that "you're an elitist" look. I'll tell them to use Git but they need a special program for it. I show them SSH and they need another app for that. Same for Ruby, most local dev servers, etc. and then every mundane command for me turns into twice the work for them because they have to do what I'm doing plus whatever extra steps plus configuration on their machines. It's really frustrating for them and they give up. A lot of times a person who has learned some basic HTML and CSS who wants to level up and start doing some version control and set up a remote server ends up giving up on the whole thing. So the whole ecosystem really is different as everything is built with a nix environment in mind. I'd been working on a Mac for a long time and needed a laptop. I got a cheap Windows laptop and thought I'd dual boot with Xubuntu so that I could deal with certain Windows file types and have an easy way to test sites in IE. Well, I ended up booting to Windows less than 10 times in 6 months and eventually got rid of it altogether because there was nothing Windows did that my Mac or Xubuntu couldn't. I even tried to write so,e desktop software and do some web dev and found that Windows is awesome for desktop apps... If you're only developing for Windows... and Windows is great for web development... if you plan to use an IIS production environment and/or you're going to program in ASP.net or C# exclusively. But again, this isn't a Windows bashing party here. It's just the reality of working with open source and web dev in 2012. There are certainly things that make nix systems difficult to work with depending on the context but as it stands we're living in a time where *nix is the default platform for web development.
blauwbilgorgel 15y ago
My baseline tools and resources for front-end development: - Page speed https://developers.google.com/pagespeed/ https://developers.google.com/pagespeed/ http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/yslow/ http://developer.yahoo.com/yslow/ - Valid HTML http://validator.w3.org/ http://validator.w3.org/ http://html5.validator.nu/ http://html5.validator.nu/ - Usability http://www.userfocus.co.uk/resources/guidelines.html http://www.userfocus.co.uk/resources/guidelines.html http://www.useit.com/ http://www.useit.com/ - Accessibility http://www.w3.org/TR/WCAG10/ http://www.w3.org/TR/WCAG10/ - On-page SEO http://www.seomoz.org/ http://www.seomoz.org/ http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//webmasters/docs/search-engine-optimization-starter-guide.pdf http://static.googleusercontent.com/external_content/untrust... - Design for the web http://www.usabilitynet.org/tools/webdesign.htm http://www.usabilitynet.org/tools/webdesign.htm - Cross-browser compatibility http://browsershots.org/ http://browsershots.org/ - Mobile ready http://www.w3.org/TR/mobileOK-basic10-tests/ http://www.w3.org/TR/mobileOK-basic10-tests/ http://www.marketcircle.com/iphoney/ http://www.marketcircle.com/iphoney/ Modify Headers add-on - Progressive enhancement http://www.alistapart.com/articles/understandingprogressiveenhancement/ http://www.alistapart.com/articles/understandingprogressivee... - Metadata http://schema.org/ http://schema.org/ - Conversion Optimization http://www.conversion-rate-experts.com/ http://www.conversion-rate-experts.com/ http://www.google.com/websiteoptimizer http://www.google.com/websiteoptimizer
recursive 15y ago
> Something has changed in the last couple of years I don't think there has been nearly as much change as Rebecca suspects. It sounds like her skills have improved significantly, and that she's projecting this onto developers at large, but I doubt there has been much of a change in general.
- rmurphey3 15y ago
  I hope I gave due credit to the possibility that part of what's changed is me when I said in the next sentence: "Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development." I do think the profession of "front-end development" has grown up a whole lot in the last couple of years. There have been front-end pros since long before I was even in the business, but I think the profession as a whole is being taken more seriously, and a set of baseline expectations for people in the profession is solidifying.
- cygx 15y ago
  No, Rebecca is right - the game changed for front-end developers when client-side scripting became ubiquitous, which is a somewhat recent development: For example, while XMLHttpRequest was introduced in 1999 (IE 5), it took years to gain traction (XHR support was added to Opera with version 8 in 2005), and incidentally, JavaScript frameworks (Prototype 2005, jQuery 2006) and distributed version control (Mercurial, Git 2005) entered the spotlight at the same time. While serious JS-based applications were definitely around before the advent of Web 2.0 (you can go a long way with hidden iframes, long polling, chunked transfer, forms, 204 status code), these were the exception, front-end work was mostly about layout and code-reuse virtually nonexistent.
- posabsolute 15y ago
  Well it's a good list, I guess it would be most useful to student looking for a career in front-end, you got the next couple of years of skill required right there. Then I agree with you, web publishing did not change that much, 3 years ago it was a bunch of js plugins together + nice html templates and well, it is still that currently. And I know loads of front-end that only know basic js with a svn client and get by. Then you got js web apps. There you got a world of difference. It is limitless and evolving like crazy
justinph 15y ago
I agree, but would point out that this list seems a bit more oriented to the type of folks doing web application development, rather than web publishing. Not every site or job demands knowledge of the latest tools or techniques. Is it good to know they exist? Sure, but I wouldn't count someone out who does't actively use git or only knows JS by way of jQuery. One thing I would add to the list is a conceptual understanding of how a web page gets to someone's screen. E.g., how a webserver works, what headers are, how DNS works, caching, general CMS principles, etc. Perhaps that's implicit in the list, but I've been amazed sometimes by other frontend folks that didn't have knowledge of some key piece of that pipeline.
- billpatrianakos 15y ago
  The lines are starting to blur though. These days a good generalist with a penchant for the front end is probably more desirable than a pure frot end design person. If you're working with teams then version control is mandatory. JavaScript is now being used far more beyond just DOM manipulation, SASS/LESS/Stylus are, for many, required knowledge even if you're just doing static sites, etc. Point being, the lines are blurring the the skillets are breeding with each other creating a need for generalists more than ever. You're right when you say this is probably more useful for web apps than static sites but even static sites are starting to become more app-ish. More emphasis is (rightly) being placed on things like server optimization and load times which requires just a bit more knowledge of what's going on in the backend than before. Take HTML5 Boilerplate for example. Their Apache .htaccess file is something that the front end guys should understand and even if you're working alone buildin a static site you should start getting into setting up those rules correctly and putting a lot of that stuff into Apache's httpd.conf. Basic CMS knowledge is required. Everyone ends up working with a CMS eventually unless your entire career is based on building single page static sites editable in Dreamweaver alone or something. Then there's new toys like Jekyll. Jekyll and its beginner friendly cousin Octopress require you to know a few things about the backend too and in fact require most of the skills the article describes. So you're right to a point but it looks like as we move forward even web publishing will start to resemble web app development more and more as far as tools and workflows go. Gosh, even FTP is starting to go the way of Gopher. I hope I see the day that even shared hosts start allowing and encouraging SSH usage over FTP as the norm almost like MediaTemple does.
SkyMarshal 15y ago
> scp to copy files to another machine or server Shouldn't that be rsync? I was under the impression scp has been fully superseded by rsync. Secure, more efficient, basically only transfers diffs instead of whole files.
- tene 15y ago
  rsync has a few quirks. scp is more-convenient for many people because it shares almost identical options to cp. The most frequent cause of grief with rsync, in my experience, is presence or absence of a trailing / on the source argument. Many users aren't even aware of the difference in meaning, and even those that are aware still get it wrong sometimes, primarily due to tab-completion. I personally use rsync frequently, but for newer users I recommend scp, unless they're dealing with a very large volume of data where rsync would provide significant benefit.
- mattbriggs 15y ago
  when I want to grab the latest version of a 30gb database dump, I think rsync. When I want to grab a file off my desktop when I am in a meeting, I think scp
  - SkyMarshal 14y ago
    Interesting, why not rsync for the desktop file too?
    - mattbriggs 14y ago
      It's mostly inertia, I know the scp command way better then rsync, and for small things (which are the majority for me),it doesn't matter so much what I use. The other day, a coworker freaked when I searched for a file using find . | ack file,instead of just using find properly. I gave pretty much the same argument, so he measured it, and found I was losing about 0.002s. He basically said it was he principal of the thing, but for command line tools I really need a good reason to learn something new without any noticble benefit 99.9% of the time
saltcod 15y ago
Where is the boundary for JavaScript. Is it: 1. Just jQuery—some hide/show/toggle/etc 2. That combo of "real" JS and jQuery—writing your own functions and calling them later on 3. "Real" Javascript—knowing Node.js, writing plugins and the like. I'm somewhere between 1 and 2, and I suspect most are. The jump to writing "real" Javascript is just huge—in fact it requires actual programming knowledge. If you get to stage 3, are you still a front-end developer or are you a programmer now? And the question I'm really curious about, should I invest all that time learning to program actual Javascript, or should I focus on all the other stuff?
wrs 15y ago
Years ago there was a job title at Microsoft called "Web Developer". I refused to give people this title or hire people into this role, because it was clearly a dead-end job. The era of "Web Developers" -- people who can make an HTML page work but don't have fundamental software development skills -- lasted only as long as the Great Wheel of Client-Server Development took to make half a revolution. Now the client has software on it again, and...surprise, you have to be a "Software Developer" to work on it, not a "Web Developer".
- prawn 15y ago
  See, I'd call those types "Web Designers" and use "Web Developer" for someone who does a mix of frontend/backend for the web.
  - wrs 15y ago
    To be clear, I'm talking about how someone defines themselves and their profession. Be a "software developer" or a "software designer". Don't put yourself in a "web" box, because the web will be implemented differently in a few years...like software always is. There's a professional skillset that developers and designers should have that is far deeper and more general than this year's popular web technologies. If you have that skillset, your career is a lot more secure. If you're a software developer/designer, and you think of yourself as a "web developer/designer", you're selling yourself short. And if you're beginning your career, know that you'll need learn how to develop/design software, not just "web".
    - prawn 15y ago
      Might be different in different regions and sizes of business - I don't work for a large business, I run a small business. I have called myself a Web Developer (if anything; usually I don't give myself a title) since 1995 and got by OK. There has been more than enough work for 15+ years. If the technology changes a bit, we either adjust or we don't, right? Maybe it's a lot different in large corporations?
tomkin 15y ago
I often read these types of articles and wonder if the author considers that there are many flavours of what one might consider a "baseline". While I have cloned a repo or two, I wouldn't say that it is a mainstay of how I evolve my abilities. I could interject all sorts of other expertise that I must use on a daily basis, where my lack of knowledge of such would render me unemployed. My skill set has evolved into what someone might call a designineer. Do I think everyone has to be a hybrid designer/developer to get the job done? Of course not. However, I wouldn't gather those skills and conflate that my skill set is necessary to getting the job done for someone else. It reminds me of the purist argument, where the evangelist will protest against web fonts, frameworks and the like. In 2001, if you were using CSS or JS you were not a purist. We can see that labels like these are to serve a purpose and it seems to be little more than an exercise in pedantry. At the end of the day, it's about providing quality work and getting the respect you deserve for your work.
- rmurphey3 15y ago
  The exact set of skills that one needs in order to do one's job will of course vary from person to person. What I have tried to point out in this post is that these topics are ones that anyone who calls themselves a front-end developer will need to be familiar with; if they are not familiar with them, then they risk being unable to keep up with the new information that is being shared about the front-end dev profession. This is based on my observations as much as my beliefs -- the set of things that you're expected to know in order to actively participate in the open-source front-end dev community is growing and changing, and this is my attempt to catalog those things in a way that I wish someone had done for me in the past.
  - cgarvey 15y ago
    I found your list to be spot on. I certainly have my weaknesses from that list, but I'm familiar with everything you mentioned. I've been making Websites for around eight years, but really only the past four have I considered myself a front-end dev. It seems like every month there's a new fron-end trend that needs to be experimented with and learned. It gets a little daunting at times (hard to find the time, really) so I'm glad effort is being put in to lists like yours. I think it would be invaluable to a beginner.
lukevdp 15y ago
This sounds more like the author is saying "this is where I am at with my skills, and so everyone should adopt them as a baseline". Maybe for his particular job what he describes is the baseline, but it's much too specific for a general baseline
- puppybeard 14y ago
  You have a good point. All the skills listed are good things to have, but you wouldn't look for half of them in my current job, a lot of it would be useless. And an understanding of design and usability is vital, even though we're not the designers, and most jobs I've seen require that, but it's not even mentioned in the article.
Garbage 15y ago
Am I the only one who is wondering why the hell Firebug is missing from the list of "In-Browser Developer Tools"?
beseku 14y ago
You know whats absolutely stunning about this baseline and every discussion on here about it? Not a single mention of any kind of understanding of design. Thats nothing short of ridiculous. I'd take ten front-enders who knew about baselines and typographic rhythm, relative font-sizes etc. before I took one of these guys. Why? Because these are the people translating your designs into the final medium, so you have to be damned sure they will get it right. Without knowing how to use CSS to represent designs you are pretty much useless to me. If you've ever had to hold an HTML guys hand through properly aligning the type or matching up colours then you would understand how painful it can be, and how vital this knowledge is.
Loque_k 14y ago
Less talk more action, posts like this are great as most devs will know most of it - and for those that dont, they now do. Just keep doing what you do, improving your skills and bettering yourself as much as possible. Surround yourself with great people, share, discuss and don't be afraid to ask silly questions. Everyone is a noob in some aspect.
MortenK 14y ago
This is not a baseline of any sorts, it's a list of tools and techniques preferred by the author. While a personal list of preferred tech is fine, it's by no means a standard established baseline, without knowledge of which you'll "feel more and more left behind". This should be titled "My top x tools and techniques for front-end development".
feralyn 14y ago
This is a fantastic list of great things to know. Right now. However, I wouldn't consider this a "baseline" as A) all of it can be quickly learned by an experienced dev and B) not all environments are rails/node. This industry changes languages/platforms/techniques like I change my socks. The key is not to memorize this list and use everything on it, it's to understand what's on this list, what else is out there, and use the right tool for the job.

311 points by thisisblurry 15y ago

> This might go without saying, but simply knowing a JavaScript library isn’t sufficient any more. I’m not saying you need to know how to implement all the features of a library in plain JavaScript, but you should know when a library is actually required, and be capable of working with plain old JavaScript when it’s not. I'd like to think this is because ideas of proper scripting have slowly propagated from goldmines like comp.lang.javascript and into the mainstream. People like David Mark have pulled back the jQuery curtain and shown developers that education really is the solution, not mindless abdication of responsibility. > It wasn’t so long ago that it was entirely typical for servers to respond to XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the front-end dev community saw the light and started demanding pure data from the server instead. Client-side templating was and still is a sham. It requires either an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure (IE is very strict with `innerHTML` in particular). I've dubbed `innerHTML` the "eval" of the DOM as it exposes an external parsing engine to do the developer's dirty work. Server-side processing is still the best option, particularly because of powerful parsers and the ability to hide domain logic. OWASP has an article[0] that covers XSS and DOM scripting that's fairly interesting. [0]: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Che...

chc 15y ago
I'm confused by the contrast you're drawing. Aren't you going to be using innerHTML if the server sends back HTML? That's how I always remember seeing it done.
- bmelton 15y ago
  I'm not terribly plugged in to the front-end developer community, so don't take this as authoritative, but my preferred (and more reliable) method of handling server input is generally to append new elements to existing, 'container' elements already present on the DOM. In context, I might have a 'tweets' div on the page that is empty on page load, but which will be populated by appending new div or li elements to.
  - chc 15y ago
    But how are you doing that if the server sends back HTML? Like, say you ask for a tweet, and the server sends back the following: <div class="tweet"><div class="header"><div class="username">rihanna</div><div class="retweet"><img src="retweet.jpg" alt="retweet"></div><div class="tweet-body">Check out my new tattoo of a woman getting a recursive tattoo!</div></div> You can't send that to document.createElement. Your only options AFAIK are innerHTML and writing your own DOM parser to build up a tree and use the DOM API to create the elements one by one (which will be OMGslow). And of course appending a new element doesn't make a lot of sense if your changes are transformative rather than additive (e.g. collaborative editing).
  - deleted 15y ago
    [deleted]
  - deleted 15y ago
    [deleted]
  - deleted 15y ago
    [deleted]
- MatthewPhillips 15y ago
  Yes, there are only 3 ways to render HTML in a browser; through a page load, innerHTML, or DOM apis (mostly createElement and appendChild).
  - nivertech 14y ago
    and iframe, though it's also page load
Raynos 15y ago
Maybe you should take your opinions about not using client-side code back to 1998
ebiester 15y ago
So are you suggesting we give up entirely on single page apps and go back to a full refresh of the page whenever the search terms change on a page? I am not quite clear of what you are suggesting here. How do you build a system like gmail with it's great response times without innerHTML at some step?
nene 15y ago
So what's the big difference of doing it on server side v/s client side? You can get it wrong on both sides. Especially what's wrong with a templating system? A templating system on server side can help avoid casual escaping bugs by doing automatic escaping of everything by default. Exactly the same thing can be done on client side. OK, I think I found the quote that is troubling you: > It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. So basically we are talking about the case where users machine has been compromised? In such a case I don't really see how you can be sure of anything - that user is screwed. At the same time the article suggests multiple ways of encoding the data on client side... I'm a bit puzzled. Maybe what they really meant was that you shouldn't hope at server side that the client side correctly performed the encoding, like hoping the client will escape you database query arguments... but that's just basic everyday knowledge.
ricardobeat 15y ago
comp.lang.javascript was a very inhospitable place. David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned). > an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure They are as stable as the code using them, just like their server-side counterparts. The parser isn't any less stable when called from innerHTML. Would you mind expanding on security?
- mkmcdonald 15y ago
  > comp.lang.javascript was a very inhospitable place. To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript. > David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned). It seems that you've turned a blind eye. His code's been available in a multitude of ways (I've used it myself as a learning tool). There's a GitHub repository[0] as well. > They are as stable as the code using them, just like their server-side counterparts. The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE). Fragment builders are hampered because they're either too dynamic for their own good or need to keep a laundry list of valid attributes. > Would you mind expanding on security? Apart from the OWASP article I linked earlier, it's more of a statement towards older environments. Browsers today escape input nicely, but that's meaningless for Joe Smith, government bureaucrat on IE 6. I prefer direct node creation patterns via `createElement` et al. for this reason (especially text nodes). [0]: https://github.com/cinsoft/My-Library https://github.com/cinsoft/My-Library
  - subsection1h 15y ago
    To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript. I agree with you about the usefulness of comp.lang.javascript, but I disagree regarding David Mark's contribution to education. I had to killfile him years ago, mostly due to his use of sockpuppets. Here are just two of his Reddit sockpuppets that I made note of years ago when I still visited Proggit: http://www.reddit.com/user/DeathFromAbove2 http://www.reddit.com/user/DeathFromAbove2 http://www.reddit.com/user/joesixpack3 http://www.reddit.com/user/joesixpack3

robin_reala 15y ago

I’d be interested to hear from Windows developers. I do most of the stuff on this list already, but I’m on a Mac and have been for a few years. Are the ecosystems noticeably different?

billpatrianakos 15y ago
I'm not a Windows developer but I've tried my hand and work with a lot of people who are getting into the things described in the article using Windows. Things really are harder and it's something I've been trying to explain to people I'm mentoring and they're finding it out the hard way. The thing about that statement is that a lot of times people will start a holy war over it. No one is saying Windows sucks here. It may or may not suck but that's beside the point. The reality of the situation today is that the majority of the open source community is creating things that will eventually be running on a Linux server. IIS is just not used all that much at all outside the corporate space and even they are moving toward Red Hat these days. But any time I explain to someone that they'd have a much easier time on a Mac or Linux distro they start an argument and give me that "you're an elitist" look. I'll tell them to use Git but they need a special program for it. I show them SSH and they need another app for that. Same for Ruby, most local dev servers, etc. and then every mundane command for me turns into twice the work for them because they have to do what I'm doing plus whatever extra steps plus configuration on their machines. It's really frustrating for them and they give up. A lot of times a person who has learned some basic HTML and CSS who wants to level up and start doing some version control and set up a remote server ends up giving up on the whole thing. So the whole ecosystem really is different as everything is built with a nix environment in mind. I'd been working on a Mac for a long time and needed a laptop. I got a cheap Windows laptop and thought I'd dual boot with Xubuntu so that I could deal with certain Windows file types and have an easy way to test sites in IE. Well, I ended up booting to Windows less than 10 times in 6 months and eventually got rid of it altogether because there was nothing Windows did that my Mac or Xubuntu couldn't. I even tried to write so,e desktop software and do some web dev and found that Windows is awesome for desktop apps... If you're only developing for Windows... and Windows is great for web development... if you plan to use an IIS production environment and/or you're going to program in ASP.net or C# exclusively. But again, this isn't a Windows bashing party here. It's just the reality of working with open source and web dev in 2012. There are certainly things that make nix systems difficult to work with depending on the context but as it stands we're living in a time where *nix is the default platform for web development.

blauwbilgorgel 15y ago

My baseline tools and resources for front-end development: - Page speed https://developers.google.com/pagespeed/ https://developers.google.com/pagespeed/ http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/yslow/ http://developer.yahoo.com/yslow/ - Valid HTML http://validator.w3.org/ http://validator.w3.org/ http://html5.validator.nu/ http://html5.validator.nu/ - Usability http://www.userfocus.co.uk/resources/guidelines.html http://www.userfocus.co.uk/resources/guidelines.html http://www.useit.com/ http://www.useit.com/ - Accessibility http://www.w3.org/TR/WCAG10/ http://www.w3.org/TR/WCAG10/ - On-page SEO http://www.seomoz.org/ http://www.seomoz.org/ http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//webmasters/docs/search-engine-optimization-starter-guide.pdf http://static.googleusercontent.com/external_content/untrust... - Design for the web http://www.usabilitynet.org/tools/webdesign.htm http://www.usabilitynet.org/tools/webdesign.htm - Cross-browser compatibility http://browsershots.org/ http://browsershots.org/ - Mobile ready http://www.w3.org/TR/mobileOK-basic10-tests/ http://www.w3.org/TR/mobileOK-basic10-tests/ http://www.marketcircle.com/iphoney/ http://www.marketcircle.com/iphoney/ Modify Headers add-on - Progressive enhancement http://www.alistapart.com/articles/understandingprogressiveenhancement/ http://www.alistapart.com/articles/understandingprogressivee... - Metadata http://schema.org/ http://schema.org/ - Conversion Optimization http://www.conversion-rate-experts.com/ http://www.conversion-rate-experts.com/ http://www.google.com/websiteoptimizer http://www.google.com/websiteoptimizer

recursive 15y ago

> Something has changed in the last couple of years I don't think there has been nearly as much change as Rebecca suspects. It sounds like her skills have improved significantly, and that she's projecting this onto developers at large, but I doubt there has been much of a change in general.

rmurphey3 15y ago
I hope I gave due credit to the possibility that part of what's changed is me when I said in the next sentence: "Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development." I do think the profession of "front-end development" has grown up a whole lot in the last couple of years. There have been front-end pros since long before I was even in the business, but I think the profession as a whole is being taken more seriously, and a set of baseline expectations for people in the profession is solidifying.
cygx 15y ago
No, Rebecca is right - the game changed for front-end developers when client-side scripting became ubiquitous, which is a somewhat recent development: For example, while XMLHttpRequest was introduced in 1999 (IE 5), it took years to gain traction (XHR support was added to Opera with version 8 in 2005), and incidentally, JavaScript frameworks (Prototype 2005, jQuery 2006) and distributed version control (Mercurial, Git 2005) entered the spotlight at the same time. While serious JS-based applications were definitely around before the advent of Web 2.0 (you can go a long way with hidden iframes, long polling, chunked transfer, forms, 204 status code), these were the exception, front-end work was mostly about layout and code-reuse virtually nonexistent.
posabsolute 15y ago
Well it's a good list, I guess it would be most useful to student looking for a career in front-end, you got the next couple of years of skill required right there. Then I agree with you, web publishing did not change that much, 3 years ago it was a bunch of js plugins together + nice html templates and well, it is still that currently. And I know loads of front-end that only know basic js with a svn client and get by. Then you got js web apps. There you got a world of difference. It is limitless and evolving like crazy

justinph 15y ago

I agree, but would point out that this list seems a bit more oriented to the type of folks doing web application development, rather than web publishing. Not every site or job demands knowledge of the latest tools or techniques. Is it good to know they exist? Sure, but I wouldn't count someone out who does't actively use git or only knows JS by way of jQuery. One thing I would add to the list is a conceptual understanding of how a web page gets to someone's screen. E.g., how a webserver works, what headers are, how DNS works, caching, general CMS principles, etc. Perhaps that's implicit in the list, but I've been amazed sometimes by other frontend folks that didn't have knowledge of some key piece of that pipeline.

billpatrianakos 15y ago
The lines are starting to blur though. These days a good generalist with a penchant for the front end is probably more desirable than a pure frot end design person. If you're working with teams then version control is mandatory. JavaScript is now being used far more beyond just DOM manipulation, SASS/LESS/Stylus are, for many, required knowledge even if you're just doing static sites, etc. Point being, the lines are blurring the the skillets are breeding with each other creating a need for generalists more than ever. You're right when you say this is probably more useful for web apps than static sites but even static sites are starting to become more app-ish. More emphasis is (rightly) being placed on things like server optimization and load times which requires just a bit more knowledge of what's going on in the backend than before. Take HTML5 Boilerplate for example. Their Apache .htaccess file is something that the front end guys should understand and even if you're working alone buildin a static site you should start getting into setting up those rules correctly and putting a lot of that stuff into Apache's httpd.conf. Basic CMS knowledge is required. Everyone ends up working with a CMS eventually unless your entire career is based on building single page static sites editable in Dreamweaver alone or something. Then there's new toys like Jekyll. Jekyll and its beginner friendly cousin Octopress require you to know a few things about the backend too and in fact require most of the skills the article describes. So you're right to a point but it looks like as we move forward even web publishing will start to resemble web app development more and more as far as tools and workflows go. Gosh, even FTP is starting to go the way of Gopher. I hope I see the day that even shared hosts start allowing and encouraging SSH usage over FTP as the norm almost like MediaTemple does.

SkyMarshal 15y ago

> scp to copy files to another machine or server Shouldn't that be rsync? I was under the impression scp has been fully superseded by rsync. Secure, more efficient, basically only transfers diffs instead of whole files.

tene 15y ago
rsync has a few quirks. scp is more-convenient for many people because it shares almost identical options to cp. The most frequent cause of grief with rsync, in my experience, is presence or absence of a trailing / on the source argument. Many users aren't even aware of the difference in meaning, and even those that are aware still get it wrong sometimes, primarily due to tab-completion. I personally use rsync frequently, but for newer users I recommend scp, unless they're dealing with a very large volume of data where rsync would provide significant benefit.
mattbriggs 15y ago
when I want to grab the latest version of a 30gb database dump, I think rsync. When I want to grab a file off my desktop when I am in a meeting, I think scp
- SkyMarshal 14y ago
  Interesting, why not rsync for the desktop file too?
  - mattbriggs 14y ago
    It's mostly inertia, I know the scp command way better then rsync, and for small things (which are the majority for me),it doesn't matter so much what I use. The other day, a coworker freaked when I searched for a file using find . | ack file,instead of just using find properly. I gave pretty much the same argument, so he measured it, and found I was losing about 0.002s. He basically said it was he principal of the thing, but for command line tools I really need a good reason to learn something new without any noticble benefit 99.9% of the time

saltcod 15y ago

Where is the boundary for JavaScript. Is it: 1. Just jQuery—some hide/show/toggle/etc 2. That combo of "real" JS and jQuery—writing your own functions and calling them later on 3. "Real" Javascript—knowing Node.js, writing plugins and the like. I'm somewhere between 1 and 2, and I suspect most are. The jump to writing "real" Javascript is just huge—in fact it requires actual programming knowledge. If you get to stage 3, are you still a front-end developer or are you a programmer now? And the question I'm really curious about, should I invest all that time learning to program actual Javascript, or should I focus on all the other stuff?

wrs 15y ago

Years ago there was a job title at Microsoft called "Web Developer". I refused to give people this title or hire people into this role, because it was clearly a dead-end job. The era of "Web Developers" -- people who can make an HTML page work but don't have fundamental software development skills -- lasted only as long as the Great Wheel of Client-Server Development took to make half a revolution. Now the client has software on it again, and...surprise, you have to be a "Software Developer" to work on it, not a "Web Developer".

prawn 15y ago
See, I'd call those types "Web Designers" and use "Web Developer" for someone who does a mix of frontend/backend for the web.
- wrs 15y ago
  To be clear, I'm talking about how someone defines themselves and their profession. Be a "software developer" or a "software designer". Don't put yourself in a "web" box, because the web will be implemented differently in a few years...like software always is. There's a professional skillset that developers and designers should have that is far deeper and more general than this year's popular web technologies. If you have that skillset, your career is a lot more secure. If you're a software developer/designer, and you think of yourself as a "web developer/designer", you're selling yourself short. And if you're beginning your career, know that you'll need learn how to develop/design software, not just "web".
  - prawn 15y ago
    Might be different in different regions and sizes of business - I don't work for a large business, I run a small business. I have called myself a Web Developer (if anything; usually I don't give myself a title) since 1995 and got by OK. There has been more than enough work for 15+ years. If the technology changes a bit, we either adjust or we don't, right? Maybe it's a lot different in large corporations?

tomkin 15y ago

I often read these types of articles and wonder if the author considers that there are many flavours of what one might consider a "baseline". While I have cloned a repo or two, I wouldn't say that it is a mainstay of how I evolve my abilities. I could interject all sorts of other expertise that I must use on a daily basis, where my lack of knowledge of such would render me unemployed. My skill set has evolved into what someone might call a designineer. Do I think everyone has to be a hybrid designer/developer to get the job done? Of course not. However, I wouldn't gather those skills and conflate that my skill set is necessary to getting the job done for someone else. It reminds me of the purist argument, where the evangelist will protest against web fonts, frameworks and the like. In 2001, if you were using CSS or JS you were not a purist. We can see that labels like these are to serve a purpose and it seems to be little more than an exercise in pedantry. At the end of the day, it's about providing quality work and getting the respect you deserve for your work.

rmurphey3 15y ago
The exact set of skills that one needs in order to do one's job will of course vary from person to person. What I have tried to point out in this post is that these topics are ones that anyone who calls themselves a front-end developer will need to be familiar with; if they are not familiar with them, then they risk being unable to keep up with the new information that is being shared about the front-end dev profession. This is based on my observations as much as my beliefs -- the set of things that you're expected to know in order to actively participate in the open-source front-end dev community is growing and changing, and this is my attempt to catalog those things in a way that I wish someone had done for me in the past.
- cgarvey 15y ago
  I found your list to be spot on. I certainly have my weaknesses from that list, but I'm familiar with everything you mentioned. I've been making Websites for around eight years, but really only the past four have I considered myself a front-end dev. It seems like every month there's a new fron-end trend that needs to be experimented with and learned. It gets a little daunting at times (hard to find the time, really) so I'm glad effort is being put in to lists like yours. I think it would be invaluable to a beginner.

lukevdp 15y ago

This sounds more like the author is saying "this is where I am at with my skills, and so everyone should adopt them as a baseline". Maybe for his particular job what he describes is the baseline, but it's much too specific for a general baseline

puppybeard 14y ago
You have a good point. All the skills listed are good things to have, but you wouldn't look for half of them in my current job, a lot of it would be useless. And an understanding of design and usability is vital, even though we're not the designers, and most jobs I've seen require that, but it's not even mentioned in the article.

Garbage 15y ago

Am I the only one who is wondering why the hell Firebug is missing from the list of "In-Browser Developer Tools"?

beseku 14y ago

You know whats absolutely stunning about this baseline and every discussion on here about it? Not a single mention of any kind of understanding of design. Thats nothing short of ridiculous. I'd take ten front-enders who knew about baselines and typographic rhythm, relative font-sizes etc. before I took one of these guys. Why? Because these are the people translating your designs into the final medium, so you have to be damned sure they will get it right. Without knowing how to use CSS to represent designs you are pretty much useless to me. If you've ever had to hold an HTML guys hand through properly aligning the type or matching up colours then you would understand how painful it can be, and how vital this knowledge is.

Loque_k 14y ago

Less talk more action, posts like this are great as most devs will know most of it - and for those that dont, they now do. Just keep doing what you do, improving your skills and bettering yourself as much as possible. Surround yourself with great people, share, discuss and don't be afraid to ask silly questions. Everyone is a noob in some aspect.

MortenK 14y ago

This is not a baseline of any sorts, it's a list of tools and techniques preferred by the author. While a personal list of preferred tech is fine, it's by no means a standard established baseline, without knowledge of which you'll "feel more and more left behind". This should be titled "My top x tools and techniques for front-end development".

feralyn 14y ago

This is a fantastic list of great things to know. Right now. However, I wouldn't consider this a "baseline" as A) all of it can be quickly learned by an experienced dev and B) not all environments are rails/node. This industry changes languages/platforms/techniques like I change my socks. The key is not to memorize this list and use everything on it, it's to understand what's on this list, what else is out there, and use the right tool for the job.