6 ms·

Not on this in particular but in general: I’ve held off on diving into front end because it’s just such a circus. So many options, so many opinions, so much cri

• recursivedoubts 2y ago
  i don't know really what to do about it, but i did write a book on the ideas of hypermedia and how htmx extends them that you can read online for free here: https://hypermedia.systems https://hypermedia.systems i think the ideas of hypermedia are fairly stable and relevant, particularly the concept of a uniform interface, even if htmx is just one implementation of them
• diggan 2y ago
  > then as if that wasn’t enough the whole fkin meta changes monthly. We’re doing react. No actual wasm. Wait no static page. Or maybe htmx. Or vanilla js. Or maybe a mix…well call it remix…it just never ends Who told you to do all those changes? Maybe change who you're listening to, or even better: don't blindly follow what others say/talk about, but listen and think about it thoughtfully instead. Stay on whatever framework/library/platform you want and feel works best for you and your use cases. No one is forcing you to chase the latest trends.
  • jfengel 2y ago
    True, but it does suck to have backed the wrong horse. You framework/library/platform can rot if nobody else is using it. You can't get away with just ignoring it. It helps to pick "boring tech", and hope that what has worked will continue to work. But it's still unpleasant to hear about the X killer every week, when X is your bread and butter.
    • colordrops 2y ago
      I've been ignoring frameworks and focusing on mostly vanilla JS and have worked on some of the most interesting and well paying projects for 15 years now. Haven't been following any of the hype, even Typescript. Was forced to do some React/Typescript at work for the first time last year and it was fine. Was able to get up and running in a few days.
    • rjh29 2y ago
      Hasn't Rails been traditional server with patched with dynamic parts since like 2005? I would pick that
• wvbdmp 2y ago
  Yes, this is exactly why you choose Htmx. So you can focus on web fundamentals. Reason about HTTP and HTML. Sometimes throw in some vanilla javascript when absolutely necessary. Pull in one or two hand-picked zero-dependency libs for things like drag and drop or a nicer date-picker or something.
• Jgrubb 2y ago
  I considered myself a frontend dev 10 years ago, I loved jQuery and Angular 1.x, Sass. I never really caught the Node fever, and it seems like almost everything connected with the JS scene since then has been constant churn and complexity. I moved into infrastructure and data and never looked back. That said htmx is the only remotely intriguing development I've seen in frontend dev in a decade.
  • 91bananas 2y ago
    I too loved jQuery, we've used Vue which is on 3.x now and doesn't really seem like it will change terribly much, in the future. It solves all of the things that in jQuery became really difficult while still feeling like there is still a DOM somewhere in there and we're not all that far removed from jQuery style js. Will agree though, most of the newer frameworks I just don't get.
  • palmfacehn 2y ago
    IE is dead, document.querySelector and friends are sufficient where jQuery was needed. Instead of basking in this achievement, frontend tooling has heaped on bloated build steps with thousands of dependencies. According to the current trends this is the standard way to populate a dynamically updated table or serve a static landing page.
  • confidantlake 2y ago
    Saying you love Angular 1.x while complaining about complexity is an interesting take.
• eddd-ddde 2y ago
  This is so true. Anyone trying to learn frontend as a newbie today has an unreasonably hard task at hands. So much unwarranted complexity. I feel like the backend is just an inherently simpler problem to solve, request in, response out. Largely stateless. Of course there are harder things to do like stateful 2-way connections, but the solutions are mostly concentrated on a couple of technologies. Like yeah we have stuff like graphql, but at the end of the day the principle is the same.
  • shadow28 2y ago
    "Backend" is absolutely not a simpler problem to solve, it's an umbrella term encompassing a wide variety of domains. If you're talking specifically about Web backends, then sure, maybe there's a case to be made there.
  • arvinsim 2y ago
    Which is why it puzzles me that the "frontend devs are not real programmers" meme still exists. Like if it is so easy, then why can't backend devs do it themselves?
    • skydhash 2y ago
      Complex tasks are different from complex tools.
    • backbeginning 2y ago
      We can, management just insists on hiring JS kids to do it a thousands times more complicated. "Just use a sane PHP framework" will get you fired now. Alas. The problem is thinking that all of these things are different domains when they really aren't. The web browser is just a program; its job is to fetch resources and render HTML. If you know how HTTP and HTML/CSS work, you can absolutely make great web applications. But this requires knowledge and expertise, and also maybe not shoehorning an entire application framework into what was designed to be a collection of hyperlinked documents. I suspect this has more to do with money than anything else... the web is dead, long live the web.
