19 ms·

You probably don't need a JavaScript framework

• zer00eyz 10y ago
  I have been avoiding JS for years (not out of hate, just the job) and every time I dabble in the node/js framework ecosystem I end up turning away frustrated. I have a few small personal projects that I haven't started due to lack of desire in building the front end I want, after reading this I'm going to give them a shot and see how far I can go with out all the goodies!
  • vskarine 10y ago
    I was in the same boat, tried reading tutorials for Angluar/Ember/Backbone/etc and wanted to throw up because of all the complexity and prior web experience/knowledge that they expect you to know. But then tried Meteor and everything there made a lot of sense to me.
    • quackware 10y ago
      Meteor is a great stepping stone to the more complicated JavaScript ecosystem of node/react/angular/webpack etc. I was a huge fan of it when I first started web development, but all its limitations caused me to switch over to using the above mentioned technologies. I highly recommend it to any beginner to web dev!
• WalterSear 10y ago
  You don't need one, but if you don't eventually adopt one, you'll end up writing one.
  • takno 10y ago
    Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller
    • Touche 10y ago
      In reality JavaScript size means very little when a single image might be 500k.
      • Svenskunganka 10y ago
        Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.
        • openasocket 10y ago
          Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms
          • Walkman 10y ago
            100ms is noticeable. It's already slow if you reach that.
            • WalterSear 10y ago
              It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.
        • deleted 10y ago
          [deleted]
      • tomc1985 10y ago
        Did you not see that headline about how the average page now is the size of a Doom install?
  • CloudYeller 10y ago
    Yep. If you're getting paid to maintain even 10-20 UI's, frameworks help preserve your sanity. At least you'll know what to expect from the boilerplate and what are the general capabilities of dozens of apps, just by learning 1 framework. And the more popular the framework, the easier it is to hire new developers to work on your apps.
  • tomc1985 10y ago
    I guess that's why we have so many! bah dum bum chh
  • formula_ninguna 10y ago
    That's funny. But at least you might not need the whole framework, just a part of it. And that part you'll end up writing youself. Why not? You'll understand javascript better. Most developers aren't able to write a single line without a framework.
  • Silhouette 10y ago
    So people keep telling me, but I've been building this stuff for a couple of decades now, including maintaining certain projects for at least as long as most of the modern JS frameworks have existed, and I'm still waiting. The only way these generalisations about everything becoming a framework hold is if you conveniently define framework to mean something like "having any sort of systematic or uniform software architecture".
• teen 10y ago
  The cycle continues... No framework -> Backbone -> Angular -> React -> No framework We should be back towards using a simple MVC skeleton by the end of 2016.
  • esaym 10y ago
    NO. MVC is a framework. Just use CGI.
  • trgn 10y ago
    I always kind of liked the simplicity of Dojo-stores, and its observable QueryResults. Simple CRUD, to-the-point, tiny footprint, ... Put a view on it, BOOM, app. (fan of modern frameworks btw, just saying vanilla MVC is kewl too)
• natrius 10y ago
  I don't use React for speed. I use it because manipulating the DOM to make it reflect the application state is hard. It's something a program should do for me. React is that program.
  • MrGando 10y ago
    A program?
    • geoffpado 10y ago
      I, too, did a double-take at the use of the word, but I looked it up, and it seems to be a valid usage. Various dictionaries define program merely as a "set of instructions," so, yeah, a library or framework counts as a program just as much as a separate process.
      • MrGando 10y ago
        I just felt a program is such a general and high-level way to describe software... basically anything that computes... wikipedia: " collection of instructions that performs a specific task when executed by a computer " We can do better than describing a JS Framework/Library, than calling it a program I guess.
        • natrius 10y ago
          I used "program" because that's what we call things that automate things for us, and that's the appropriate frame for thinking about React: it automates things you could've done by hand, but why do that?
  • deadowl 10y ago
    I don't get a lot of opportunities to play around with JS frameworks, which is odd because I hobby-code a lot in JS. I imagine the top reasons to use frameworks are cross-browser compatibility and support for scalability in the domain of your work. Unfortunately sometimes people use them because the only tool they have is a hammer, so everything is a nail. Vanilla DOM manipulation has become much easier in the past few years. I have played around with some new DOM features in my own time, but for anything public-facing I'm going to use a library that allows for cross-browser compatibility, and typically that's a combination of jQuery, polyfills, etc.
• statictype 10y ago
  React doesn't exist to handle the massive amounts of data that facebook has. React exists to make complex UIs easier to build and maintain. Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code. That the author kind of misses this point makes me pay less attention to the rest of the post.
  • timr 10y ago
    "That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding.
    • thatswrong0 10y ago
      That doesn't address the fact that, to some of us, React simplifies creating, testing, and maintaining complex UI due to its functional nature. React is simple to me, and that's why I like using it.
      • timr 10y ago
        "React is simple to me, and that's why I like using it." Horses for courses. The author is merely making the argument that you don't need react, and the GP comment didn't bother to read the argument before responding.
        • thatswrong0 10y ago
          If you're going to tell me I don't need to use a library, it has to be way more convincing than, "Look how easy data binding it with native APIs! And it's not slow!" This is a weak argument in my opinion, and does nothing to address how removing abstractions will make my life easier.
• sshbio 10y ago
  I like this way to do, preventing complexity. There may still be things that can not be achieved JavaScript, but aside from those cases, I would even add "you (probably) don't need JavaScript".
