You're mixing multiple concepts into a single thing, and that's probably a large portion of why you're running into difficulties. There's fundamentally two pieces to a web-based application. The user interface and the server that runs it. The server piece is critical for accomplishing the tasks while the user interface is critical for triggering those actions.

Now, since this is your first, and you're in over your head (not a bad thing, we've all been there before!), you need to decide which is more important:

1) Interface turns out how you want - You don't care how sloppy the back end is, or it's trivial and you care about user experience above all else

2) Back end functionality - What the server does is critical, it holds the important pieces and the user interface can be simple at first and expanded later

3) Getting something, anything working - You want a product that just needs improvement, it can be a mess for the UI and the backend, but it's functional

4) Increasing your knowledge of how these systems are built - You recognize this project might not succeed, and you would like to learn enough so that you know how to choose and utilize existing tools in the future

5) Be able to churn out multiple applications at a quick pace - You want to be able to kick out multiple applications quickly to see which will stick better as a concept, and then move to improve the one that has the best chances

Now, there's multiple ways to address each one, and they're not necessarily mutually exclusive, I simply chose this list so that you can pick the direction you go.

If #1 is the most important, get a simple backend and live on w3schools/specifications pages for ECMAscript/other resources (unfortunately, I don't primarily do UI work and typically use the w3c recommendations/w3schools for any references I need, there are likely good communities out there around CSS/ECMAScript).

If #2 is most important, choose the language and platform and use just quick, thrown together UI to be improved later. A lot of frameworks prefer convention over configuration, so which one you choose likely won't matter to you since there aren't any "preferred" methods yet. One with an active community is best, IRC channels are your friend when the documentation fails you.

If #3 is the most important, reuse everyone elses code as much as possible, duct taping things together. There won't be much knowledge gain here, but you'll have a product that's a pain to maintain and extend (I suggest against this being your priority if you're inexperienced).

If #4 is most important, don't use anyone elses code at all. Only use built in language features and common libraries (don't use web frameworks, don't use high level libraries such as jQuery). You will most likely never launch the web app, or even get halfway done, but you will learn a LOT. A couple of failed attempts such as this and you'll be able to pick the right frameworks for your project based on capabilities and easily work around short comings of those frameworks as you hit them. This is an educational route, and not one to base a business idea on (not saying it won't work, just that it's not likely).

If #5 is most important, follow the steps for #4, then #3, then repeat as necessary until you can do #5.

A lot of people will probably disagree, but I'm a firm believer that understanding the capabilities of the underlying system and what is possible and how makes using the abstracted systems a lot easier and faster. You understand how much time you're saving, how they likely did it and you aren't completely lost the instant there isn't an existing solution to what you want to do. The idea is not to think that you're going to build a new framework that you'll use everywhere, but instead you actually understand what it's doing when you type "gimme_a_new_controller --named MyMagicStuff --with_table MyMagicStuffTable --with_fields secretIngredient,specialSauce".