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

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.

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.

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!

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.