• bricss 10y ago
  Absolutely agree. Also wanna notice that is React is the only one V from the MVC. At least it's weight now more then Angular. Backbone can even do everything and twice time more then React can do.
• CameronBanga 10y ago
  Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.
  • philfreo 10y ago
    No, if you look in the footer you'll see it says "Public file shared from Slack", which I think just means someone posted this document using Slack
    • mortenjorck 10y ago
      Weird, so Slack effectively has a stealth Medium competitor now?
  • hu_me 10y ago
    yes this what I was curious about as well. Interesting the simplicity of creating snippets with markdown makes it easy to use for posts as well sharing code snippets ala gists
  • jammons 10y ago
    Slack's blog is at slack.engineering. It's called Several People Are Coding. This is not from Slack, as noted by philfreo.
• apeace 10y ago
  contenteditable and MutationObserver? What about <input> and onchange?
• tomc1985 10y ago
  This! This times a million times!!~! Seriously. The javascript world is INSANE. All these frameworks and few truly need them... node.js package management is a mess... yet how many of these coders will take the time to learn real ES5? It really isn't that hard of a language. I feel like calling oneself a "javascript" expert practically requires knowledge of a framework or too. This is saddening, because Javascript itself is a rich language with a ridiculously fast runtime, yet everyone wants to work with a framework when a head full of sound theory and experience will do :/
  • fizixer 10y ago
    As a javascript-noob, not even jquery? I've heard jquery solved so many headaches.
    • 8note 10y ago
      it solved differences between older browsers. now, they tend to follow standards, and that melding is less needed
    • lstamour 10y ago
      It solved problems of cross-browser compatibility back when Netscape was still a thing, before Chrome existed, when major releases of browsers (IE) radically changed functionality between releases, and if I recall, we had Phoenix/Firefox as the most cutting-edge browser of the era. This is what browser market share looked like back then: http://arstechnica.com/uncategorized/2007/02/8908/ http://arstechnica.com/uncategorized/2007/02/8908/ When jQuery launched, it appeared on Del.icio.us and Digg, for context of its era: https://jquery.org/history/ https://jquery.org/history/
    • niuzeta 10y ago
      The major criticism of jquery comes from its "overhead" which comes from wrapping a lot of functionalities onto relatively(at the time of its onset) large file[1]. While they were legitimate(internet was slow) at the time, at its cost jquery worked as a go-to-solution for browser incompatibility. This was a major issue which jquery solved magnificently. And frankly, a significant portion of jquery usages are a very limited set of functionalities: selection, class manipulation, some visible on/off, AJAX and promises. A lot of those don't necessarily need jquery[2]. Some hard-core guys go so far as to separately download only modules[3] which works. Honestly, I wouldn't mind calling a significant portion of jquery to be "pure javascript" as it lets me not worry about browser compatibilities and pleasant stuff that should have been part of standard library. ES6 is supposedly fix most of the complaints, but whether browsers will support them or not is a different question. [1] https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size has a nice tabular info on how large jquery file sizes were. [2] http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ is a widely cited source. [3] https://github.com/jquery/jquery/tree/master/src https://github.com/jquery/jquery/tree/master/src, go nuts.
• sorpaas 10y ago
  Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. Now let's add Javascript to the list.
  • Dr_tldr 10y ago
    The good news is that with V8 and ES2015, we now have a formalized, (fairly) fast, and tolerably buggy implementation of Half of Common Lisp. Oh yeah, and it runs natively on devices owned by literally billions of people.
• TheCoelacanth 10y ago
  You don't need a JavaScript framework. You just need a bunch of stuff that you can't use because it isn't supported in IE9. > HTTP/2 is widely supported by web browsers already. At the time of writing, 70.15% of visitors has support for the updated protocol. Oh yay, so only another 5-10 years until I can use it.
• darawk 10y ago
  The point of React isn't its performance (though that is nice). The point of React is the simplicity and composability of functional components. You can create this on your own of course (and I have), but the solution of "just use the DOM" ignores an enormous amount of progress that React made with component design, not performance.
  • takno 10y ago
    The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against
    • gjolund 10y ago
      That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using. Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline ... and more, in less code that just `npm install -g ember-cli` `ember new my-app` And then having a common app structure with thousands of other people that can provide help and insight. You people really are kidding yourselves. I feel bad for whoever is paying your salaries.
      • takno 10y ago
        I'm paying my salary. In my last performance review I rated myself outstanding and gave myself a substantial bonus. Frankly my employer is a little bit irritated by your arrogant comments about his hiring policies You list a lot of things that a framework gives you, but they vary between the small (routers are easy if you can ignore #) and the things which you probably don't need but have been convinced you want by your framework
        • gjolund 10y ago
          Hilarious. You are the only person working on the project and you are patting yourself on the back for writing "maintainable" code. Bring 50 more people into the project and then lets talk.
