Don't get me wrong, web applications have a compelling story versus native applications. Notably, the "distribution problem" of how do you get updates to users is pretty much gone. And, while the incompatibilities between browsers can be infuriating, still, there are at most a dozen that matter.
This is a long list of requirements for a beginner. Hell, it is a long list of requirements for a practitioner.
Fortunately, it can be broken up into a bunch of easy stages. Unfortunately, it will take time and energy.
First, learn "12 element HTML" -- <html>, <head>, <body> <p>, <ul>, <li>, <a>, <div>, <span>, <table>, <tr>, and <td>. Write something, using nothing but these elements, and using all of these elements. Do not use an HTML editor. Use a text editor, vi, emacs, notepad, whatever. These will be the bread and butter tags you use every day, and you will be expected to be able to fix the, usually hideously broken, HTML generated by HTML editors. Read what you have written with a critical eye towards appearance.
Now, work on appearance. Find out what CSS is. Make sure you understand CSS selector syntax. Find out what the box model is. Understand where styles can be located. Try all three, figure out what the advantages and disadvantages of each location are. Apply this to the stuff you wrote. Make it look better. Go overboard, make it look even uglier. This is will take a few days. There is a lot here, and unless you have the luxury of an on-site designer, you will have to know enough to change color, font, and location.
You may find yourself being fascinated with CSS. I am not, I just want to know enough to make it easier for the people who have to deal with the applications I write to find information. However, CSS is surprisingly broadly needed, at least in the small. Many menu systems use <li> and CSS to make the items visible, distinct, and positioned, for example.
A couple of websites have a lot of good advice on them about CSS, http://www.alistapart.com/ has a lot of good information. http://www.csszengarden.com/ shows what can be done by an artist of CSS. CSS3 opens up new possibilities.
If you have gotten even this far, you now need to think about "continuing education". You need to start being exposed to what other people are doing. One of the best sources of the is Hacker News. You want to read it at least daily. Visit the "Show HN" items, and demos. Unless it is your interest, you can safely ignore most of the financial and general interest stories. But, it is the only place I know where in-depth stories and cutting-edge demos are routinely announced. Be sure to look at comments, as well. There are some very bright people on HN, and the signal-to-noise ratio is unusually high.
Now turn your attention for a day or two to HTTP. HTTP is "stateless". What does that mean? How does that affect application development? What kinds of interactions with a server do browsers use? What is the difference between a GET and a POST method? When can servers respond to browsers? Read the standard, the actual standard, not some simplified version.
Now back to HTML. What is a <form>? What are all of the input types available? When is it good to use each? When is form submission triggered? Design some forms. Don't forget that forms can be styled. Have someone else try to use the form, watch them to see what appear to be problems, have them tell you what the problems are. What you think are problems and what others think are problems will often be different. Both matter!
Up to now, everything could be done with just a browser using file:/// URLs. Now you need a web server, and preferably a web application server. Install one, pyramid, rails, flask, django, whatever looks reasonable to you. Why? Well, forms aren't very interesting unless you can somehow save and retrieve the information in them. Install your web application server. Get a basic "Hello, Web" application running. Read the documentation.
Wire in a basic persistence engine. At this point, it doesn't matter much which one you use. A lot of people like sqlite at this stage. I have reservations, because it stores everything as character, and doesn't fail properly. If you like SQL databases, PostgreSQL is very good. Figure out how you are going to use the persistence engine from your application server. In particular, are you going to use direct function calls, or are you going to use some kind of an adapter (an ORM, like SqlAlchemy, for example). If you already know the database language, you are probably better off using direct calls, especially at this stage. Constructing the mental models required to work effectively is difficult and the more "moving parts" you have, the more complicated the mental model has to be.
You wrote a form. Catch it using the application server. Persist the data. Write another form so that you can retrieve the item and display all associated data. Look at your form. Does it have date fields, or numeric fields, or times? Are some fields required for the data to make sense or to be stored? OK, implement server-side logic to check the input. (You will always have to do this on all forms -- client-side logic helps the user immensely, the form will be more responsive -- but client-side logic can always be subverted.) OK, now comes a big question. What do you do in the presence of errors? How do you communicate them back to the user? How do you prevent data from being lost?
Congratulations. You can now make any 1990's style web application. But, "modern" web applications are a bit different. In order to make the application more responsive to user actions, more and more of the action is being moved to the client side, that is, more and more is happening in the browser itself.
An aside: and this goes for all web development. Avoid w3schools.com. It is full of inaccurate information. See w3fools.com, and in particular, http://w3fools.com/#what-should-be-done for better resources.
If you do go with jQuery, read Rebecca Murphey's jQuery Fundamentals book. (This is supposed to be extended and developed into learn.jquery.com, but that site is not ready at yet). In particular, all of the examples at jquery.com use an approach that requires heavy use of anonymous functions, often deeply nested. This is much harder to read than necessary, and anything that is harder to read is also harder to write.
You can now write most modern web applications. There is lots more to learn, and this includes lots that I haven't learned yet. The HTML5 technologies promise a lot of new options, and will definitely allow us to push even more to the client side. Note that HTML5 form inputs have a lot of new options. Read about them, think about using them.
One thing that is often underestimated is the amount of reading required. There is a lot. And, as fast as most software development practices change, web software changes even faster. Do not expect your hard-won knowledge to have a long working life. Change is constant, pervasive, and rapid. Keep reading, keep thinking, keep trying to improve, and keep practicing!