[–] [S] 1 point 1 year ago (2 children)

If you don’t know the basics, and can’t build a functional site with just HTML/CSS/JavaScript, all of the frameworks will be a nightmare. You should really learn those first

I maybe should've lead with that in my post, but I do know HTML/CSS/JS on a basic level. Again, as I thought I laid out in my post and as I have said in other comments, I'm not really here to ask for advice on learning these things. I'm asking for advice on a stack choice.


never use what’s “hip” on the frontend

Some other people mentioned Svelte. Would you say that's too "hip"? What other options are there than React, if we exclude all the hip stuff?

  • source
  • parent
  • context
  • [–] 8 points 1 year ago (3 children)

    But you (almost certainly) started using those backend frameworks after you had experience. You learned the basics first, and then incorporated frameworks when you got to larger projects.

    I came here to say the same thing as the original reply in this thread, albeit with slightly different justification:

    If you don't know the basics, and can't build a functional site with just HTML/CSS/JavaScript, all of the frameworks will be a nightmare. You should really learn those first, even if it means building a practice site, or completely rebuilding your frontend when you decide to use a framework.

    The frameworks can make your life easier, but there's a learning curve, and a huge cognitive burden especially when you are just starting. You'll fight them more than work with them at the start.


    That all said, never use what's "hip" on the frontend. JS frameworks typically have the lifespan of a house fly. React is one of very, very few that has remained popular, and continued to get updates for a long time (at least in JS framework terms). It's a solid choice with a huge community, good docs, good tooling, etc. There may be other valid choices, but seriously - avoid anything new and flashy, because that usually just means its deficiencies haven't been found yet, and as soon as they are, there will be a new framework.

  • source
  • parent
  • context
  • [–] 3 points 1 year ago* (last edited 1 year ago) (2 children)

    Devographics has been running these popular "State of X" surveys (State of JS, State of CSS, etc) that have been useful for tracking trends in frontend framework usage:
    https://www.devographics.com/
    https://stateofjs.com/en-US
    https://stateofcss.com/en-US
    https://stateofhtml.com/en-US
    https://stateofreact.com/en-US

    The StackOverflow survey is also somewhat useful:
    https://survey.stackoverflow.co/2025

  • source
  • [–] 2 points 1 year ago* (2 children)

    We use Leptos at work, which is similar to Dioxus and Yew.

    Main downsides:

    • You can't really pull in component libraries, where someone has implemented more complex UI elements before. You will need to code more of these yourself.
    • Because it's mostly delivered as a big WebAssembly blob, it's only really suitable for Single-Page-Application-style webpages (SPAs).

    Main upsides:

    • You get to use similar syntax and libraries as you do in the backend. Frontend code still has a very different paradigm, so it's not completely free to jump between the two, but the hurdle is definitely lower.
    • You can share code between frontend and backend. In particular, this means it is enforced at compile-time that frontend and backend share the same API.
    • Some of the common code patterns benefit quite a bit from Rust's design.
      For example, for conditionally displaying different UI elements, rather than JavaScript's multi-line ternaries, you can use Rust's normal if-else expressions as well as match-blocks.
      And when you make a request to the backend, you get back a Result. You can pass that up into the display code. If it contains an Ok value, you display the rendered component with the data inside. If it contains an Err, you render the error where the component would normally be.
  • source
  • parent
  • context
  • [–] 1 point 1 year ago

    I'm not making fun of anyone. I know how stressful situations like that are, but you need to chill because being an abrasive asshole isn't how you get people to help you.

    When I looked for work with front end, everything is asking for framework experience, when I have raw html/js/css experience. So what you’re saying isn’t helpful. I’m pointing that out and asking for practical advice, you’re being a dick for making fun of my situation.

    I wasn't trying to be helpful to you. You are not OP. OP didn't ask "what should I learn to land a job". I never claimed that knowing basic js/css/html was going to help you get a job. Anybody can do that, it's webdev 101. I was pointing out that those basic skills are all you need to write good front-end software, and that most front-end frameworks are over-engineered and unnecessary.

    But to answer your question: learn what employers are looking for. Duh. You looked at job postings and found that they were asking for framework experience, so you already have your answer. If you land a web dev job, it's going to be to work on an existing legacy (and often shitty) codebase, not to write new software. The trendy/popular stuff is what's trendy/popular, so learn that to increase your chances.

    But most importantly, fix your attitude. It doesn't matter how smart you are if nobody wants to work with you.

  • source
  • parent
  • context
  • [–] 2 points 1 year ago* (last edited 1 year ago) (2 children)

    Since you mentioned Rust is your backend, take a gander at Leptos. I'll admit that i'm not quite versed in it yet but what I'm doing is learning React and building my apps on React while also learning Leptos.

    Leotos takes heavily after React but isn't actually like React. I know that doesn't make much since so you will have to read the docs but it does seem to be a more efficient FE.

    And to be clear, I absolutely hold my nose while working with React as that was actually my last choice of the big 4 front ends but since my end goal is Leptos and documentation and information online is widespread, it's something I can live with

    EDIT:

    I am mistaken. Leptos takes after AwesomeJS, not react.

    EDIT 2

    I meant Solid.js

  • source
  • parent
  • context
  • [–] 3 points 1 year ago (1 child)

    and you don’t have to be a dick about it.

    how am I the one being a dick about it? You're the one that's making fun of people trying to improve their situation in life, and I'm the dick?

    When I looked for work with front end, everything is asking for framework experience, when I have raw html/js/css experience. So what you're saying isn't helpful. I'm pointing that out and asking for practical advice, you're being a dick for making fun of my situation.

  • source
  • parent
  • context
  • [–] 2 points 1 year ago (2 children)

    Chill out. If you want advice on how to find a job, post a thread asking for help. This thread is asking about javascript frameworks, not how to help you get hired. A lot of people are struggling right now, and you don't have to be a dick about it.

  • source
  • parent
  • context
  • [–] 1 point 1 year ago*

    I used to feel the same. I apply ATOMIC design principles in my folder architecture. I start by defining the most basic reusable type that I can export. I then create more complex and specific types by extending and combining those base level types. Breaking everything up makes it manageable. Plus it leaves a trail to follow to figure out what parts of code do. It also will throw an error if a variable or import isn't being used.

  • source
  • parent
  • context
  • [–] 5 points 1 year ago

    As a frontend dev working my way to the backend, I would probably say a stack of React/Vue, Typescript, and SASS. These are industry standards (or at least, as standard as you can get with such a fractured ecosystem). And/or: learning the ins and outs of an ecommerce platform for theme development, like Shopify or BigCommerce. In terms of frameworks, I prefer Vue because it's a little higher level than React and translated well from vanilla JS.

  • source
  • parent
  • context
  • [–] 3 points 1 year ago

    What's "complicated stuff"? Your business logic will probably be complicated regardless of what you use. A framework will just add a few more layers of complexity and introduce a (usually fragile) build process.

    Idk what you're trying to build, but from this:

    I “just” want to build a pretty standard, responsive, modern-looking UI. Ideally without too much boilerplate,

    It doesn't sound like you need a framework. Want responsive? Learn how to use flexbox. Want a "modern" look? Learn design, or find some CSS templates to start from.

    If you're trying to make a SPA (which a lot of beginners/insane people seem to think is a good default, which it definitely is not), then a framework might make it easier, or it might not. It depends on what you're building. You may be able to use HTMX with a light sprinkling of JavaScript, or may need a full-blown batteries-included framework.

    So. What are you building?

  • source
  • parent
  • context
  • [–] [S] 9 points 1 year ago (5 children)

    why not go for native browser and HTML/CSS/JavaScript?

    I guess because you end up rewriting a lot of stuff manually, rather than going for tried-and-true solutions that work out of the box? I mean isn't that the same as every framework, regardless if we're talking JS or frontend or backend or whatever. I mean I use a framework in the backend as well, I'm not about to roll my own routing system and manually listening to a socket and everything.

    I totally get the sentiment of KISS, but if you know that your site will not be super simple and will need interactivity and the possibility of complex workflows, isn't the raw HTML/CSS/JS kinda limiting? That's the impression I'm getting from what I've read online.

  • source
  • parent
  • context
  • [–] [S] 3 points 1 year ago (3 children)

    It just doesn't seem like best practice to do raw JS/CSS/HTML from what I read online? I get that for maybe small sites where you just need mostly static pages, that might be fine, but if you want any complexity and flexibility, isn't raw JS/CSS/HTML sort of limiting? I.e. you'd end up doing lots of complicated stuff that you'd build yourself instead of using a framework.

  • source
  • parent
  • context
  • view more: ‹ prev next ›