• vhiremath4 10y ago
  "Another example is the Fetch API"... That API has very limited cross-browser support. One of the largest reasons web frameworks exist is to bridge the gaps between browser incompatibilities/offering legacy support. I don't know if this person has even really scaled and deployed a web application that must work across several browsers - especially older browser versions. I always wonder that whenever I see people bashing frameworks. Like the author said, start with asking why the framework was created. Just make sure you come up with the right answer to that question next time.
  • zxcvcxz 10y ago
    Yeah I find it hard to believe that the people who go on about how convoluted web development is actually get paid to do web development. 1) Where are all the people hiring web devs who don't know a single library or framework? 2) Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?
    • takno 10y ago
      Do Google even really use angular? I know none of their core products use it. As to Facebook, their website is painfully slow, seems like it's not a model of the right way to do stuff
      • vhiremath4 10y ago
        Google Developer Console, Doubleclick Platform, Parts of Chromecast including the Chrome Extension, YouTube for PS3 Plenty more. You'll notice that a lot of what is written in Angular by Google tends to be their newer platforms/platforms being re-written while Angular was out/coming out. Older products like GMail are extremely complex and transitioning to a saner, more streamlined way to scale those applications usually stems from necessity, but rest assured they use their own framework (take a look at all the gnarly tags and events bound in GMail). I don't personally use Angular.
      • zxcvcxz 10y ago
        Well fb is fast for me, so is cloudflare, airbnb, Codecademy, Coursera, Docker, Dropbox, IGN, IMDB, Imgur, Instagram, Khan Academy, Netflix, okcupid, and a whole bunch of other websites that use react. Plus I like being employed so knowing frameworks and libraries is a must.
