You need to focus on delivering the end product and not some teck stack learning journey.
Just keep it ridiculously simple on the front end and you should be vaguely fine, security and accessibility not withstanding.
User interactions -> events -> event handlers -> listeners. If there is no third party code in your application you can skip the listeners if you want and it would make your application dramatically more simple.
Use of messaging via web sockets will also dramatically reduce complexity in your app down the line from an architecture perspective, but if that requires more than a day and half to execute and scale on the front end then don’t do it.
Finally, understand the spirit of the language: lexical scope, functions as first class citizens, data structures, event loop. This is the most important part. If you are not immediately comfortable with these concepts you are in deep trouble and should pay someone else to do this work.
Either way the OP has to both learn and deliver a product in a short time frame. It just makes more sense to cut out all the unnecessary bullshit developers use to compensate with.
I think it's way quicker to put out a MVP with a good UI framework (something like MUI or Chakra or Ant) than to spend a lot of time building up primitives from scratch.
It's like the difference between writing Visual Basic and C++ or whatever. Different use cases.
Without knowing what the OP is actually trying to build, it's hard to say what's more suitable.
I wouldn't necessarily default to vanilla OR React. It really just depends.
I was in that line of work long enough and have heard that false analogy enough to know that it’s people pretending to be arrogant to distract from their stupidity. Rephrased its really just: I shouldn’t have to form of whining because they never learned in the first place and are embarrassed by what super beginner things they absolutely cannot do.
Work required some frontend tools with no devs available and I was assigned the work. The folks who would usually do that work were pushing me towards React, Vue, and Jquery solutions. I took a look at each, knew I would be responsible for understanding and maintaining the whole systems, and went with vanilla HTML, CSS, and JS instead.
Started out returning simple pages. Added styling to meet requirements. A lot of it was embedded in <style> tags until I found a way to organize it into separate classes. Then added JS for event handlers, listeners, and scripting the simple the pieces that needed to be automated.
That system has been running in production for years now. New features and bugs are easy for me to identify and add or resolve. It's also given me a solid base understanding to migrate components to JQuery and build other systems in required framework. Zero regrets about that choice. It was simple to learn, quick to build, and solid.
I normally use Next for sites that are write-rarely-read-often. Its strength is in offloading some work to a light backend and caching the results, so clients don't have to do that. It's not appropriate for use cases that are either real-time or simple/low-volume enough to not need server caching.
Depending on what you're trying to build, simpler solutions like Astro or Remix or Vite might be better. Or static HTML with some JS thrown in only where needed (check out HTMX and Alpine).
You might not even need React either. You can check out Svelte and Vue too. If your project is like jQuery powered sites of old, today's vanilla Ecmascript is about as powerful and can do a lot by itself.
It really just depends on what you're trying to build. They all output some combination of HTML, JS, CSS, and occasionally Canvas or SVG UIs. So the choice is really about developer ergonomics and out of the box features that support whatever you're trying to build.
The batteries included frameworks are more powerful to support more complex projects with server-side needs. If you don't need all that, a simpler client based solution will be easier to reason about and troubleshoot. If you don't need heavy client side interactivity, sometimes a backend driven solution is better.
-----
If you're not sure, just default to learning Next and especially React. Not because it's the most appropriate, just that it's the most popular. Easy to get help for and to hire for if you need it.
- The starter template is like a collection of web dev best practices.
- The community is great. Beginners should ask a lot of questions, and the Svelte community is pretty good at trying to help them.
- The DX is wonderful.
I'm building this with Kit: https://weather-sense.leftium.com
The only caveat: if your goal involves finding employment choose React (Next.js) because there are way more openings.
There are a number of long tutorials on YouTube... will get a couple of links when I'm back at the computer
It's a layer on React and you can keep things simple from the server actions point of view (they are still pretty new in React proper too)
Docs... It's react, they don't need to write that documentation, just the nextjs parts. I have had no major issues with their docs, not sure what you mean by moderately complex thing
If you just need to support things like user auth and some dynamic content pages, then most of the time you'll be fine with a server side framework like Laravel. I'd recommend Laravel because the documentation is great and you get a lot of out of the box – although most of the time you'll be better served just picking a framework written in a language you're familiar with.
If you really need client-side rendering then Next.js is probably one of the better choices given its popularity, although Vue is just as powerful and slightly easier to pick up for beginners so I would recommend that. I'll never understand why Vue doesn't get more love.
Personally I think people are far too quick adopt frontend frameworks when all they really need is a good backend framework and a good templating engine for dynamic content. Unless you need to dynamically load content on the page from an API or do some really fancy client-side stuff, you don't need a frontend framework and you'd be better off keeping things simple.
It's super hard to recommend anything from the single sentence of info you've given us here though.
There are also a CRUD generator available in the Nest.js ecosystem which can scaffold a project for you quickly. https://docs.nestjs.com/recipes/crud-generator
It might help if you defined "medium complexity" more clearly, as this will strongly influence the choice of tech stack based on your actual requirements.
For background, I got into web development via standard HTML/CSS/javascript, then jQuery, and more recently moved on to React-based frameworks (Gatsby, NextJS).
My opinion is that React-based frameworks have raised the level of abstraction too high and attempt to solve problems that 99.9% of web applications don't have - such as optimizing web KPIs like First Contentful Paint and painting a picture-perfect SEO story. These things matter when you're afraid your user base might run away from your application and never return if you don't serve them something within the first 250 milliseconds of landing on a page.
If your user base consists of more than just the reptilian brain, I would suggest you return to the basics and write web apps that take advantage of the core HTML5 spec. There are a huge number of features available in native HTML in 2024 - why isn't the web dev community knowledgeable about those features, let alone using them?
The advantages of "minimalist coding" are numerous:
1 - A better, portable understanding of how the web actually works - be a long-term developer, not a short-term frameworker[^1]
2 - Agility in coding - refactors are not a thing to be afraid of when the code base is small and manageable.
3 - Minimal external dependencies, especially with the hell that is the npm world. My Django project has a total of 8 production dependencies - half of which could probably be removed if I wrote a couple hundred more lines of code. Compare that to the hundreds+ dependencies that a boilerplate React-based framework project will hoist upon you. I admit, pip in the Python world is not great - but I can get my brain around the problem and deal with it.
4 - Long-term maintainability - Older tools have staying power. If a tool has been around for 20 years and is still maintained, chances are it will stay around for another 20 years. Compare that to the latest flavor-of-the-day framework that might stop being supported when a big company decides to fire that team and shut down support for the service (e.g., Gatsby after being purchased by Netlify). Waking up and finding out your web app will no longer run ever again is a miserable feeling[^2]
[^1]: https://archive.ph/XSPRr