Comment by bambax

Comment by bambax 4 days ago

28 replies

View on Hacker News

The real question is, do we actually need "frameworks"? Pure JS works pretty well, and no JS at all even better.

I recently worked on an SAP project where there was a whole Java layer in front of SAP, and then a huge Angular app on top of it all; but since the point of the application was to manage b2b sales of physical things and it mattered very much whether those things were in stock, almost every screen did a full request to the SAP layer. The need for a thick "rich" client was unclear, and PHP would probably have worked much better.

Hype aside, it seems big organizations are using frameworks as a mean to ensure uniform coding practices and make developers more easily replaceable; but surely there are better ways to achieve that.

brulard 3 days ago

Not every page or app needs framework. But building complex app without one would be very hard and time consuming, and your team would need to come up with ways to solve problems like architecture, code structure, routing, data management, state management, etc. So you would basically reinvent all the wheels on your own cost, and you will have a non standard solution, that would not be compatible with libraries out there (for example UI components) and neither with new devs. Before Angular and React came I was building apps with plain JS with jQuery (not a framework, just a lib) and I would never go back there.

Reply View 0 replies
sparin9 4 days ago

I agree. In a recent small project, I ran an experiment: first, I built the app in React, then in Vue, and finally in vanilla JS. In the end, I stuck with the vanilla JS version because it was significantly smaller, easier to deploy, and much simpler to maintain long-term.

Reply View 0 replies
cruffle_duffle 3 days ago

I worked at a startup where one of the original devs had “strong opinions” on JavaScript frameworks. “It’s all bloat!!! We don’t need that crap”. So consequently all the new engineers had to learn this dude’s codebase, which turned into to be… A framework! Only instead of a documented one that had plenty of support it was an unholy mess that required extra time to build all the stuff missing from the it’s-not-a-bloated-framework-but-pure-JavaScript-framework.

Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.

Guess what happened to development productivity and product quality? They went up dramatically.

Reply View 0 replies
sensanaty 3 days ago

As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.

The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.

I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?

Reply View 2 replies
  • OscarDC 3 days ago

    > but worse in every conceivable way

    I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?

    I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.

    I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.

    Reply View 0 replies
  • bambax 3 days ago

    > I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways

    If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.

    Reply View 0 replies
j-krieger 4 days ago

> The real question is, do we actually need "frameworks"?

Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.

Reply View 21 replies
  • onion2k 3 days ago

    The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.

    We have one. It's called "the browser". The discussion is whether or not we need a higher level API than that. If we do, maybe that should also be a part of the browser's API.

    Reply View 9 replies
    • arvinsim 3 days ago

      It would be easier if "the browser" is just one target.

      As it is, there multiple browsers supporting different levels of features.

      That's the whole reason why frameworks are made in the first place dating back to jQuery.

      Reply View 4 replies
      • GuB-42 3 days ago

        The days of IE6 which justified jQuery are long gone.

        All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.

        Reply View 3 replies
    • troupo 3 days ago

      > The discussion is whether or not we need a higher level API than that.

      Try using DOM APIs to build anything remotely complex or interactive. There's a reason everyone who only uses browser APIs ends up just dumping strings into the DOM via innerHtml.

      Reply View 2 replies
      • skydhash 3 days ago

        > Try using DOM APIs to build anything remotely complex or interactive.

        I think the core question is: Are we building something complex or interactive. I don't see the need for React or other frameworks unless you're storing a lot of mutable states client-side. But more often than not, all I see is replicating the database through API endpoints.

        Reply View 1 reply
        • j-krieger 3 days ago

          Any user facing website that is not a portfolio site is interactive. The days where the web is display-only are long past.

          Reply View 0 replies
    • j-krieger 3 days ago

      „The browser“ doesn‘t exist. So no, we don‘t have one.

      Reply View 0 replies
  • TickleSteve 4 days ago

    Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other.

    More abstraction != easier to use.

    Reply View 10 replies
    • tipiirai 4 days ago

      Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.

      Reply View 7 replies
      • troupo 3 days ago

        > HTML, JS, and CSS deliver a clean separation of concerns

        There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.

        > For apps,

        For apps you need actual app-like things where your separation of concerns looks like the right image here: https://x.com/simonswiss/status/1664736786671869952

        Reply View 6 replies
    • j-krieger 3 days ago

      Your comment shows that you don‘t have a lot of experience in that matter. „Pure JS“ (there is no such thing) has perhaps the tiniest standard library of anything out there. The rest is browser vendor code, of which a lot depends on browsers and versions. Hell, they didn‘t even get date parsing right.

      Reply View 1 reply
      • TickleSteve 2 days ago

        "Pure" JS exists as a concept, not a project.

        Having a tiny standard library is also a good thing, not a bad one... I'm not saying its an ideal API but in general, smaller==better (within reason).

        Reply View 0 replies