• edejong 10y ago
  I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came Grunt, NPM, Angular, some CSS framework, unit testing. Much more, but I forgot the names of all of it, you know the drill. I have to admit, looking at each of these components independently, one could hardly argue with their usefulness, but together they buried a relatively simple and elegant messaging system in tons and tons of incoherent, unmaintained, inextensible and incompatible (with websockets at the time) stuff. The line-count went up, of course, easily to 15000 lines. I couldn't understand my own designs anymore, since they got spread out over dozens different files. Refactoring became almost impossible. The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well and we lost each other, making a babylonian tower, far away from our original goals. The quality of your solution is not in your libraries, or your frameworks, instead it's in being fluent bottom-up before grabbing a library or two. You'll see you often don't even need them. (edit: small typos, edit2: please explain down-votes, I'd like to know and be happy to answer any questions)
  • lazaroclapp 10y ago
    Also, your TCB now includes Angular, a bunch of fairly unstable libraries and the servers that provide all the NPM package managing infrastructure. I mean, your TCB already included the OS, the OS update manager and the browser, but still...
  • mwfunk 10y ago
    I didn't downvote you (and I thought it was a thoughtful post), but I could totally see somebody interpreting "web-boy" as some sort of weird emasculating epithet a la "fanboi". On the Internet it's super easy to take offense at things that weren't intended to offend, in fact some people seem to thrive on it.
    • mrlatinos 10y ago
• intrasight 10y ago
  Back in the late 90s a bunch of us create an architecture we named AJAX. Now in 2016 a bunch of us are still using AJAX to build web apps that work just fine and are probably faster than these "frameworks".
• educar 10y ago
  The main point of frameworks/libraries is to set coding guidelines for the team. It's fine to go off and invent your own framework but this causes maintenance issues for the people coming in next. Most likely, there are no docs or examples for the code you just wrote (especially the framework bits). When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. So it's best to pick one so that the code is easier to maintain in the long run. Besides, the focus should be on the app and not the framework/library and writing your own is just distraction.
  • coldtea 10y ago
    >When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. Not in my experience. I've seen frameworks come and go like that over the span of 15 years and teams rewriting for the new "hotness". So, one year they do Angular, then Angular 2 comes out, invalidating a lot of their code/experience, then they get to React, then they're told that they should structure it like Flux, then Redux comes along, and who knows what in 2 years. Just imaging that merely 5 years ago Backbone was the preferred edge JS framework. In fact wasn't even that at that point -- it was only just released 5 years ago...
    • jimbobimbo 10y ago
      Release of a new framework doesn't render all existing code based on an older framework useless. Nobody mandates moving all existing Angular 1 codebases to Angular 2.
      • coldtea 10y ago
        Mandate moving them, no. But eventually they'll bit rot, and all the new features, and community support will move to 2 -- and you're stuck with the worst of both worlds: a framework with stuff you don't need AND with few left to maintain it.
• carsongross 10y ago
  Most people probably don't need to write much app-land javascript at all to have reasonable UX: http://intercoolerjs.org http://intercoolerjs.org Bonus: you get HATEOAS without knowing what HATEOAS means.
• mortenjorck 10y ago
  This might be the post that convinces me to write a companion piece on why you probably don't need a CSS framework, either. Browser renderers have come so far since Bootstrap's peak: Flexbox has all but obviated its primary value proposition, and when CSS grids make it out of RFC, using Bootstrap for layout will be like using Backbone to do rollover styling.
  • takno 10y ago
    I would read that article positively
  • CuriouslyC 10y ago
    Sorry, I have to disagree strongly. For starters, bootstrap provides consistent and attractive default styles. Additionally, if you implement your styles as a bootstrap theme, third party components that are written with bootstrap in mind will (usually) automatically have the correct look & feel. Flexbox is definitely a lot nicer than the Bootstrap column system though.
  • chipsy 10y ago
    Plus one for my interest. I became checked out of front-end framework developments when it started to become a big build process with a lot of dependencies, and if that can be reversed, I'd be happy to work with the DOM again.
• blue_dinner 10y ago
  If you don't use one and have a complex app, it will eventually turn into a spaghetti mess of callbacks. You will end up writing your own framework that hasn't been battle tested on thousands of sites. For simple apps, it's probably not needed. The issue also is that you app could be really simple now, but have features added to it regularly making it complex.
• bitwize 10y ago
  If you're looking for work and the hiring manager fishes for names of JavaScript frameworks you've used, you need a JavaScript framework.
• gjolund 10y ago
  I'm really glad I don't have to work with people who think like this. You don't NEED a framework, just like you could theoretically build a car from scratch. If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. Frameworks do exactly what they say, provide a common framework for your team to work off of while they build a complex application. I feel like most of the FUD around JS frameworks comes from simple people building simple apps and wondering why everything needs to be so complicated. Frameworks enforce structure, which becomes more and more important as your app grows in complexity. Frankly it would be great for me if this train of though picked up steam, plenty of contract work from companies who can't maintain their "homegrown" frameworks anymore.
  • coldtea 10y ago
    >If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. That's the very mentality that gave us J2EE crapfest and poisoned JS. The idea that a complex app requires a kitchen sink approach and framework-itis...
    • gjolund 10y ago
      Complexity requires structure in order to be maintainable. Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. Both are signs of inexperience.
      • coldtea 10y ago
        >Complexity requires structure in order to be maintainable. Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job. It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design. You know that Joe Armstrong quote about OOP? "the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" Well, it's the same with frameworks. You wanted a router, a template engine, and a few more pieces, but you go that, a banana, the entire jungle, and a mustachioed dictator telling you how to do things. >If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. It's as if we've forgotten the existence of libraries and APIs, of which there are like 200.000 in npm, and 50 of them are also really good. >Both are signs of inexperience. Some of the most experienced programmers, of 20+ years of career of successful projects, don't trust frameworks (and surely neither the "framework du jour" of JS, nor the "framework that ate Cincinnati" approach of J2EE of yore).
• AlwaysBCoding 10y ago
  You probably don't need Redux* but React is awesome
• deleted 10y ago
  [deleted]
• Nitramp 10y ago
  One thing many people underestimate is how easy it is to run into XSS, XSRF, XSSI when not using a framework, in particular XSS when using native DOM APIs ("location.href = ..." - pwned. "e.innerHTML = ..." - pwned. "a.href = ..." - pwned. "*.src = ..." - pwned.). You might not need a framework, but you'll need a structured approach to avoid those problems, and frameworks can help a lot with security.
  • BinaryIdiot 10y ago
    Unless your framework bridges the backend and frontend you're not going to just magically get rid of XSS vectors. Also regardless of what framework you are using you still have access to location.href, e.innerHTML, etc. I'm not really sure what you're trying to convey here but it's lost on me because, framework or not, all of these things still exist. Hell angular simply wraps location as do some other frameworks.
    • Sacho 10y ago
      I thought his point was clear. A framework provides all those things, free of charge. Instead of using location.href or e.innerHTML you're invited to use framework.html(), etc. It's possible you would take care of escaping output on your own, but the point he was trying to convey is that you are likely to take shortcuts and not do all those things.
      • MaulingMonkey 10y ago
        framework.html() would presumably have the same problems as e.innerHTML (as you're probably aware). The examples that come to mind are replacing something like... e.innerHTML = "<td class=\"" + type + ">" + value + "</td>" with: d3.select(e).append("td").attr("class", type).text(value) or: $(e).append("<td></td>").addClass(type).text(value)
  • Achshar 10y ago
    None of those are "pwned" if you know what you're doing. Idiot proofing is a real feature I grant you but it's not something you can blame the native DOM APIs for.
• pfooti 10y ago
  So, I've been working with rich text editors in particular recently, and I can tell you one thing: contenteditable is a gigantic pain in the rear. It's uneven across platforms what it transforms user intent into (control-B: do you get a <b> or a <strong>?), it handles paste events sloppily, and marking inner fragments as not contenteditable (say an image embed, atmention or some other block) is weird, especially if that item is the last thing in the list. Contenteditable is so annoying that the first thing most rich text editors seem to do is make their own selection state manager, because the native range implementation in the DOM is crap. Medium in particular pretty loudly got rid of it entirely, and that's the direction most modern web-based rich text editors are going. So. The best thing to do here is find some kind of framework that helps you map from user intent into mutating a data model, and a separate way to translate that data model into the DOM. This sounds like a framework to me, and it especially sounds like one if you want it to work on lots of platforms. Similarly, sure: I don't need a framework to do DOM manipulation. But I've been using angular (1.x) for a few years now, and I can say: it makes life a lot easier. If I don't have to debug lines of javascript looking for where different elements get injected into the DOM, I'm happy. I can just look at the template file for the html code I'm editing and see where classes get programatically changed based on state, not because I'm deep inside some MutationObserver, but because I can read an ng-class directive. Easy pie. I sure don't need a framework. I could also program in ones and zeroes. Speaking as someone who's been doing web stuff since the 90s, where the first framework I ever wrote was a bunch of DIY C libraries to make writing cgi-scripts easier, I can say with all honesty: using a framework makes life easier. Sure, it's annoying to learn, and sometimes the opinions of the framework are different from your opinions. That's why I use angular instead of ember (because I'm not a rails person, for the most part). Take your pick, learn it well, and it will make your life easier. And if you're that worried about the weight of your library, stop loading so many hero images uncompressed. (I will grant edge cases where library size is a big deal, but it's more of a premature optimization thing in most places, especially now that tree shaking is starting to make its way back into our build tooling).
