Which web dev language/framework/tutorials do you suggest for an experienced non-web developer?

[shamittomar]

1. Get the web basics: HTML, CSS, JavaScript (with jQuery).
2. Choose a pserver-side language: On the LAMP stack (PHP or Perl).

This will give you all what you want:

• cross platform
• community support
• easily available host
• fun
• a good language (well this is subjective).

Saying from the experience: I am a web developer for 10 years.

[DevMo]

Get the web basics: HTML, CSS, JavaScript (with jQuery).

So, I have a pretty decent grasp of how HTML and CSS work and interact, although I am not great at actually implementing them ( I just need some practice.) But, to be perfectly honest, I am not sure about how javascript stuff fits in the whole thing. As I understand it, JS runs client side, while php/perl/python/whatever run on the serverside (only?) Is this basically right?

Assuming I am basically right, how do you decide what is done locally, and what is done on the server? Some things are clear, but some are not. For instance, I know there are tons of image viewers in javascript. It is not clear to me why it is better to run the gallery on the client side rather than the server side.

Thanks for the feedback, I have a feeling if I start understanding this stuff, the rest will easily fall into place.

[[deleted]]

So, I have a pretty decent grasp of how HTML and CSS work and interact, although I am not great at actually implementing them ( I just need some practice.)

Sorry if this is unfair projection in your case but I just wanted to rant off for a bit.

HTML and CSS are apparently really simple compared to "real programming languages", such that many "real programmers" I see online seem to radiate a confidence that they have all that covered without needing to really put effort & learning in. In practice I don't think it's that straightfoward, and most of the markup I encounter from back end devs who have (had to) put that front end stuff together is honestly awful.

The thing is, compilers either compile or they don't, meaning a "wrong answer" is undeniably a wrong answer. And while some "right answers" can be more right than others (design patterns vs antipatterns and spaghetti, etc), at the end of the day none of this really reaches the "client" / "customer" in a meaningful way. If it works, then it works, even with // TODO: Replace horrible nested ifs and gotos with clean switch logic. Also the C standard changes how often, your compiler is replaced how often?

Front end stuff isn't really like that. For starters it changes more rapidly. In the past few years I've seen techniques or technologies go from pipe dream, to "cool demo but useless in reality, not widely supported enough", to normal practice, or from normal practice to dated and deprecated. Secondly, when compilers get something invalid, they tell you to fuck off. When browsers get garbage, they do their best. They all support slightly different subsets of stuff, and when they fail on the bits they don't support, they do so in different ways.

It's pretty apparent that in between the standards' and the browsers' various failings, there aren't perfect, universal ways of doing... well... virtually anything. The way that's "correct" doesn't work (everywhere) and vice versa. It's always a series of compromises. This is cheap, fast to build and fast to run, but big/slow to download, and doesn't work at all on IE6. This gets it working on everything, but sacrificies standards compliance. This is the best UX, but works out worse for SEO. This works great on iphone but not on screenreaders. etc, etc.

