austin-cheney 4 days ago

Vanilla. Otherwise you will end up building the hypothetical nuclear reactor used in the story to explain bike shedding. If your goal was to be a long term corporate imposter then I would recommend React and a bunch of other bullshit, but you don’t that time.

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.

  • briangray 3 days ago

    Seconding this. Not as a qualified frontend dev, but as a backend dev forced to learn frontend in a short time frame.

    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.

  • ldjkfkdsjnv 4 days ago

    Vanilla javascript is a completely different skill set than modern react frameworks, its a waste of time

    • austin-cheney 4 days ago

      I strongly disagree after writing JS full time, and as a hobby, for 15 years. Normally when people argue against vanilla JS it’s because they never learned to write original applications (in any language), or if they are in management it’s just more expedient to churn through employees than train them to program.

      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.

      • solardev 3 days ago

        IMO neither one is necessarily better; they're just different levels of abstraction. React lets you think and work in components more easily. Vanilla has a much closer to the metal events and interactivity model.

        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.

    • Woshiwuja 4 days ago

      what kind of take is this, what do you think react was made with? if react isnt used anymore does your skillset translate?

      • ldjkfkdsjnv 3 days ago

        I'm not going to learn assembly to program in c, and especially not as a beginner.

        • austin-cheney 2 days ago

          JavaScript is not assembly. It’s like saying I am not going to learn the rules of driving before driving a car because I’m just a driver, not a lawyer.

          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.

        • Woshiwuja 14 hours ago

          are you never gonna write js inside a react component?

solardev 4 days ago

As a frontend dev, can I ask what your web app is? The stack you choose should depend on the needs of your project. An e-commerce site needs something different than a blog or a game or a map or a dashboard.

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.

Leftium 4 days ago

SvelteKit: https://kit.svelte.dev

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

verdverm 4 days ago

NextJS is a pretty solid choice. It's wildly popular right now (for good reason), is React based (industry dominance), and has a super simple DX (you won't get into webpack/other-tool hell)

There are a number of long tutorials on YouTube... will get a couple of links when I'm back at the computer

  • syndicatedjelly 4 days ago

    I currently use NextJS at work and really don't recommend it for new projects. It's popularity is manufactured, not based on an organic desire by developers to use NextJS. Server actions are a poor/leaky abstraction unless you "ride the rails" of their use cases. The documentation is rather poor once the application's use cases become even moderately complex.

    • verdverm 4 days ago

      I chose NextJS because it's better than the alternatives, having tried them. I would disagree that it's manufactured popularity

      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

      • langcss 4 days ago

        Docs are good but the app router complicated things and had a knock on effect on other docs like auth. Every example was app or pages now so you had lots of examples out there that could no longer work for you. That choice made the documentation a lot harder to use.

    • langcss 4 days ago

      NextJS can be used in different ways, but it is solid as a front-end only set up for building React apps. Create-react-app is deprecated so the choices are fewer. Vite is another choice. Another is esbuild and a bit more set-up work.

    • solardev 4 days ago

      I don't think next is necessary (or even right) for every project, but what do you mean its popularity was manufactured? It wasn't even around until a few years ago and it quickly displaced other frameworks.

kypro 4 days ago

There's a difference between a website which features dynamic content and a site that requires a modern frontend framework like Next.js.

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.

shove 3 days ago

You’re (probably) not going to build a medium complexity web app in less than 2 months as a complete beginner. We’d need to know a lot more about what kind of app to recommend a framework. We’d need to know a lot more about your overall goals to give meaningful advice. For example, is the goal really to build an app in two months, or is the goal to skill up and learn something? Sincerely, a web dev veteran with 30 years experience and the hair loss to prove it

ldjkfkdsjnv 4 days ago

Just learn next.js. Ignore all the other advice here, go straight for the most popular framework. There are a million courses and pieces of content online to learn

nilawafer 4 days ago

The Wasp project is one option to get your project started quickly. https://wasp-lang.dev/

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.

syndicatedjelly 4 days ago

I use Django, HTMX, and TailwindCSS for a side project. The Django framework matches my mental model of web development best. HTMX offers AJAX-based server-side interaction for very, very cheap. And TailwindCSS is a breath of fresh air for styling HTML. The application is hosted on a Digital Ocean server - I'm experimenting with both Docker containers on Ubuntu servers, as well as the DigitalOcean App Platform (comparable to AWS ECS). The app platform is easier to set up, but seems to have some slight performance disadvantages versus a custom Docker instance with an nginx container to route requests.

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

[^2]: https://github.com/gatsbyjs/gatsby/issues/38696