• calsy 10y ago
  Is it possible for someone to point me in the direction of a nice JS project template that does not use a framework? I would still like all the core elements of a decent JS project such as package manager, bundler, templating BUT without the overkill of a new framework. A project template that allows you to simply write HTML, CSS and JS modules in an organised fashion. A reference to a Github repo or online doc would be awesome. With so much JS news and information these days its really hard to find any info without the words react or angular or whatever. Appreciate any help from you knowledgable folks.
• deleted 10y ago
  [deleted]
• frik 10y ago
  I wrote about that about 4 years ago, often called vanilla JS. Back then everyone on StackOverflow was still completely bought into the JQuery mission. I often see it when people don't fully understand something, they choose a framework.
• kup0 10y ago
  I don't think frameworks and tools are the problem. I have dealt with the same frustrations about these huge tool-chains but I've always seen it all boil down to one key point: the problem is not the tools- it is not choosing the right tools for the project at hand. Then you get websites and apps that really bloat up because of the overkill or poor choices. There's the whole side issue of progressive enhancement and/or making a non-JS version of a site, but I feel like those ideals are now dead- whether it's due to it being unfeasible, unaffordable, or something else.
  • samtho 10y ago
    Its ROI. For any new company starting off, they will quickly realize that all non-js agents are either bots or very low-powered machines. With many new companies, who base their entire existence on the web and customers' ability to access it, these two groups are not their target audience so why bother making a JS free, static site when you don't need those customers' business? On the flip side, government sites are (or at least should be) developed with a high degree of accessibility in mind due to laws that typically prevent anything less. Their reach is much higher and their audience is potentially every citizen in their jurisdiction.
• _alexander_ 10y ago
  Ok, we don't need frameworks, however what should we use in order to build complex UI applications? Own solutions? And know imagine that in every project you build your own skeleton and architecture...
  • jqm 10y ago
    I think the point is for complex UI applications (or a team with interchangeable members) you would use a framework. But for less complex applications you might very well not. Enjoyed this article. I like JavaScript, I use it almost daily, I'd like to learn React or Angular but just haven't had the real need. For the amount of JavaScript in the apps I build there just doesn't seem to be the payoff. I did venture into npm. What a nightmare of goop and time wasting. Although there were some cool utilities the amount of time setting up and dealing with in most cases didn't really pay out. Don't manipulate the DOM. Why not? Works fine for what I do. Maintainability. Maybe. But well organized code is well organized. If there were a lot more of it this probably becomes a valid point but JS doesn't do everything in my apps. It does the things JS was originally designed to do. I figure when the dust settles I'll probably dive into a framework. But right now stored database procedures, database triggers, a light Flask/Bottle layer and judicious use of well organized jQuery/ native JS works really well and doesn't have a bunch of unneeded parts. Then again I'm still using Slackware. I like things simple. The less abstraction and "helpfulness" between me and what I'm trying to get done the better. Simple, powerful, modifiable tools without a lot of glitz and overhead are my preference. I mistrust black boxes and complexity. Maybe React is the kind of tool that could be useful... don't know. Might look into at some point when I feel it's reached puberty.
• scope 10y ago
  - shows an example using mutation observer API and fails to mention it only works on IE 11+ - follows the widely accepted format of "rant about some popular framework/library/language by mimicking a tiny portion of it" - uses shock factor to get the reader's attention > React, Virtual DOM, Webpack, TypeScript, JSX… HOLD ON! Let’s pause for a second here and think. YES, you don't always need a framework/library BUT if you want to build something maintainable & scalable, it's better to opt for battle tested approaches (which is especially true when it comes to the web, having browser quirks)
• dwg 10y ago
  To begin, React isn't a framework. It’s a tool. Would you compare a table saw to a workshop? That doesn’t make sense and neither does comparing React to a framework—especially if you’re saying you don’t need one. Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is merely a part of how React works. People don't buy cars to get an engine. They buy cars to get around places. People don't use React to get a virtual DOM engine. People use React to make building and maintaining apps easier. Let’s say you decide you’re smarter than everyone who worked on React or some other library, and you can build your app without them. Great, if you’re building a small app this is probably just fine. Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change. Using libraries, or even frameworks, is how you leverage the collective intelligence of dozen, hundreds, or even thousands of very smart minds (a few of whom might even be smarter than you). Especially proven ones with many successful projects using them. You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time. The rest of the article mentions other points which don’t seem particularly related to framework decisions to me at all, so I’ll let them be.
  • BinaryIdiot 10y ago
    > To begin, React isn't a framework. The way I look at it: - If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool. - If you use a library that replaces or changes your style of work then it is a framework. React is a framework in my opinion. It can be used as a library but it's almost never used that way; most people incorporate JSX and much of the virtual dom into their workflow. But this is pedantic. I feel comfortable I could make an argument for almost any JavaScript library being a framework as well as not being a framework. > Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change. While correct I cannot disagree with you enough. If you write clean, as-simple-as-possible code with clear separations of concerns it's dead easy to maintain and not necessarily "full of bugs". It really just boils down to how well a developer can architect an application to determine if their own framework is going to be a huge bottle neck / issue or a breeze. I've been through both :) > You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time. I'm not a fan of this sentiment. If it makes the most sense (and it doesn't always) I try to avoid using frameworks but I would hardly call myself a cowboy (though perhaps I will going forward, ha). The DOM API, as this article shows, provides quite a bit of functionality that many popular frameworks / libraries provide and as long as you don't need to target old browsers you're fine here. Yes, angular and react do a lot for you but you can still write effective web applications without them with minimal "reinventing of the wheel". Just because someone provides a way to do X in a framework doesn't mean it's not easy to still do X without a framework. Many times the bulk of the framework's capabilities are supporting its own, specialized workflow that isn't always necessary.