• WD-42 2y ago
  Many others including myself have made this observation. I think I've finally formulated why there seems to be such a stark difference between FE and BE/systems cultures. The backend and systems programmers are still writing code in a programming language. So much of FE dev now is stringing together other people's declarative frameworks. When programming is done it's mostly glue. So if you exist in this paradigm you're going to have very strong opinions about whatever framework/tech you are using because it's so hard to operate outside of it. You also gain a vested interest in the survival of whatever you've chosen. This is why I've been slowly trying to make the transition out of web dev, at least FE. I don't want to deal with this crap anymore!
  • wpietri 2y ago
    Ah, this makes a lot of sense to me. Thank you. Interestingly, I think this problem exists in areas of back-end work. I know people who mostly do systems integration, where they're customizing some enterprise behemoth. But since that world is anchored both by the big vendors and by your company's choices of them, it seems saner to me. People may identify as a SAP developer or whatever, but they don't have to advocate for it or have a quasi-religious belief in it.
  • fnordlord 2y ago
    Beware that backend has plenty of those declarative frameworks also... Kubernetes, terraform, most CI environments, CMake. (I'd add SQL but since it's the only one that doesn't drive me crazy, I don't like to think of it as declarative) I don't know FE development enough to speak on it but I agree with your sentiment in general. When I see "declarative," I think "learn by memorization and trial and error rather than reason and intuition."
    • mattgreenrocks 2y ago
      > Beware that backend has plenty of those declarative frameworks also Thankfully, they don't take over your application code, though they eat a considerable amount of brainspace, especially in the collective discourse. Discretion and focus remain key skills in tech these days.
• cageface 2y ago
  User interfaces have different, inherent complexity that backend programming doesn't have. If you look at the Android & iOS native toolkits they've churned at least as much in the same time. Also, and it seems like this has to be pointed out in every one of these threads, the complexity of interfaces we're building on the web now is far greater than what we were building 10 years ago.
  • mrbombastic 2y ago
    Not sure why this is downvoted without comment, many people underestimate the complexity here.
    • kitsune_ 2y ago
      There indeed is complexity, but a lot of the projects that are created to deal with that complexity that gain traction are made by people who don't have much experience in general, or lack exposure to non-frontend programming, so you end up having to deal with a lot of half-baked stuff. It's kind of a lethal cocktail.
    • skydhash 2y ago
      Ui is practically a problem solved (from the technical perspective). The complexity you’re talking about stems from trying to solve the problem with the wrong technology (the DOM). Laying out text for a document is fundamentally different from creating an application interface. An things that are easy to do in any UI toolkit (from GTK to Android) can only be hacked in the DOM. Things like layout constraints (between two components) and lists.
      • cageface 2y ago
        This is completely wrong. The DOM is an implementation detail. All the native toolkits are moving to the same kind of declarative APIs that were pioneered on the web because it's just a lot easier to think of UI as a function of state than it is to get 100 imperative updates in a row right.
  • 2y ago
• shepherdjerred 2y ago
  I just don’t understand this opinion. Backend (and frontend!) can be use stable technology choices if you want to. There are also plenty of bleeding edge libraries/frameworks/languages that come out every week. As an example, how do you want to deploy your backend? VPS, severless, Kubernetes? What database? Which language? Which libraries? There are boring stable answers to the above for backend, just like there are boring stable answers to frontend. Really, I think you’ve just found those boring stable options for the backend and you haven’t done that for the frontend yet. React has been out for more than a decade and it’s the dominant way of building UIs. And there are pros and cons to this with 1000 solutions, but, really, plain React will work for most things you want to do.
  • WD-42 2y ago
    What exactly is "plain React" though? Not sure I've ever seen a project that used only React and nothing else. It would seem you'd need a build step, at the minimum.
    • roywiggins 2y ago
      You only really need a build step to use JSX, which is strictly speaking optional.
      • shepherdjerred 2y ago
        This is true (and part of why I love React/JSX) but in practice nobody writes JSX by hand.
        • cowoder 2y ago
          Isn't it the other way around, nobody writes React by hand they all use JSX?
          • shepherdjerred 2y ago
            You're right :)
• squidsoup 2y ago
  > I’ve held off on diving into front end because it’s just such a circus Its only a circus if you're constantly chasing the new shiny thing. Many of us have been productively building apps in react for nearly a decade without significant changes in tooling.
  • klysm 2y ago
    This is the way
  • andyp-kw 2y ago
    While I don't think react is the best frontend framework, it has become the industry standard and therefore is the most peaceful approach to building apps in 2024.
  • WD-42 2y ago
    React how though? Are you raw-doggin React.CreateElement? Doubt it. So qualify "building apps in react" with whatever bespoke build system, router, state management, etc combination you are actually using. Just because you found yourself a tent inside the circus doesn't mean it's not a circus.
    • arvinsim 2y ago
      How is that any different from using Django in Python? Laravel in PHP land?
      • ywvcbk 2y ago
        Django is quite stable and monolithic. If you used it 10-15 years ago and wanted to build something new it wouldn’t take too much time for you to readjust. With JS you’d be entering a new world and chances are that almost everything you can remember is now an “anti-pattern” and starting on a clean slate might be easier.. Frontend is a mishmash of random components and packages, unless you are 100% sure in advance what are you going to use and and do chances are that you’ll run into with issues with the latest version of package X not working with build system Y due to cryptic incomprehensible reasons unless you make sure to stick with the latest “mainstream” trends (which seem to change ever 1-2 years).