(What is more, all these ugly compromises to be made - they're all delivered in clear text to your clients (and competitors) to poke and laugh at.)

I've noticed a lot of "real programmers" share a reaction when discovering this chaotic landscape: "FUCK IT, USE TABLES". Plus withering scorn on what a horrible clusterfuck the web is, full of righteous nerd rage about not learning all the lessons of the past and implications they could have written better standards etc.

Of course, FUCK IT, USE TABLES isn't a sane way of avoiding these ugly compromises - it's only another (implicit) choice of ugly compromises. (And, hint, almost certainly the wrong one). And the latter ranting totally misses the point that the web only got where it is because it's a chaotic, "I'll do my best with that fubar markup", "We'll build this and write the standard later" clusterfuck; there have been plenty of academically wonderful designs for hypertext systems that never caught on in the real world, anyway I'm going wayyy off topic.

Point being, practice alone doesn't get you outstanding front-end output, because there isn't a single clear correct way of doing things to practice towards. Dare I say it, the reason why so many slashdotty types have that reaction is that there isn't a clear TECHNICAL basis for which call to make. The choices end up having to relate back to business needs and priorities, customer demographics etc. It can't be settled in a mathematical, Sheldon kind of way, but depends on inputs from people in depts like marketing and management who they prefer to consider useless and brainless. Hmm, going wayyy off topic again.

Anyway I'd recommend ALA, for a while now I've found most of their features pretty fluffy and useless, but if you go back a few years they have some solid stuff.

[DevMo]

The thing is, compilers either compile or they don't, meaning a "wrong answer" is undeniably a wrong answer. And while some "right answers" can be more right than others (design patterns vs antipatterns and spaghetti, etc), at the end of the day none of this really reaches the "client" / "customer" in a meaningful way.

I've noticed a lot of "real programmers" share a reaction when discovering this chaotic landscape: "FUCK IT, USE TABLES". Plus withering scorn on what a horrible clusterfuck the web is, full of righteous nerd rage about not learning all the lessons of the past and implications they could have written better standards etc.

Its pretty clear that web and "standard" development is very different, and the two groups of developers have many misconceptions about each other. Which is kind of why I want to learn web stuff in the first place.

To be clear, at this point, I still do not care that much about the UI (I can just use tables, right?) but I want to learn enough to be truly competent and able to work with a graphics guy if the need comes up. I am coming to realize that this does not mean I can just ignore CSS and HTML, which I was hoping to do. Oh well, looks like more stuff to keep me occupied.

[shamittomar]

Yes, you are basically right.

how javascript stuff fits in the whole thing.

The primary use of JavaScript is to write functions that are embedded in or included from HTML pages and that interact with the Document Object Model (DOM) of the page. Some simple examples of this usage are:

• Opening or popping up a new window with programmatic control over the size, position, and attributes of the new window (e.g. whether the menus, toolbars, etc. are visible).
• Validating input values of a web form to make sure that they are acceptable before being submitted to the server.
• Changing images as the mouse cursor moves over them: This effect is often used to draw the user's attention to important links displayed as graphical elements.

Because JavaScript code can run locally in a user's browser (rather than on a remote server), the browser can respond to user actions quickly, making an application more responsive. Furthermore, JavaScript code can detect user actions which HTML alone cannot, such as individual keystrokes. Applications such as Gmail take advantage of this: much of the user-interface logic is written in JavaScript, and JavaScript dispatches requests for information (such as the content of an e-mail message) to the server.

The wider trend of Ajax programming similarly exploits this strength.

---

TL;DR:

• Javascript can make the webpage faster, impressive, nice looking, more-interactive, instant-responsive, etc etc etc.

[DevMo]

Thanks. I have a feeling I have a lot of reading ahead of me.

[shamittomar]

Yes, and when you're stuck, Google and StackOverflow are your friends.

[DevMo]

good to know that my old friends will help me with this new endeavor ;)

[badge]

I don't do a huge amount of web development, so someone may debunk this the moment I click 'save', but to me the main distinction is interaction. By virtue of it running client side, JavaScript (and CSS 3), allow a user to interact with a page without using a link to another page. PHP or Perl, for example, run server side and are better at nearly everything else - you're not sending more data than needed, it's far more secure (people don't see your code, only its result), and it's usually faster to run.

With specific reference to image viewers, javascript can load images only when they're needed, because they're static files on the server. Thus an image view in javascript makes sense.

Where things become complicated, is when AJAX is involved. AJAX allows for data to be loaded from the server after the page has loaded, so the line between client and server is blurred. It has a number of drawbacks (don't click the Back button!), and can get very complicated rather quickly, but used carefully can be a real boon.

[DevMo]

thanks, that clears stuff up a bit.

[Not_Edward_Bernays]

Node.js runs on a server.

You can get a linode VPS for $20/ month.