• evan_ 10y ago
  This looks like a great blueprint to spend way too much time writing an app that is un-maintainable and only works in a few browsers.
• Svenskunganka 10y ago
  I apologize for not adressing your concerns with the post earlier, I've just added an update to the bottom of the post with some replies to some comments I've read. Please keep in mind that my intent is not to mock you or your framework of choice. My goal with this post is to try to inspire you to try building something with the native DOM and Web API and see for yourself. Some may enjoy it, others may not. And if you feel comfortable with your current way of building your web applications with a framework, that's completely fine. Also, please keep in mind that I cannot address every use-case in a single post. As much as I'd like to, that's going to take way too much time.
  • Michielvv 10y ago
    Although I agree with the idea that Frameworks can easily make your life worse instead of better. Especially at the time the Framework moves forward to a version that is not at all compatible with what you are doing. However, in your update you are suggesting to use Object.observe as a simple alternative to React. I looked it up and https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/observe https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... says it is deprecated and even removed in some browsers. Using API's that are not widely supported and then not relying on a well supported framework to abstract them, seems to me an even worse maintenance nightmare than sticking with a Framework.
• petecox 10y ago
  vanilla-js.com
  • jqm 10y ago
    That's pretty funny.
• bikamonki 10y ago
  This eternal argument of js framework/non-framework reminds me of them old days of static html when Dreamweaver will just munch a PSD file and spit out working HTML + Images + CSS. Some of us hated it b/c the output was bloated, super hard to read/maintain, etc. So, some of us just went ahead and coded from scratch. I guess the preference has to do with a need to 'understand' what's going on. Tools like React or frameworks like Angular are just the modern Dreamweavers: don't mind the inner-workings, just follow the rules and get the desired output. If I can recommend a js framework so flexible it feels like a non-framework I'd say go and learn Backbone.js It's like a flat green Lego table, no assumptions, just structure.
  • ChrisDutrow 10y ago
    I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess. Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to. This fits my personal preferences, I prefer simple, verbose code. I also tend to prefer lower-level to high level. For example, I don't like ORMs. For me, it is easier to explicitly express how I want the data to be indexed and move in and out of a database as opposed to have an ORM manage it for me... because if it doesn't do it right, its very difficult for me to learn how to get the ORM to do what I want it to do. I also prefer more keystrokes and fewer "things to have to know about" to fewer keystrokes with many things going on behind the scenes that I cannot see. I think I may be in the minority in this respect? I understand that there may be better frameworks now, but I feel I need to commit to something and stick with it, I think the cost of re-writing things all the time is too high. I think its faster in the long run to use an old framework that's 50% slower than switch to a better framework every two years. For reference, this is the main project I use backbone on: https://demo.enterprisejazz.com/ https://demo.enterprisejazz.com/
    • bikamonki 10y ago
      >I think the cost of re-writing things all the time is too high. Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date. I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined towards vue.js or mithril.js. I checked your demo, in case you have not done so already here are 3 tweaks I've done to make Backbone run faster: - Select el already on DOM for a view's el instead of render/append. This is a huge performance improvement. - For big collections use plain JS array instead of Backbone native collection. You'll trade some methods for performance, but such methods can be re-implemented with Underscore. - Ditch the router if you need dynamic routes. Here's an experiment of a classic listings app. After selecting a city, 5000 random listings are loaded at once into a JS array, after that I use Underscore for search/sort. Records in this example come from a static demo file. A red warning pops up with total download time and total processing time (lapse from download ready to array populated and ready for use). When I used Backbone collection processing time would be between 5-9 seconds (depends on processor speed). http://edwardspooner.com/items/index.html http://edwardspooner.com/items/index.html
• proc0 10y ago
  npm install --save-dev vanilla-js-loader
• pier25 10y ago
  Yeah why not? Let's reinvent the wheel every fucking time. I'm sure your clients and your family will love that.
• hmsync 10y ago
  In some special environment, such as Electron (Atom shell), that can ignore the cross-browser problem, writing application using native Web API and DOM API and ES6 is elegant and effective.
• dmix 10y ago
  One of the big ones is build tools. You don't need Gulp/Grunt/etc for 90% of the stuff I've seen it used for. They could be replaced with a Makefile plus a bunch of standard unix utilities. You shouldn't have to install 90 libraries in order to build/install/run your program.
• zwily 10y ago
  I wrote dbmon at Instructure (first with jquery, then in ember, then in react, where it has been for a couple years) to give us a birds eye view of a bunch of databases. It's been kind of surreal to watch it blow up into what it has.
• hawkice 10y ago
  For those who read the comment about Object.observe: Don't use that. It's being removed from everywhere it exists, and pulled from the standards recommendation. Just have a set(state) function that calls your callback instead, it's like three lines of code.