• wg0 2y ago
  You should then look at the circus that is CJS and ESM compatibility [0] [0]. https://sokra.github.io/interop-test/by-tool https://sokra.github.io/interop-test/by-tool
• sensanaty 2y ago
  How people don't get bored of this same exact thread in every single one of these posts is beyond me. But also as someone who does fullstack in a pretty much even 50/50 split, this is such a tired meme by this point seemingly from people who just refuse to actually sit down and think about the FE ecosystem for longer than 3 seconds and end up parroting this same talking point. You could make a similarly dramatic post about the backend world. There you're even fighting which programming language you want to pick. PHP, Ruby, Go, Elixir/Erlang, C#? What about the recent mess with ElasticSearch and Redis? Where and how do you host your backend? Which DB do you use and why? Mongo, anyone? At this point in the FE framework world, you've got 3 very stable players that have been there for a decade. Angular, React and Vue. And sure, they've each gone through some sort of reworks in the past, but nobody's forcing you to pin your dependencies `@latest`, you can pretty much always keep trucking along with whatever version you were on. We've got a huge app still running along on Vue 2 (not even 2.7 which backports the very nice Composition API) and we see no reason to bump versions to 3. I've even had some nightmare scenarios trying to update Rails and Laravel in the past that dwarf any problems I ever encountered in the frontend world. Also, vanilla JS, HTML and CSS still exist and work just fine if you're building some small toy thing, but you'll quickly realize why these frameworks exist in the first place (or you'll do the dumb thing of building your own as some do) if you're doing anything more complex than a brochure website. And the tooling has only gotten simpler if anything with Vite. Want to start a new frontend project? It's literally just `npm create vite@latest`, and you get a nice TUI with which you get to fully customize what you want and don't want. The README even comes with a nice little list of commands for you to run, and hosting can be done literally anywhere where you can deploy the `dist/` folder to, just like the "good" old days. For people who always claim superiority for being the genius backenders they are, they sure seem to be having a lot of trouble with something that they will themselves say any coding monkey coming out of a bootcamp can do with relatively few problems.
  • teqsun 2y ago
    As a fellow full-stack I agree. There's a joke I've told many times in interviews if they ask me to define what a full-stack engineer is, to which I joke "It means I do whatever the senior engineer doesn't want to do, which 99% of the time is front-end". The people I tell it to laugh, because it's funny but also because it's true. On the front-end you're dealing with more customer/users and it's inherently more of a servile role, while it's much easier to be stubborn, eccentric, 'powerful' in the tech-facing backend. I'd also wager there's a certain "tech purity" angle too, given the inherent reverence foisted upon lower level languages and programming fields that is seemingly rife. To play devil's advocate on myself, perhaps it's more that the higher end technical complexity challenges for Front-End aren't commonplace enough. I've had the fortune to work in a field where the level of necessary technical complexity on the front-end part of my job is very high, so ymmv
• kccqzy 2y ago
  My preferred way of writing frontend code is ClojureScript with Reagent. That hasn't changed in eight years since I discovered Reagent eight years ago. Just don't chase fads. Stick to things that you know are working fine.
• draw_down 2y ago
  [dead]
• stephenhuey 2y ago
  I entered the working world in the aftermath of the dotcom bust when JS was a nightmare of footguns (much more than now) and Microsoft literally had zero developers working on IE, the most-used browser in the world, for YEARS. Web dev was therefore stuck in an archaic prison and there was much rejoicing the day Microsoft announced they were once again assigning a team of developers to work on the browser. Fast forward a decade and a lot of terrible things in JS were being rectified at the language level. A dozen years ago, I tried a SPA for the first time and it seemed cool to have a framework (Angular, the first version) to provide more abstractions than jQuery and Backbone. However, the groupthink bandwagony insanity that ensued was ridiculous, and I felt like such an old codger trying to tell the kids to just be grateful that JS was finally working pretty well and move on and build stuff instead for a while instead of spending so much energy remaking the tools every 5 weeks. I'm not trying to be dramatic--I really do feel like companies have no idea how much they overspent on web app development in the past decade versus how much more working code they could've gotten for the money they spent. It literally felt like people were creating extra work, and had no idea how much easier it was than a few years before.