13
Condor
6y

I honestly don't get the idea behind JavaScript frameworks. Like, if JavaScript on its own is really so bad that it's only usable for front-end devs with a framework.. why has nobody considered committing back their changes into JavaScript itself? Makes life easier for everyone.

Also, regarding the framework.. as far as I understand it's a bunch of functions that you load in, right? But do you really need all of those, to the point where the unused ones are justifiable? And wouldn't it make more sense to write them yourself as you need them? I mean that's at least the idea of functions in languages like Bash or C or whatever.

What's the point of frameworks?

Comments
  • 6
    For example if we look at Vue and we don't talk about the framework but about the results. I think our team is like 20% - 30% faster and it's way more fun than plain jQuery.
  • 9
    whats the point?
    the point is reducing the amount of code a dev needs to write as the framework will come prebuilt to handle alot of functionality.

    the downside, you introduce a hell of alot of code, that just sits there unused.
  • 1
    Well people are actually committing back via TC39.
  • 1
    @Ovyerus im yet to see a JS dev actually shake their tree...
  • 6
    This. I've seen a bunch of SO questions answered "here's how to do it in jQuery" when the person asked for JavaScript. I haven't used any frameworks because I can do the same thing in plain JavaScript, and I'm not on a time limit for my own personal projects, so I have pretty much nothing to gain from being able to work just a bit faster (plus then I'd have to take the time to learn the syntaxes for the frameworks).

    They just seem kinda dumb to me, and bloated, due to the fact that I'd personally use very little of that the frameworks have to offer and have ALL THAT EXTRA SHIT BEING LOADIED FOR NO GOD DAMN REASON (tree shaking could be done, but I'm kinda paranoid and think I might need some of the shit that gets removed for later when it's something COMPLETELY unrelated), but I GUESS someone could make the same argument for functions and libraries in C/C++.

    It's just a weird situation to me. I don't like frameworks. They're not my thing.
  • 5
    The whole point of a framework is to save weeks (maybe even months) of time creating that logic for yourself.

    Every framework (Like React/Vue etc.) is simply putting another abstraction layer on top of pure Javascript, which CAN make your life easier but it doesn't have to.
  • 3
    I made a desktop-like web app that behaves like the desktop, with windows and controls, etc.. using Backbonejs.

    I think it is easier than writing normal JS when writing complex UI, because things are more organized.

    But that was 6 years ago, I havent done any Js for a while but now when I look at it, completely lost..

    Why the fuck so many JS frameworks???

    Why do you need to use a framework to build just a login form, or other static pages??

    PLEASE STOP
  • 5
    The same argument can be made for using a language like C/Java/python instead of just writing Asembly code.
    Writing more high-level code is easier, faster and in a lot of cases also safer: abstraction often prevents you from fucking up. Of course, there is no free lunch in computer science and abstraction often leads to performance loss.
    Therefore, a programmer needs to compare the value of his own time, the value of having a readable program and the value of a "safe" program, against the value of the program's performance in terms of memory and time usage.
  • 2
    I feel that JS frameworks are used for things they are not needed for like 95% of the time. I would say that plain vanilla JS is okay most of the time. For almost all websites I made I needed just tens of lines of it.

    And the design of those frameworks is really fucked up. They try to be OOP-like, but then they come with bullshit like "single store of truth" instead of components holding their own data.
  • 3
    Ease of use.. Regarding the frameworks and not contributing to core JS.

    JS is actually really great as a dynamic language, even better when statically typed(TS).

    Some libraries like date-fns and lodash contains the fastest + most standardised way to do most things.

    Other than that, people are lazy. I imagine people not configuring privacy on social media - using jquery and all the libraries for everything.

    Personally, I create a new file for each function I create and reuse them - if it doesn't already exist in a lib I'm using ofc.

    Lastly, treeshaking. This eliminates most dead/unused code.
  • 2
    Build a simple app with Javascript where you show a list of items in html.

    Then add some logic to show/hide the list.

    By then you'll know why JS frameworks are necessary.

    Time and money is two essential factors in any organization.

    A framework is simply a tool.
  • 3
    @colaguy This could be done with literally one line of plain js. Get button, add click handler to it and set hidden class for ul.
  • 3
    It sounds like you don't need a framework at all. It surely helps if you have tons of dynamic things and fancy responsiveness - but if you don't need any of this you can just cut out all the fluff. If you do need the functionality though it will save you tons of time.
  • 2
    @irene I'm with you on this one.
  • 1
    @hitzoR yes but that doesnt scale at all. It gets messy pretty fast.
    Every language uses a framework/library for building bigger projects.
    It doesnt really make sense for small projects to use vue/react but at the same time it doesnt hurt either. Those things are very fast and small.
  • 2
    @musician but that little todo list wouldn’t need to scale 🀷‍♂️ it’s a ul list and a button, but sure add a framework to handle your onclick event and show/hide toggle.

    That almost feels like the mentality behind Jquery, But now we have bigger frameworks with shinier toys.

    Oh and before you pull the “why reinvent the wheel” line, not everyone needs monster truck wheels on a mini coupe.
  • 0
    @C0D4 many parts of jquery are now in the browser. Same will happen with something like react. And it doesnt need to scale long until you feel the pain. Just add projects and tags and youd be faster with a framework.

    And even if it doesnt need to scale. Why not choose your favorite workflow? If thats vanillajs for you thats fine. But these days I use typescript and react for pretty much everything. And your monster truck analogy doesnt really makes sense here tbh. In the end it all gets compiled down to 'normal' js. The user doesnt care how you got there ;)
  • 0
    @musician regarding compiling.. I'm not a web dev, but I do selectively whitelist JavaScript resources using NoScript. Very often do I see jquery.com in the list of requested JavaScript resources. If it's being transpiled down to regular JS, why do all these sites still need to load in the framework itself from jquery.com? Doesn't make sense to me.

    Also, scalability aside, I really don't think that a simple ul that's hidden and shown on demand needs any framework. Heck, I recall that that can even be done without any JavaScript at all!

    Just my 2 cents as someone that's out of the loop when it comes to web development, but I think that people are going way too crazy over these frameworks. It would make sense if it were to be transpiled in a manner that discards everything that isn't used from the framework. Or even better, if the framework is consulted when something is needed and only that particular needed function is copied into the code base.

    I have a dream...
  • 0
    @musician also, some users do care how the website is built. Seeing the performance of the average web page nowadays, I can't help but feel disappointed at modern web development with the status quo of just throwing frameworks at it (that are loaded on every website request!) on one hand and demanding from users to throw more parts at it on the other hand.

    I'd really like to make such web devs make their website scale up to thousands of tabs without slowing down on average hardware - and without the ability to throw more parts at it - since 100+ tabs aren't all that uncommon anymore nowadays. Or maybe it's just me. Or to have another extreme, make the website perform well enough that it could even be displayed on the hypothetical Tamagotchi or a toaster or whatever. Low-performance devices essentially. I'd dare to say that at least 80% of the internet can't even come close to this. But of course the obvious solution is more parts and the user doesn't care anyway, right?
  • 1
    @Condor Projects like Material-UI and next.js do come close to some of your wishes.

    It seems that as the web-tech matures, more and more people agree that RFC, treeshaking and not bundling everything is the way to go.

    Use lighthouse to check for PWA, perf, a11y, seo, and best practices. People not following this, aren't following simple standards - which would be more than 80% of the interπŸ•Έ.

    Something along the lines of:
    "With great power comes great responsibility".

    DApps and Web 3.0 is surely going to stir things even more.
  • 1
    @Condor Mostly, I'd like to see the practice of creating a pure html/css version of one's websites - just in case JS magically & suddenly stopped working.. But only because I think it makes sense to serve a lot fewer bytes the the people who wishes it.

    My thoughts are with the browsers. They have to change standards and secure settings, just because people keep doing something wrong.

    Nowadays, the browsers run an (I'm not sure) isolated V8 instance in every tab and have to make sure laws are abided and security the best it can be. In the meanwhile, 5 people every day make a post on how CORS and JWT suck, complain about the browser and use a library to stuff a request header. Most don't even know about CSP.

    The problem is not JS developers; it's people who think they're developers after 2 months of hello world and a year of copy pasting. These people are ruining it for others. It trendy and lucrative to become a dev so why not?
  • 0
    @hitzoR show me the code if it is that simple. Easy talk.
  • 4
    @colaguy document.getElementById('el').addEventListener('click', () => document.getElementById('ul').style.property.visibility = 'hidden' )
  • 2
    @irene I'm not saying it's pretty. But JS is very functional and this is one line. It can even .click() in the end if we wanted it to, then change color to blue.

    I really wanted to declare some variables and keep things to themselves 😁 But that wasn't the challenge.. The real challenge was writing it on mobile lol
  • 1
    @irene Yup! My first thought too. Then a variable for the the button and ul using that wrapper.
  • 1
    @irene I'm not following πŸ™ƒ
  • 1
    @irene Ah yes, that's a good function. I might even use that sometime!
  • 2
    @Kandelborg you should check purescript, elm or ghcjs.
  • 1
    @karasube thanks! I knew about elm but not the others, I hadn't even thought about haskell to JS πŸ˜„
  • 1
    @Kandelborg First of all, this is not a single line. Thats a pretty intenstive line to read.

    Secondly, so for every component within the application, lets say you create a dashboard with customer details, number of members and stats about paid membership you'll have to create an event listener, keep track of the element tags and also write CSS in JavaScript? That doesn't scale.

    Complexity increases radically with JavaScript. A framework is a tool box that handles most of this for you, so you can focus on building features.

    If this was Angular, you create a component, a boolean value "show", and an ngif directive to show/hide the component with an button event.

    You end with something like this within the HTML

    <app-customer-list *ngIf="show"></app-customer-list>

    Its easy to read, easy to work with and easy to collaborate with.
  • 2
    @colaguy I can do the same thing in vanilla JS, easy.

    That is in fact one line. Copy it into something else, there are only spaces.

    Im currently trying building a framework which is a collection of tools, I get your points but.. dude, the thing you're talking about is a really simple use case. When you need async, i18n, SSR, critical path css, and dynamic SEO; on top of all your dynamic and layout & UI components.. That's when it becomes nice to have abstractions.

    The funny thing is that the API I'm using in my messy proof-of-concept is the exact same ALL frameworks & abstractions have to use in order to accomplish these things. It's the standard anyways, there are other (probably valid) ways to go about it.

    I'd like to try and build this in Web Components, so you can see what I'm talking about when I say that it's the same API and compare the frameworks with my thing on Codepen or where ever. But it might take a few days before I get started - would you like to see it?
  • 3
    People do commit back to the presumed core (ECMA). Though it takes a while for all browsers to correctly implement its new features. Firefox mostly has had a head start, and mostly provides good polyfills for backwards compatibility.

    JS has a great way to expand upon itself.
    Frameworks are just a way to code with the least amount of resistance while doing it.
  • 2
    I do find a lot of use cases for these frameworks.

    I don't deal with simple applications at work. I deal with enterprise grade(read large as fuck) web applications and decoupling the entire ordeal into multiple parts, including(as a first and foremost actually) front end is wonderfull.

    Javascript frameworks exist because managing ui state in large apps is complex. Ridiculously complex, frameworks are battle tested for it. Tools like Vue and React make this a simple task vs doing it in vanilla JS.

    If you can do it in Vanilla JS then shit fam by all means. But I will gather that such apps are not as big.
  • 1
    @colaguy Just admit that your example was really bad.

    Just wrap the button with ul into single div and give it some class and work with it in JS. And also have class for hidden state, so you only toggle the class at the parent div on button click. Easy enough and it can scale however you want easily.

    There definitelly are use-cases for such frameworks, but for most websites they are useless and they just bloat the website with unnecesarry kilobytes, thus hurting performance.
  • 2
  • 2
    @Kandelborg Yes, that would be nice.

    I know the example itself is easy, but the code produced is not that declarative. And I'm also aware of that most of these frameworks use this underlying architecture along with custom elements in which Angular, React++ uses.

    The goal of a framework is to simplify productivity so that you don't need to think of these things.

    Honestly, I would rather want to use VanillaJS than any other frameworks, but the reality is that in order to get work done in these days, you need something that is quick and powerful.

    In other words - get shit done.
  • 1
    You are thinking of libraries, not frameworks.

    A library is reusable code, like jquery.
    Like you said, any library can be merged into the language itself, and it foes happen from time to time.
    But generally those changed fit into the language "culture" and "ideals".
    Loke the foreach or map filters added to ecma script

    A framework is a way to use the language, generally to save time and generally comes with a few libraries.ñdpecific to help in that specific framework.
    This make no sense to merge because there are many ways to implement the dame idea, like Vue and Angular
Add Comment