• joesmo 10y ago
  While we're at it, let's just write everything in spaghetti ASP because you don't need a [insert programming language here] framework.
• codeisawesome 10y ago
  I don't agree with the sum of it's parts, but I like some of the... components... in this article.
• namuol 10y ago
  React is popular because it re-frames the meat and potatoes of frontend dev as a simple input -> output problem. VDOM merely helps make this approach performant at scale - it has little to do with why people actually use React. Abusing MutationObserver to get "easy" 2-way data binding is precisely the sort of antipattern that React & Friends would have discouraged.
• jrochkind1 10y ago
  I really wish I didn't need a javascript framework, but I find this essay unpersuasive. He doens't seem to deal with the same kinds of problems I do. But I like that he's making the argument, and trying to pull out the parts where the web API has gotten a lot better. It's approaching maybe. I really do wish. If we're lucky, maybe we can come up with something lighter weight (conceptually, and in terms of build tools needed, as much as in byte size) that is closer to the built-in browser API. I definitely don't feel like I can do what I need in a sane way with nothing but the browser API though.
• known 10y ago
  +1 http://www.xul.fr/ajax-frameworks.html http://www.xul.fr/ajax-frameworks.html
• matchagaucho 10y ago
  Brilliant. I get burned by cross browser issues when going without frameworks. Would love to work exclusively with Web API.
• CommanderData 10y ago
  You 'probably' don't need one but 'should' use one to save yourself countless hours re-inventing the wheel that frameworks solve. The best thing is to try and use minimal frameworks and libraries and justify every single one - Which I'm sure most devs already do. jQuery is still rather justifiable. Yes, you can replace functions with JavaScript today but you'll end up with similar looking functions. I recently added Transit to animate using CSS3, the alternative would be to write each animation effect I use in CSS3 down to the duration! If I need to change the ease I spend 5x the time doing so - From a devs perspective no, just no.
• dandare 10y ago
  If the author thinks TypeScript is a framework there is no need to waste time reading the article.
• mhd 10y ago
  It's interesting that by comparison, a lot of these modern JS frameworks are positively tiny. No comparison to e.g. Cocoa, QT, MFC, Rails, Spring and all the things usually called the f-word. React itself barely qualifies for "library", more like "helper functions". So, having started outside the web world, I really don't understand the hullabaloo. It reminds me of a certain point in Windows development, when shareware etc. was a thing, but download speeds, RAM and disk space were still low. Creating smaller programs was a thing for some developers, both for distribution and an alleged "bare metal" feel (whether they were that much better than e.g. a big package including all of Tcl/Tk is another matter). Programming Win32 with assembly. The ATL. Compressed executables. People recomming a new weird command-line oriented operating system made by some crazy Finn. Both ATL and Win32ASM bring in yet another feature: Programming in my favorite, possibly new idiom. Another reason for creating these mini-frameworks in the JS world. All glued together by slapdash micro-libs and utilities, that might be there one day, might be gone tomorrow. I might finally be getting old and cranky, but I actually feel that some bigger frameworks wouldn't hurt. Some kind of standard library included, given that this won't come out of standards or the global community. More opinions. A set of standard components/widgets, not just three score methods of displaying them and two score of connecting them to a score of different backends. Go all in: If you really want to just use the web browser as a delivery system for all kinds of GUIs, give me a GUI framework. I think that strangely enough ExtJS used to have more competition there... Either that, or make more use out of the old-fashioned tenets of HTML, do more with text and links and stick to progressive enhancement. The middle ground of shiny but tiny GUIs that seems to be the rule for modern "SPAs" is neither fish nor flesh. (And I don't think that "isomorphic apps" is the answer here, either.)
• etatoby 10y ago
  The article's author does not seem to understand what React is for and why people use it. The article is full of sentences like: it's true React is fast, but basic Javascript is even faster. Duh? It's true React is quite small, but if you don't use it, your site will be even smaller. No sh*t Sherlock? React was invented to simplify the program structure of medium-to-large applications by replicating the successful data flow of the Web itself: namely, the state of the application is in one place only (the URL in the Web, the state object in React); HTML is generated from that state using one set of reusable and composable templates; and crucially, user events only affect the state, not the HTML itself. Personally, I'm going back to basic HTML + progressive enhancement, for a variety of reasons. But React is the sanest of all the client-side architectures I've seen so far, including bare-bones web api.
  • dualogy 10y ago
    "for a variety of reasons"---care to share in brief?
• callesgg 10y ago
  I might not need a framework but that does not mean that there is no value to it. I don't really need a smartphone, but it is quite useful.
• nbevans 10y ago
  Whilst predictably this HN thread has turned into a bit of a flame war I would like to point out the article certainly made one indisputable point. That HTTP/2 is going to change how modern web apps are written all over again. So then we'll all need another new framework.
• hellofunk 10y ago
  >Virtual DOM is efficient and has good performance, but native DOM interaction is insanely fast and your users will not notice any difference. As soon as I saw this, I knew there were limits to this author's knowledge on the subject. React was a requirement for the low-latency UI we built for a major commercial app and without it (or a similar library) the user experience we shot for would have been impossible.
  • jasonwelk 10y ago
    I agree, but it also possible to use these frameworks without much understanding of the DOM and I think anyone serious about web development should have a good inside grasp on how the DOM works before using a library.
  • moron4hire 10y ago
    React Virtual DOM is faster than rebuilding the entire DOM from scratch, yes. But making edits to DOM manually will be faster with native browser functions and no VDOM diffing overhead.
• __s 10y ago
  openEtG doesn't even use jQuery, it's been alright. Only library it uses is pixijs, & a slimmed down version at that. Originally everything went through canvas/pixijs but over time only a few views aren't DOM http://etg.dek.im http://etg.dek.im for site http://github.com/serprex/openEtG http://github.com/serprex/openEtG for source It does a lot of dynamic content generation, which dom.js has proved sufficient for
• sod 10y ago
  A) There are people that love frameworks. B) There are the ones that don't. The type A ones just gave up to the complexity and bury it with foreign frameworks. The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known. But here is the big "but". Would programmer type B want to work with a 2 year old project from another type B programmer? And there you have your answer why there is such a hugh appretiation for frameworks. Its easier to throw 10 programmers of type A onto the same project.
  • seanwilson 10y ago
    > The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known. You're forgetting type C that don't know anything about existing frameworks so decide to reinvent the wheel by writing an unmaintainable mess of spaghetti code... I'm guessing type Bs are very rare. Once you've seen enough untestable jQuery soup you'll learn to appreciate frameworks.
    • wccrawford 10y ago
      I would go so far as to say that to a new programmer on the team, Type B and Type C programmers' code looks much the same. I'm a type B. I've written entire systems from scratch that fit me like a glove. I could fix any problem in no time flat, and it was very stable. But when it came time to have other people work on it, it didn't fit them like a glove. It barely made any sense to them at all. They eventually got up to speed, but they were never as productive in it as they would have been in a decent framework-based system. I was actually quite happy when they decided to rewrite the whole thing... And then it turned out I left about a year later, so it was a good thing they did.
  • andremendes 10y ago
    So frameworks matters because they define a set of development practices to get interoperability between project members, to allow different people (in terms of development practices) to do work together. Seems like it's mainly a matter of balance between collaborative work easiness and individual work flow quality. There's also the work avoided by not having to test code on different environments but after reading this thread looks like it's a minor advantage of frameworks.
