2

My background is back-end server development. Very back-end.

Now I work in a position where I need to also take care of front-end. Nothing fancy but I need to be able to code for front-end as well. As I said no fancy stuff as I am not a designer.

I know some very basic stuff about html/css/js but most of the time I spend googling when I need to do something. So I am wasting time.

To give an example I needed to upload a file from the web page but I was not aware that there is an input tag specifically for file-upload. So I spend quite a while googling to figure out how to do it. So I am not sure if for example this should be something I should have known and it is a gap that I have or not.

So what I am interested in is in what should I invest time to "master" so that what I daily need to do, I will be able to do, without spending too much time searching my way.
In a nutshell I am interested to understanding on what are the core "fundamentals" I should focus.

To give an example:
In CSS I think I should invest time in attribute selectors or positioning but spending time learning fonts is a waste of time for my needs. Am I wrong?

So with this is mind I am interested in the what to must know to survive in html/css/javascript?

UPDATE
None of the answers so far are really relevant and I really need some help.
May be my post need some clarifications? Is there something not clear?

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
Jim
  • 316
  • 1
  • 3
  • 10
  • possible duplicate of [What should every programmer know about web development?](http://programmers.stackexchange.com/questions/46716/what-should-every-programmer-know-about-web-development) – gnat Sep 07 '13 at 13:26
  • @gnat:The question you refer is not related.I am not asking if I need to know sql or http or tcp or versioning etc.I know this stuff. I am asking a specific question on html/css and js – Jim Sep 07 '13 at 13:28
  • @gnat:I know web development.I know how to deploy a web application and how to code from the server etc – Jim Sep 07 '13 at 13:28
  • What backend language are you using? Hint: if the answer is Ruby, that is very good – tjons Sep 07 '13 at 14:06
  • 3
    @Jim so you're looking more for [Where to master HTML, CSS and Javascript?](http://programmers.stackexchange.com/questions/29396/where-to-master-html-css-and-javascript?) with a dash of [how easy is html/css?](http://programmers.stackexchange.com/questions/187903/how-easy-is-html-css) –  Sep 07 '13 at 14:26
  • @MichaelT:I don't see *anything* relevant in this links – Jim Sep 07 '13 at 15:22
  • 4
    `So I am wasting time`. I bet you are not. You are out of your comfort zone. Learning takes time. Try reading some books on css (`css mastery`)/ html / javascript (`secrets of the javascript ninja`). – Simon Bergot Sep 07 '13 at 16:06
  • @Simon:I don't have a problem reading books.But most books on the topics are 400+pages long.So I think it would be best to focus on the parts that really matter and avoid reading things that would be useful to people that have more needs than me.E.g. reading a 60page chapter on fonts and text formatting in CSS IMO is a waste of time.So I am trying to collect all these "candidate" for non ignoring chapters – Jim Sep 07 '13 at 16:11
  • 3
    html/css books usually have a lot of images to show how things will be rendered. So 400 pages can be a pretty quick read. `As I said no fancy stuff as I am not a designer.` Designing and programming are two different jobs. A web page can be designed in photoshop by someone who has no clue about css. Programming a web gui can require a lot of technical knowledge, because what looks basic at first can end up being really difficult (like aligning 2 pieces of text). Getting quickly the big picture can help you to avoid wasting a lot of time. – Simon Bergot Sep 07 '13 at 17:09
  • 1
    Sounds like you are in the process of reconfiguring neuron firing patterns through repetition of stimuli. Humans call this "learning". It's good because it preserves the ability to do more "learning". – idoby Sep 07 '13 at 18:30
  • If you're reading a technical book and there's a chapter about something you aren't interested in at the time, you have three choices: (a) skip it entirely, (b) skim through it to see if there's anything that might be useful, or (c) read it anyway to broaden your knowledge of the subject. If I'm under time pressure and searching the web doesn't help me I'll often start with the index of a relevant book and look at/for keywords that seem relevant. No need to read the chapter on fonts if all you're after is file uploads. – user Sep 07 '13 at 19:01
  • 2
    @Jim, I think you do need to clarify exactly what it is you are asking. We only have the vaguest idea what your job is, and your comments so far come across as asking "How can I instantly learn what I really need to learn and avoid learning what I don't really need?" which is unanswerable. We can't tell you if CSS is essential and fonts are irrelevant to doing your job because we don't know the job requirements. You might create a dandy CSS stylesheet, but have your manager chew you out because your font choice makes your app completely illegible. – Charles E. Grant Sep 08 '13 at 00:15
  • Repeated clarifications, a lack of useful edits, answers that are all over the map, and a continued insistence that the answers aren't helpful strongly suggest that you aren't actually interested in learning and haven't done much research or thinking of your own in order to focus your question. I've therefore voted to close. This *could* have been an interesting topic but not if it's just another "teach me UX in 6 seconds" attempt. – Aaronaught Sep 08 '13 at 16:21
  • I suggest you look at Peter Norvig's essay, [Teach Yourself Programming in 10 Years](http://norvig.com/21-days.html), and consider how that applies to UI/UX (hint: it does). – Aaronaught Sep 08 '13 at 16:22

5 Answers5

8

I know some very basic stuff about html/css/js but most of the time I spend googling when I need to do something. So I am wasting time.

No, you're not. You're spending time on research and self-directed training, which is the choice you or your employer made when they assigned you to do something you hadn't done before in lieu of hiring someone specifically for the front-end. Instructor-led training may be worthwhile, especially if your organization has an existing training program.

But that's basic professionalism. On to your question:

"What are the core fundamentals' of client-side development I should focus on?"

(In order:)

0: Whatever your organization has already done. If most of the rest of your pages are built on Prototype, use that. If the site you're working on is drupal-based, learn drupal.

1: XMLHttpRequest, along with XML and JSON, and how they communicate with the sever-side of the application. <input type="file" /> is neat, but it winds up as an HTTP request of some kind in the end anyway.

2: JavaScript Events / Asynchronous Programming. Unless your client-side is absolutely trivial, knowing how to properly attach events to the DOM and user interaction is essential. If your client-side app grows in complexity, knowing how to raise events can keep your code DRY.

3: <a>, <form>, <input> elements: The basic set of widgets you have for user interaction are here. Virtually everything else in the HTML standard can be ignored as "design", until you get to complex solutions involving the <iframe> and <object> elements.

4: DOM manipulation. You'll get a lot of mileage from knowing how the client can load or change part of a page. createElement, appendChild, setAttribute, and insertBefore are methods that have utility in client-side programming and XML manipulation. (Reading part of a page can help, too.)

5: CSS selectors. Not the attributes that make up a rule, but the portion of the spec that allows you to select the set of elements that will be rules will be applied to. Every framework I've seen uses a variation of these as its basic syntax, and, as with most of the HTML elements, the specifics of the rules can be ignored as "design"

If your organization doesn't have an existing framework choice, and you've familiarizing yourself with the five items above, then and only then should you take a look at frameworks. jQuery is popular and mostly worth the overhead (especially if it's a public website and you have to deal with cross-browser compatibility), but like any other framework it's far more useful as a tool than a crutch.

(And if you find yourself worrying about fonts, tables, colors, or document flow, stop what you're doing and find your "designer" hat, because you've crossed the rubicon and you're doing design.)

user
  • 2,703
  • 18
  • 25
DougM
  • 6,361
  • 1
  • 17
  • 34
  • +1.Why not tables? I understand that we should prefer css instead of tables but still tables are needed to display data, right? – Jim Sep 07 '13 at 16:21
  • 6
    Use tables to display tabular data, never for layout. Doing otherwise is a mistake that **will** (not 'might') bite you sooner or later. (Think of tables within tables within tables within tables) – Dan Pichelman Sep 07 '13 at 16:41
  • @Jim: Tables are **DESIGN**. You asked about development as opposed to design, and I answered. If you're worrying about fonts OR tables OR divs OR lists, you're doing design. (Design can be done by hand-writing an HTML file with JavaScript turned off. Development requires a compiler or a script interpreter.) – DougM Sep 08 '13 at 20:46
4

This is interesting as I read the title I wondered if the question was from one of my guys. As the 'entrepreneur' I have run into employees who let themselves get straitjacketed by their view of the world.

What you need to learn is what you need to accomplish your job. If you think that we can put some boundaries right now on what you need to learn then you are in my opinion doing both you and your employer a disservice.

If you ever get hired for a position and they tell you upfront that you already know everything you need to do the job then you are either working for the government or you are working for a union. I suspect you were hired because someone thought your ability to solve problems was better then the next guy they interviewed.

I tell my guys that if they are at least daily not asking questions of the team - me or Google then the job is too easy and we need to do an intern into that task and move them to something higher valued.

PyNEwbie
  • 167
  • 4
  • I'm a union employee who works for my state government, and I had never seen the language my principal project is written in before I started. There are real programmers working in the public sector, fwiw. – DougM Sep 08 '13 at 20:49
  • Actually you are right and I am feeling slightly guilty about this post I might delete it – PyNEwbie Sep 09 '13 at 13:22
3

Find a mentor, if you can. Reading books and laundry lists of "dos and don'ts" will only get you so far.

I've worked with some hardcore "back-end" developers who were able to do some excellent work when paired up with even a casual "front-ender". Left to their own devices, with no pair or code reviewer, they can still occasionally get lost or go off the rails.

I don't know what kind of an organization you're in, but you might want to suggest to your manager that designers generally cost less to hire than developers, including designers who know HTML + CSS, and although you'd like to learn more about front-end development, it is probably a waste of your time (and therefore company time/budget) to focus exclusively on that area.

If you really can't buddy up, then read a book or visit some of the questions given to you in the comments. Like I said, I'm not going to provide a list of areas or dos-and-don'ts because (a) we have no way of knowing what's most relevant to the work you'll be doing unless you tell us what that work is, and (b) the question has already been asked a dozen times here. I'm focusing on the "what should I do if I'm a back-end developer being asked to do UI work" and my answer is, don't do it alone.

Aaronaught
  • 44,005
  • 10
  • 92
  • 126
  • I don't have a problem reading books.But most books on the topics are 400+pages long.So I think it would be best to focus on the parts that really matter and avoid reading things that would be useful to people that have more needs than me.E.g. reading a 60page chapter on fonts and text formatting in CSS IMO is a waste of time.So I am trying to collect all these "candidate" for non ignoring chapters – Jim Sep 07 '13 at 17:07
  • 3
    @Jim: I thought I already addressed that point. As someone with no experience in this area, you're not qualified to assess which sections are a waste of time. You don't know which parts "really matter", and neither do we, because we don't understand your problem domain and you don't have the vocabulary to describe it in detail to us. You can take shortcuts, but I'd only advise it if you have somebody to watch your back, otherwise you're likely to make very serious mistakes and omissions. As is, you're going to get some really terrible advice (i.e. telling you not to go straight to jQuery). – Aaronaught Sep 07 '13 at 17:10
  • Ok.I will ask it differently. Do you have experience in writing client side code?If yes how often did you used your skills in text formatting? – Jim Sep 07 '13 at 18:06
  • @Jim: The answer to the first question is definitely "yes". The answer to the second is "it depends", which is what most people with experience will answer to most questions of that form. Text formatting is a fairly large topic. It's sort of like asking you, as a self-described back-end developer, if you've ever had to work with "data structures". What specifically are you referring to? I definitely *have* had to work with fonts - there's often even back-end work to be done with those, e.g. preventing hotlinking to commercial fonts. – Aaronaught Sep 07 '13 at 23:28
  • Now I can understand what you mean.I am working for a site that is internal to the company and presents data. So it does not need to be fancy. As long as the data are in structured and nothing is missing it is ok.Is this explanation better? – Jim Sep 08 '13 at 08:54
  • @Jim: It's partly because of this attitude that so much business software is of poor quality. Almost every application can be described as "presenting data", and that's usually how someone with no UX experience will attempt to define the problem. Talk to a good designer, or even a business/systems analyst, and they will have a completely different spin on it. If you're going to be doing UI work, you need to learn a lot more about the **"user"** part in particular; lists of tips and tricks or HTML/JS subject areas will only give you the *illusion* of competence. – Aaronaught Sep 08 '13 at 16:17
  • I don't understand your last comment.I only asked a guide-path to start. Not end there – Jim Sep 08 '13 at 20:00
  • @Jim: That's exactly what those 400-page books are - *introductions*. You don't seriously think they contain everything there is or ever will be to know about being a UI designer/developer? – Aaronaught Sep 08 '13 at 21:15
2

This is a great question with some really interesting answers. Just recently I was listening to a presentation by a really smart guy with bucket loads of back end experience; one thing that I remember was him saying that his company were dropping the backend/frontend/test engineer distinctions. The reason was that right now, all developers are expected to cross pollinate across those disciplines. The rise of MV* development client side, the growing prevalence for technologies such as node.js and the move towards dynamic webpages has meant client side development has been gradually getting more (programming) technical. Coupled with the ambitions of TDD, BDD and bare minimum CI means (and this is client side too) brings the testers into the loop. Sharing domain models over a SOA and intricacies of your RESTful architecture mean that all parties must understand somewhat of what the others do - and work together when they dont.

Anyway. I too began life and progressed fairly far as a Server Side developer before a new job expected me to start embracing more of the complete picture. Firstly, depending what you might be expected to do, it is hard. Dropping a box of a page and making it submit form data aside, if they want you to mock up something with a few elements on it, that may trigger some small dynamic behaviour, possibly be reusable and maybe have some nod to beauty - there's a real challenge! Cross browser, cross platform, cross device, cross generation, it is a minefield. Considering page load speeds, accessibility, behaviour on portrait mobile vs latest mega resolution apple display, and the ever present, do we have to support IE7?

Maybe none of that is a concern, in which case:

  • Learn the super basics. There are some weird gotchas in there - self closing script tags are invalid, huh? Can I use the HTML5 doctype for everything? How many H1s on a page?
  • Learn about page flow and how absolute/relative positioning works. Seriously, coupled with float, clear and the various offset mechanisms (margins, padding, collapsing margins), this is a must - it is more intricate than it looks.
  • display: block, inline, inline-block... and how this affects page layout.
  • visibilty:hidden vs display:none
  • Learn how to include different CSS files in different situations through IE macros or media queries.
  • Use backgrounds rather than images, often.
  • Use the tools to help you. Firefox and Chrome both come with excellent developer toolkits to help you modify markup and css in the browser as well as debugging javascript code.
  • You've mentioned selectors, learn them, that's the easy bit. Once you've learned them learn how modern web development techniques are using them to create lightweight, readable stylesheets. (There was OO CSS and now it seems it's all about being modular - SMACSS is a great resource.
  • Look at libraries like Modernizr to help reduce some of the pains of legacy browser support.
  • Learn what HTML5 can do for you (as in the new bits). You might not need it just yet, but there is lot of good tech in there. An example might be the new File API. Then use caniuse to see what browsers support the features.
  • For JavaScript, at first, don't learn jQuery. A lot of the time you will not need but you'd use it anyway, and then it's just bloat. You gain a lot by understanding what you get out of the box!
  • Object protoypes, learn them now, it's useful knowledge later.
  • The event model, the single threaded nature (well, mostly), how people use elements as beacons to bind listeners to, preventing memory leaks through unbinding your functions.
  • Anonymous Objects.
  • JSON and how to use it, it's easy and everywhere.
  • Learn how to structure javascript, some things will catch you out - what no function overloading? The book (and related examples) by Addy Osmani is my go to refernece.
  • Javascript libraries are great though. They remove the majority of cross browser nonsense. Especially if you are working with Asynchronous code, do learn what these libraries give you, and reach for them when you need them.
  • Learn whatever your Client Side team are doing. Are they using LESS/SASS/Stylus to preprocess their CSS? Backbone to separate their model and view? A framework like jQuery? A boilerplate responsive grid or component library like Skeleton or Bootstrap?
  • Validate your code, use the W3C validator and tools like JS[LH]int.
  • Give back. Most of the guys I worked with doing complex javascript were not from programming backgrounds. You think differently, you can work together to write much more beautiful code.
  • None of this is a waste of time, like it lump it the web, the visible web, is a large part of the future and knowing how it works will only benefit you.

While you're learning it, write a book, there are going to be a lot of people in the same boat!

JohnMark13
  • 711
  • 4
  • 7
  • +1.What do you mean by object prototypes and anonymous objects? – Jim Sep 07 '13 at 19:21
  • It depends on your background as to how to describe it! Javascript is untyped (which reminds me, make sure you check the difference between `==` and `===`) and so you can think of Objects like key value pairs. Plus a little bit. The little bit is the prototype and it's the bit that makes Javascript a little OO. With the prototype you can assign values and functions to a "type". Coupled with this, remember that functions are first class citizens too. You can (and will) assign them to variables and pass them around as arguments. This leads to annonymous objects/functions, closures and modules! – JohnMark13 Sep 07 '13 at 19:43
  • poor you - have you tried asking your boss if he'll be practising what he preaches and manning the reception desk, and doing the filing by supporting all areas of business administration, not just management. – gbjbaanb Sep 08 '13 at 14:18
-2

That depends what you need to do - it might have been a long time ago, but you would do exactly what you did when you started learning the back-end technologies.

Start with basic tech, forget CSS etc, go straight to simple layout and simple code. Once you've got the hang of that, you can move on to a web client javascript framework. Once you've got the hang of that.. you should be in a position to know what you're missing.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • That's not going to cut it as I am not a student and I am working.I need to reduce the learning curve and as I already said I know the basic stuff. – Jim Sep 07 '13 at 13:38
  • 5
    @Jim: You can't ever *reduce* a learning curve, you can only take shortcuts - typically with painful consequences. – Aaronaught Sep 07 '13 at 16:36
  • 1
    -1. Never forget CSS! – tjons Sep 07 '13 at 19:30
  • 1
    @TJonS always forget CSS when you first start learning how to write html. You must keep things as simple as possible, now it might be that this phase is short and you move to the better html+css quite quickly, but you need to learn in chunks ever-expanding complexity, not jump in at the deep end from day 1. – gbjbaanb Sep 08 '13 at 14:12