• keeganmccallum 10y ago
  I think the flame war that has erupted has a pretty simple explanation: some people forget the state of javascript just a few years ago. I am currently in the process of moving my team away from the monolithic dojo framework towards using more of the vanilla web standards, but I think dojo was a great choice at the time. The pains of cross-browser support, terrible vanilla APIs that were completely different in IE8 vs the rest of the web, etc. made frameworks "the way to go" in the past, and that's set us off in the direction we are going today of immediately reaching for one. Articles like this one are great in that they are helping to educate people on the power and ease of use that the modern web has to offer, but I can 100% see why people are going to skeptical for a while longer when it comes to using only vanilla javascript.
• seanwilson 10y ago
  So instead of using an established framework the post is suggesting possibly using these things? MutationObserver for UI updates + Fetch API for networking + History API and a custom router for routing + CSS for animations + HTTP/2 instead of Webpack + npm for building + JSPM for package management + multiple polyfills for browser support for all this Besides not having a name and a dedicated site, how is the above any different from using a framework? Once you've worked out how to get all these things to play nice together, are you really saving any time from just using an established framework that's done the work for you in the first place (i.e. they'll use some of this stuff under the hood already)? Just because you're leaning on native features instead of library features doesn't make it any different from using a framework. At least with an existing framework you know it's battle tested, has good documentation, has an active community and is easier to maintain for new programmers on the team.
• moron4hire 10y ago
  I'm getting so tired of this conversation. Use a framework. Don't use a framework. Just build something already. Who cares how you made it? I'm so sick of getting asked "what framework did you use?" I'm so sick of seeing people pitch their projects as "ProjectName: built with FrameworkX and LibraryY", with zero indication what the project does. If the most interesting part of the project to you is the tools with which it's built, you're not an entrepreneur, you're a fetishist.
• nogridbag 10y ago
  I came across this thread late, but the comments here have been quite fascinating to read. I think as developers we're always seeing patterns in our code and trying to figure out the best way to solve them and that's how many frameworks emerge. Before React's emergence I would occasionally come across UIs which were incredibly complex due to events firing left and right (and events firing in response to those events, etc) and in an attempt to reduce cognitive load I would try and re-structure the code with a uni-directional flow that would re-render the entire UI when any state changes with varying degrees of success (since applying this pattern on top of another framework is pretty fragile). So React was immediately appealing to me. And Flux and later redux was the evolution of that idea taken to another level. As for the article itself I was a bit confused by it as from the clarifications at the bottom it makes the assumption that the reader is building a trivial application with minimal UI state. There are thousands of boring companies like mine not named Youtube or Facebook building complex web applications and it wasn't until I read the clarification at the bottom that I realized the whole article wasn't aimed at me.
• inspiraller 10y ago
  I agree. I enjoy developing the quickest route from a-z. I can write javascript. I know the dom, that its quicker to update one large dom container than it is to update many smaller elements. I have worked with and understand ajax, that rewriting a dom node before unbinding any events creates browser memory leaks causing it to eventually crash. I would not know these things if i had coded with the prescribed framework. If the argument for using them is to have team coding standards then have team coding standards. The framework creates its own problems.