11 ms·

Frameworkless JavaScript

278 points by pauljonas 13y ago

nkuttler 13y ago
How disappointing, the article is called "Frameworkless JavaScript", but the author uses jQuery for the application. Yeah, I get it, jQuery a library... File size seems like the biggest concern, but really, how important is that on a dynamic page that needs to load exactly once? And using a CDN it might already be cached anyway. That being said, I also like clean, minimal JS code.
- manuletroll 13y ago
  I think the focus on file size comes from the fact that moot is supposed to be embedded on sites, much like Disqus.
sync 13y ago
Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.
- hadem 13y ago
  Whereas had they decided to use Backbone or AngularJS I wouldn't have to invest tons of effort...? Regardless of framework (or lack there of), effort will be needed for those utilizing the API.
- mattgreenrocks 13y ago
  This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?
  - aaronem 13y ago
    Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...
    - mattgreenrocks 13y ago
      Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
      - aaronem 13y ago
        Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.
        Zelphyr 13y ago
        You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
        scarecrowbob 13y ago
        "And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together." Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything? I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
- Chris_Newton 13y ago
  Congratulations, you've just built your own ad hoc JS Framework. We used to call that part of software development “design”, and learning basic design skills and becoming familiar with the common strategies and techniques were prerequisites for being a useful developer. Perhaps losing that baseline is an unfortunate side effect of having readily available black box code to do many common jobs in the Internet age and being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.
  - SkyMarshal 13y ago
    In my experience, using a framework and learning design aren't mutually exclusive. Learning a framework often requires studying its source code and grokking how it works, there's simply no better documentation. Granted that may not be quite at the level of designing your own complete framework from scratch, but imho it's the happiest middle ground between personal skill development and standing on the shoulders of giants that FOSS has enabled.
- mrottenkolber 13y ago
  I don't use any 3rd party code for my current work as of now. So yes I have built my own "toolkit". Maybe a vector rendering library wil be required at some point, but I started off on bare bones to see how far you get. It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.
- codingdave 13y ago
  Every non-trivial app will add enough custom code to a framework that new developers have a learning curve.
- coldtea 13y ago
  >Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running. That's the framework party line. Not necesarilly true. For one, somebody not familiar with, say, Angular would still have to get to know Angular (a huge task in itself) and then your application code too. Why not just have them understand the application code only? Since it's tailored to your application it also omits needless features and workarounds for framework issues.
  - jdewald 13y ago
    I've never seen a non-trivial application that is "application code only". Most frameworks weren't built out of thin air, but because of real application needs. Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you (which now you have to support even though it's not core to what your application does, but is just a support layer). Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.
    - coldtea 13y ago
      >Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. There are trivial apps (no need of framework, small enough), medium apps (can use a framework maybe) and serious non-trivial large apps, apps you bet your company on. The latter are often better to NOT base into a framework. If they do anything novel, and they want to do, they'd hit framework limits. The framework will impose its logic upon your code, whether it fits or not, and you'll have all the baggage of assorted layers it offers you'll feel obliged to use. >Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you That's totally orthogonal. That you don't use a framework, doesn't mean you can handpick any of the popular template language libs, database mapper libs etc. Instead of being constrained by the set the framework authors chose. That is: libs, instead of frameworks. >Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit. That's not ironic in the slightest though. It reinforces what I said: since those teams evaluated whats available and they didn't fit their needs and rolled their one to solve their particular problems they way they want to solve them, what makes third companies think those "hand-rolled" frameworks are a good fit for THEIR needs? The message to take away, when a company rolls her own framework is not "frameworks are good, I should use theirs", but "they saw it fit to roll their own stuff. Perhaps I should too". After all, if you're a startup your competitive advantage is your code. You shouldn't constrain it to fit anything external. Now, if you are a consultant or web designer delivering cookie cutter projects for a company, or an enterprise developer doing some CRUD, by all means use a framework. Especially if you aren't doing anything very creative or original in the first place.
- twerquie 13y ago
  What if, instead of needing a framework, we just wrote tiny modules of functionality and composed them into an application? This is how the nodejs guys are doing this via npm and I must say, it's staggering. The core node "framework" has a tiny API, and the heart of it is simply require().
  - frik 13y ago
    Yes exactly! Modules like in Node.js or libraries as in PHP are a lot more flexible and IMHO better than frameworks. I coded single page HTML5 apps in JS and Node.js/PHP and avoided any frameworks. A few helper functions are enough and I got a codebase that is easy to read, refactore and the overall code size is small and the execution is fast.
  - ianstormtaylor 13y ago
    Exactly. If this kind of thing seems like your cup of tea check out component[1]. [1]: https://github.com/component/component https://github.com/component/component
  - ben_mcmahen 13y ago
    This, entirely. You can effectively construct your own framework by combining other pre-established routers, models, and views (plus whatever other modules you might want). You still get many of the benefits of using frameworks (testing, docs), but it's much more flexible and has the potential to be leaner. You still need to establish best practices and a relatively consistent application design, but these are things you'd want to do anyway... even if using Backbone, or whatevs.
- rfnslyr 13y ago
  It's SO much effort to spend a weekend studying a code base and playing with it. Get over yourself.
- jonny_eh 13y ago
  On top of that, their new knowledge of said framework is not transferrable to their next job. If someone works on a popular framework, it makes it easier to get the next job.
onion2k 13y ago
Suggesting that frameworks are too complicated because they "add tens of redundant methods, adding complexity for the end user" is ridiculous. The number of methods in something doesn't always add to the complexity - in a lot of cases a framework vastly reduces the difficulty of using something by abstracting away the hard stuff so the user doesn't need to worry about it. That's pretty much the point of a framework. Further though, using an established framework improves things through the "many eyes" principle - if tens of thousands of people have used a piece of code, chances are it's going to be pretty damn bulletproof and it'll have a swathe of documentation backing it up (as official docs, blog posts, StackOverflow questions, etc). No startup can even dream of competing with that. Specifically in the case of moot.it, perhaps as a thing that's dropped into a website to provide a discussion forum having tight code is a bonus, but if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.
- nailer 13y ago
  I think the 'redundancy' here is more just unnecessary complexity. Eg, the primary value of Angular is binding DOM -> data. As a developer, I want to specify: - The template for the DOM - The data That's all. I don't care about $scope.$apply, a second module system (even if it's better) or anything else I have to read about. Ractive.JS (The Guardian's framework) does this. It's just mustache templates you bind to data, and when the data changes, the relevant parts of the DOM do. The 'how to' fits in a tweet, it's backed by a major media company and the lib is 32 kilobytes.
  - nawitus 13y ago
    Ractive.JS doesn't need $scope.$apply because it uses it's own model system. AngularJS doesn't use it's own model system, the model is a plain old JavaScript object. The author of 'Frameworkless JavaScript' criticizes the Ember way of using a "complex model system". $scope.$apply exist because of limitations in JavaScript. Apparently this will be fixed in ES6, so ES6-version of AngularJS theoretically won't need $scope.$apply. Ractive.JS's data-binding looks similar to Ember.js, which also has it's own model system to learn (learning complex frameworks was criticized in the article).
jbrooksuk 13y ago
This has been discussed before. https://news.ycombinator.com/item?id=6653024 https://news.ycombinator.com/item?id=6653024 A massive discussion between Backbone.js developer and the developer of Riot.js kicked off. It's an interesting read that's for sure. You can find the library here https://github.com/moot/riotjs https://github.com/moot/riotjs
- nkuttler 13y ago
  Oh, so they wrote their own framework but the site doesn't use a framework.. now I get it.
  - danneu 13y ago
    The blogpost explains why they didn't use an off-the-shelf framework. (Spoiler: "We wanted control.") That they can generalize their homebrew abstractions into a new framework only shows that they didn't use an off-the-shelf framework.
binarymax 13y ago
It is refreshing to see this post. As someone who has tried, and not really taken to, all three of those frameworks I sympathize. Stick with what works for you. Shipping code on your own terms is the end goal. The customer viewing the page does not care one iota what framework you are using.
- onion2k 13y ago
  Moot's customers are not the people viewing the discussions; their customer is the developer integrating their code into a website. A framework might be important to them. If their argument was "We didn't like any of the frameworks so we built moot without one" that'd be great, but they're making the case that all developers would be better off without, and that's pretty damn dubious.
  - aaronem 13y ago
    My thoughts exactly. Moot's specific use case militates strongly against any of the frameworks discussed in the linked article, but it's specious to infer from that that frameworks are never of value, and especially questionable to do so in an article whose trailing "Read next" link points to an article about the framework Moot themselves invented.
  - Arnor 13y ago
    I fail to see where the article proselytized against JS frameworks for anyone. They highlighted their specific needs and explained why each of the big 3 JS frameworks didn't fill that need. Can you point out where I missed this "all developers would be better off without..." tone?
crabasa 13y ago
Unfortunately, the title is misleading. It should be titled "Angular, Ember and Backbone are too heavyweight so I created riot.js".
puppetmaster3 13y ago
By no framework, I think don't use an MVC framework, it does not add value. (I wrote a book on MVC framework). Great is the enemy of good, they are bad for you. There are non MVC frameworks that focus on UI/DOM/CSS. I based this on Enity/System more w/ events management, I call it module buss. Don't have time to evagelise it ( http://github.com/puppetMaster3/ModuleBU http://github.com/puppetMaster3/ModuleBU ) Don't use MVC, code is just all over place, there are other patterns. I know this is shocking.
splatcollision 13y ago
Great post, needs to be said sometimes that custom code is always going to be smaller and do just enough. I'm also working on a real-time socket.io app and find that I can keep most of the data model logic on the server, and the front-end is focused on user interactions & rendering data. I do use Backbone but only the Views, but the overall architecture of the front end is clean, simple, and minimal.
- Zelphyr 13y ago
  You sir/madam, are doing it right.
terabytest 13y ago
Unless I'm blind, this post contains everything except usage examples or source code for your framework. I'd be interested in seeing it for myself, not only in hearing how cool it is.
- tipiirai 13y ago
  It's here: https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...
mietek 13y ago
I've just gone through a similar process of reviewing and discarding a number of JavaScript frameworks. I've settled on React, and I can't recommend it enough! React handles mostly the V in MVC, and does an admirable job of it. It even provides a cross-platform event abstraction, which would've saved the author some trouble. http://facebook.github.io/react/ http://facebook.github.io/react/ http://facebook.github.io/react/blog/2013/06/05/why-react.html http://facebook.github.io/react/blog/2013/06/05/why-react.ht... http://facebook.github.io/react/blog/2013/11/05/thinking-in-react.html http://facebook.github.io/react/blog/2013/11/05/thinking-in-... Now, how about CSS? So far, I've reluctantly chosen Bourbon + Neat + Bitters, which are nice, but not ideal. I appreciate the Sass and semanticism (semanticness, semanticitivity) of it all — no more Bootstrap-like class names in my HTML! However, there aren't enough examples of real pages built with these tools. Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages? http://bourbon.io http://bourbon.io http://neat.bourbon.io http://neat.bourbon.io http://bitters.bourbon.io http://bitters.bourbon.io
- polskibus 13y ago
  I had the same thought while reading the article. React seems great for people who don't need many libraries to develop complex web apps.
- akbar501 13y ago
  React is a view + template, not a framework. From the React site: "React as the V in MVC". It's perfectly normal to combine react with something like Backbone as more complete solution.
  - Touche 13y ago
    React components are controllers too. "componentDidMount" == controller event. They are lightweight controllers, though.
    - akbar501 13y ago
      @Touche True. It's perfectly reasonable to add a model/data layer to React as a final/complete solution. In such a situation a heavy weight controller can be skipped.
jon_kuperman 13y ago
Really interesting post for sure. I'm not really seeing the size advantage here. All of the mentioned frameworks are cached on popular CDN's and I just don't think you're really getting much of a win out of creating your own, smaller files. Also, I'm always wary of companies that want to re-invent the wheel as opposed to using open-sourced, well-documented projects. If I start at your company and you use Backbone, not only is there a good chance I can come in with a good understanding of your code -- but I can easily check on Google for any questions I have. If I start at a company that has built their own, closed-source, custom JS framework -- I'll have to ask internally every time I have trouble figuring something out. It may be necessary for your product, but to me it always raises a flag when people create their own proprietary version of something that already has been done. Anyway, a great read for sure!
- pauljonas 13y ago
  It's not just the download size and CDN utility in caching JS on the client side for reuse -- on older machines or devices with less than shiny new execute power, all that code make for a sluggish UX experience. Maybe not in seconds, but even a hundred milliseconds can make for a huge difference, even if it's not readily apparent.
  - jon_kuperman 13y ago
    If the code is already cached on the device, which I'm assuming it is in most cases. What is it that is slowing down the UX experience?
    - userbinator 13y ago
      Cached doesn't mean free. Every byte of JS still has to get parsed even if it won't ever be used. I really like how this demoscene-like mentality of being efficient with our computing power by only applying the minimal, needed complexity has started to get a more mainstream following. The traditional approach of piling on more complexity in the form of abstractions and other things is simply not sustainable. "The fastest way to do something is to not do it at all."
sheetjs 13y ago
While I agree with the salient point in the article, I disagree with the emphasis on the size of the script. If using a framework reduces headaches and saves developer time, it will be significantly less expensive to use the framework than to roll and host your own solution. ALSO, there exist cheap/free CDNs that host many of these libraries: backbone -- http://cdnjs.com/libraries/backbone.js/ http://cdnjs.com/libraries/backbone.js/ rainbow -- http://cdnjs.com/libraries/rainbow/ http://cdnjs.com/libraries/rainbow/ socket.io -- http://cdnjs.com/libraries/socket.io/ http://cdnjs.com/libraries/socket.io/
- acdha 13y ago
  CDNs are not magic and there's a lot more than bandwidth to consider: you still have the overhead of doing DNS lookups, additional server connections and response latency before bandwidth enters the picture and the client overhead of decompressing, parsing and processing the response, where CSS will block rendering until it transfers and JavaScript will not only block rendering but also further loads until it finishes executing. Latency is almost always far more important to the user experience than the actual bandwidth and, particularly if you have many users on wireless networks, with blocking resources the concern isn't the average or best-case latency but the worst-case. Libraries are still usually a reasonable trade for the reasons you mentioned but it puts a solid limit on your site's performance. If most of your users won't execute most of that code, it makes sense to reconsider – for example, if you could replace most of your jQuery usage with APIs like e.g. querySelector/querySelectorAll and your site only supports IE8+, it's quite reasonable to question whether you're getting enough benefit to be worth that download or whether there's a way to defer anything which isn't used all of the time. For example, much as I love LeafletJS, I'll toss in a rel=prefetch header for it but won't load the script until I need to display a map.
  - gavinlynch 13y ago
    I find this specious: What modern web app isn't minifying/concatenating it's Javascript and CSS source? All of your concerns are easily remedied via a proper build procedure. And we're talking about, in relative terms, miniscule amounts of data for the web. 33 kb? C'mon now.
akbar501 13y ago
Backbone + Marionette (http://marionettejs.com http://marionettejs.com) reduces the amount of boilerplate.
warfangle 13y ago
>Why not Angular? The author points out that they just want two-way databinding, and don't want the entire overhead of Angular. Most of the Angular overhead is directives that you probably would use /anyways/, and are actually just written in Angular. Ostensibly, you could fork Angular, take out all the custom directives, and end up with a much smaller starting codebase. But then you'd end up re-implementing a lot of the default Angular directives (like ng-loop), and likely have a buggier application for it.
etanazir 13y ago
Reasonable argument for preferring small optional packages v. shipping the kitchen sink with a big package. But hubris to roll your own everything.
Arnor 13y ago
I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these frameworks get in the way for most of my projects. I tend to use the following structure: (function () { 'use strict' var n; $(document).ready(function () { // Event listeners here $('#some-id').on('click', n.Product.respond_to_some_click); } // Sometimes I omit the n variable and just pollute the global namespace because I'm BA like that. n = { Product: { respond_to_some_click: function() { // Do some stuff } }, Cart: { }, Whatever: { } } }()); This structure keeps things pretty well organized without a real need for a framework. So far this has been a really comfortable alternative to a heavy framework. I can't wait to get it ripped to shreds and see how I can improve :)
- popotamonga 13y ago
  Launching a massive project with that exact same structure soon. No problems at all. Feels so flexible.
- ktusznio 13y ago
  This approach is fine for small projects but you'll run into organizational problems once your application's complexity grows. For example, how many event listeners are you going to pile into that $(document).ready callback before you decide to break things up? How do you organize your code if/when you separate your listeners. Another aspect your code doesn't address is fetching/posting data from/to the server, which leads to many more tangles, especially once you start duplicating code between models, etc. Anyway, this isn't a criticism by any means. If such a lightweight approach is working well then you're doing it right. I'm just pointing out that things can get hairy as your app needs to do more and more.
  - Arnor 13y ago
    In my current project I have 20 listeners in the ready function. I can see how it would get pretty nasty if I got up to the 100+ range. I think that would be settled by tacking on a listeners method to each of the models: ... $(document).ready(function () { n.Product.listeners(); n.Cart.listeners(); }); ... Ooo... I like that, maybe I'll implement that... Regarding the fetching/posting data, I have an ajax method on the applicable model. Fortunately, I'm writing the server app as well so I got to make some decisions on that end that simplify the approach (e.g. everything goes through POST, all data comes back as JSON.) I suppose that makes the AJAX acronym imprecise... AJAJ?
nawitus 13y ago
This article criticizes the time spent learning a new framework. However, it doesn't seem to note that creating a new bulletproof JavaScript framework will likely take a lot of more time.
mrcwinn 13y ago
No.
cdata 13y ago
As a JavaScript developer who spent much of his early career writing framework-less JavaScript (as many of us did in the not too distant past), the sentiment behind this post really rings true to the way I feel about programming for a client like the browser. Modern frameworks are all young and imperfect in their own ways, every byte counts and JavaScript is certainly powerful and expressive enough to get you by without a framework. On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. The reality I have experienced is this: as your project and team grow, not everyone you work with will hit the ground with the architectural ambition to contribute to or absorb a new paradigm. Many developers will come to the table with useful domain experience related to a specific framework, or a desire to learn a tool that will be useful to them in a future job. Asking developers to learn your company's proprietary paradigm is asking them to invest time and effort developing a skill that they often can't even use in a side project if they wanted to; putting aside questions of commoditization of the profession, I think that this can be a potential enthusiasm killer for your team mates. The ability to think beyond the framework and self-solve problems with code is a great skill to engender in a team. That said, the pursuit of that skill often must be balanced with the business need of crafting a product.
- SkyMarshal 13y ago
  The other big benefit of popular frameworks to businesses is that they're more likely to reach maturity faster with more people using, fixing, and contributing to them. With frameworks, bugs, security holes, and performance issues - especially the hard-to-find edge cases and gremlins - once solved are solved forever (more or less), whereas every time you start your own new framework you have to deal with that again. It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.
CmonDev 13y ago
Doesn't matter which kind of icing you put on a bad cake, but it can make it look a bit better. Does author suggest we just eat a very small bad cake with no icing on top? Also POJO historically stands for "Plain Old Java Object".
js4all 13y ago
You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, your app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint. Using a proprietary framework has none of these advantages. Every new developer needs more time to find his way into the code and that time multiplies as your team grows. Just think about this before starting a new project.
- coldtea 13y ago
  >You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, you app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint. For one, your app can have a structure even with your self-coded solution. That's the job of the programmer, not of the framework. Besides, the framework's structure is not tailored for you app. It's the one-size-fits-all structure its developer likes to think in. Second, while using a framework might has some benefits for a slightly larger team, when you go even big it loses the benefits again. In fact a lot of the big companies are using their own framework (which they self-coded).
gedrap 13y ago
>> First, it's about the same size as Moot as a whole (91kb) I am feeling a bit of a fool to ask that but... what's the obsession with the code size when it comes to client side JS? Bandwidth? Well, unless you are running at Google's scale, some extra bandwith is much cheaper than the time spent on writing your own solutions to well known and solved problems (and some of the problems you were not aware of yet). Performance, since more code - more stuff to execute - will take longer? It's good to have performance in mind and maybe benchmarks will tell you that it's X times faster but what will it be once translated to seconds?
- adamcw 13y ago
  Bandwidth concerns cut both ways. I typically worry less about my server being able to serve it, than I do about the client having to receive it. For desktop users it's less of an issue, but site size matters a great deal to mobile users. At least that's where I tend to worry about it, not sure if this is the common reason.
- robmcm 13y ago
  They want small JS files so their designers can have a 2MB background image...
- owenversteeg 13y ago
  As I said here (https://news.ycombinator.com/item?id=7032169 https://news.ycombinator.com/item?id=7032169) it's usually because of front-end performance. Users are very concerned with performance, and loading a 150kb library doesn't help. The extra kilobytes translate into seconds at an alarming rate if you're not on Google Fiber, and I've found that in rural NH Bootstrap usually takes 3 seconds to load vs. Min takes 300ms to load. Min (http://minfwk.com http://minfwk.com) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.
- ultimatedelman 13y ago
  it all comes down to load times. because users will leave if a page takes a long time to load, the less code you have to transfer over the wire, the better. it is different from server side code because it must be transferred and executed by the user. also, this applies heavily to mobile. not everyone has high-speed internet connections or wifi on their phones, so the less data transfer you have, the faster your page will load, and the less likely your user will leave before it's done loading.
yeukhon 13y ago
So when OP says none of the popular framework works for him, he doesn't want to be locked in with another framework, he created his own MVC framework Motto. That sounds contradicting. You now locked into your own framework.
pka 13y ago
So you're mixing view logic (rendering DOM elements, listening to events) with controller logic, and from my experience this is exactly the type of stuff that leads to an unmaintainable mess when your codebase grows. For one, you can't test your controllers unless you mock the DOM (and nobody is ever gonna waste time doing that). And what happens when you decide to create a mobile version of your app with a new set of touch optimized views? Duplicate all controllers? Then you decide to split a view into two or more independent views. Rewrite that controller logic again. And so on... This is exactly what MVC frameworks try to help you with, and with good reason. And I'm not even talking about the dozens of other well-tested and carefully designed features you'll probably end up duplicating. Taking everything into consideration, I really don't think smaller file sizes justify all that.
moron4hire 13y ago
Love HN. "I, not knowing your exact requirements and constraints, know better than you what is best for your project. You are a fool for having defied us. At last, my intellectual superiority is proven."
dougk16 13y ago
What's interesting to note, for all those disparaging this approach, is that this is how all those other JS frameworks came into being in the first place...developer isn't satisfied with what's out there, rolls their own stuff, and lo and behold it can be generalized to other applications. I wouldn't be surprised to see a Moot framework in the next year or so!
- teleclimber 13y ago
  Next year? Try right now: https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...
oesmith 13y ago
I wonder why Google's Closure Compiler hasn't taken off more in the open-source world. At the cost of some mandatory comments to help the compiler, it's able to analyze and remove unused library code from your application.
programminggeek 13y ago
Every app has its own framework/DSL. What a "framework" that isn't your app gives you is the ability to have a common language to describe and build your app's framework/DSL. The larger the team, the more important a framework becomes. The smaller the team, the easier it is to have "less framework" that you aren't totally defining yourself. That said, the real benefit in most frameworks is the solved problems. They might not solve them in the most optimal way, but is reinventing the wheel adding the most value in most cases? Nah, probably not. Then again, sometimes reinventing the wheel is fun.
mjackson 13y ago
The very next post on this blog is all about ... drum roll ... a custom framework that the moot team built, after deciding to not use any frameworks. https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework... Sadly, this behavior is very common among those who have a hard time adopting existing libraries/frameworks. In the end, they almost always re-invent their own obscure wheel that does the same job.
- felxh 13y ago
  The irony doesn't escape me, but for what it's worth, here is a previous HN discussion about their framework you mentioned: https://news.ycombinator.com/item?id=6653024 https://news.ycombinator.com/item?id=6653024 A complaint I remember was that "there isn't much to see here except jQuery"
- badman_ting 13y ago
  Boooooo.
- ataggart 13y ago
  I think it's important to distinguish frameworks from libraries. With libraries, your code is the caller; you can compose things as you like, including with your own code for cases not covered by the library. But with frameworks, your code tends to be the callee; you must conform to (and are thus limited by) the assumptions the calling code has baked-in by the framework authors. My sense is that the pain from this inverted directionality is what drives these bespoke frameworks.
- ntoshev 13y ago
  Of course. Not using any framework (external or built in-house) would mean that the team didn't find any useful abstractions that could be layered on the raw JavaScript. Very unlikely.
- evolve2k 13y ago
  Obligatory XKCD http://xkcd.com/927/ http://xkcd.com/927/
WalterSear 13y ago
if(frameworkLess == MadeYourOwnFramework){ this.author = aHipster } On second thoughts, the message seems more like "Go frameworkless, with our new framework."
- usingpond 13y ago
  Re: hipster-- I don't think that word means what you think it means.
owenversteeg 13y ago
It seems that a large motivation to not use JS frameworks is their large size. Of course, the same can be said for CSS - the frameworks are quite large. Unfortunately, since most developers don't interact with CSS as much, people typically ignore the fact that Bootstrap and Foundation are 130kb and 150kb respectively - at the same time they complain about a 24kb JS library's size. This inspired me to create Min, a 995 byte CSS framework: http://minfwk.com http://minfwk.com
peterhunt 13y ago
These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. This type of thinking is going to hold back frontend web development as a whole unless we address it. Disclaimer: I am on the React team. "API first" -- just layer your API on top of whatever you're using to implement it. Abstraction is an important part of what we do as SW engineers. This post describes a particularly leaky abstraction, which is easily fixed. "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc). By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. The lesson to be learned here is that if add a single image you've pretty much blown away any JS savings you would have had. Another thing: usually multiple server round-trips matter more than bytes down the wire. "Full control" -- this is a legit reason. Some of the bullet points are indicative of the state of client-side JS tooling though which are fixable. "Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. This is totally OK, but not a good reason to tell everyone that code reuse is bad. "Technology lock-in" -- somewhat of a legit reason, but more of a commentary on monolithic architectures than anything else.
- twerquie 13y ago
  Comparing images and javascript in terms of payload size is apples and oranges. Images do not block the rendering of a page, are trivial to decode and display, and do not have long execution paths for the duration of their life.
  - tomkin 13y ago
    If your argument is "byte size", images matter. There's no getting away from that. This Marco Polo, Columbus-esc view of "rediscovering the basics" is on ego, not efficiency. You're not discovering new territory by rebuilding the wheel, passing it off as "efficiency". Bandwidth costs would be the only point I could possibly side with - but as mentioned, you add a JPG or any resource for that matter, and the benefits are gone. If you are going to go about the busy work of rebuilding the wheel, ask yourself, is there a single user's life you are improving? If you have sacrificed the user experience at all - to save 10kb - then you've disserviced them, while patting yourself on the back needlessly. 10k barely changed my experience on a 14.4-33.6kb modem, so I am unsure of how to make the argument today.
andyl 13y ago
I've built apps with Backbone, Marionette, Angular, and React. All very interesting and innovative. But for me none of them beats the productivity of a 'component' system built from simple jQuery plugins.
fogus 13y ago
This sounds like every project that I've ever been on. My co-workers could have written a series of these types of posts: * MVCless GWT * Makeless Builds * Eclipseless Java IDEs * Hibernateless ORMs * Freemarkerless Templating I've seen this story many many times. I'll give you one guess as to how many of these *less solutions were worth the effort put into them.
- vhiremath4 13y ago
  Is the answer 42?
asattarmd 13y ago
tl;dr They are realtime. They don't want full blown Rest frameworks for just reactive views. So, no AngularJS or EmberJS. What about Knockout.js? It's just 16kb.
- mVChr 13y ago
  Exactly, I'm just waiting for a greenfield project where I can try Knockout + React.
jsnk 13y ago
What a joke! He complains about frameworks being too bulky but unquestionably uses jQuery without questioning it the same way.
akamaka 13y ago
Amen, I agree 100% with this blog post. I work on a popular web application that's built on AngularJS, and these are the exact same conclusions that I've come to. * Code size is a huge issue for us. When something goes wrong, it's terrible to have to dig deep into mountains of code. * I haven't yet interviewed a developer who truly has a deep knowledge of AngularJS out of the box. There are lots of people who have shipped little projects with it, but at the end of the day, we hire smart guys and train them. Framework knowledge doesn't really matter. * I might be "hubris" to write your own framework for a small throwaway client project, but when you are heavily invested in your own product, every option is on the table. We borrowed time at the beginning by using Angular, and we are slowly paying it back, one frustrating problem at a time.
fiatjaf 13y ago
Framewoks shouldn't do everything for you, they should provide you the bases for separation of code, and them you should implement anything you want on the top of it. Angular and Ember force you to do their way -- and charge a byte price for it. That's why a simple thing like http://aurajs.com/ http://aurajs.com/ is so good and beautiful.
ulisesrmzroche 13y ago
On the other hand, if you're on a budget and don't have the money to implement your own solution to single-page web apps, you've gotta make some compromises. And that's where a framework comes in.
- super-serial 13y ago
  I've always thought the opposite while working on my own projects with limited budget... I don't have enough time to learn all these js framework idiosyncrasies, and learn the way a framework wants me to do things. I know how to separate data from the application code, and use events to communicate between parts of my app. That seems much simpler to me than trying to learn a framework.
mcmire 13y ago
Is this the same guy who wrote head.js?
kinofcain 13y ago
How on earth is using JQuery considered "frameworkless"?
- iends 13y ago
  jQuery is considered a library and not a framework.
spikels 13y ago
The authors of the recent book "Single Page Web Applications", Mike Mikowski and Josh Powell, took a similar approach - avoiding frameworks and using jQuery and just a few JavaScript libraries. Mike gave good talks on their philosophy at a couple of the HTML5 Dev Confs (available on YouTube). Made a lot of sense to me.
dikei 13y ago
I don't have time to write my own framework and teach my team to use it, so I use Backbone and tell them to google it :)
bphogan 13y ago
Seems to me that the smartest thing to do is write your application independent of any framework. That way you insulate your stuff from the framework and it doesn't become the app. That's sort of the big lesson I've learned over the years working with Rails, where too many projects become "Rails apps" rather than apps that use by Rails.
deevus 13y ago
When I'm working on a deadline it's super easy to just grab x, y & z framework and use the bits I need from each. And in the end, I've added what... 150kb of scripts? Unless I'm targeting users with bad connections, what's the problem?
- ddebernardy 13y ago
  Hehe. The answer is in the question. Mobile browsing is what... a third of the web nowadays?
jheriko 13y ago
> Goals for a web application should not be in imperative DOM manipulation, object oriented practices, or in "pure" MVC. A successful application aims to be simple, and there is no room for academic jargon. I highlight this particular pair of sentences because I believe it is very important... I've had too many discussions over why code is 'bad' when what people mean is "doesn't precisely fit this particular idea of how to implement a particular paradigm". What they really mean is that they have a philosophical objection. This effect has even poisoned programming languages... look at static class in C# - really thats a hack around having omitted free standing variables and functions with no associated object - something completely against the spirit of OO but ultimately necessary, practical and /better/ than shoehorning it into an object (singleton).
Aardwolf 13y ago
As nice as the frameworkless javascript of that website may be, I had to turn off javascript to properly read the content of that website, because otherwise it made the page title flash in a distracting way to say "Someone is writing...".
tipiirai 13y ago
New document: "Building modular applications with Riot.js" https://news.ycombinator.com/item?id=7036274 https://news.ycombinator.com/item?id=7036274

278 points by pauljonas 13y ago

How disappointing, the article is called "Frameworkless JavaScript", but the author uses jQuery for the application. Yeah, I get it, jQuery a library... File size seems like the biggest concern, but really, how important is that on a dynamic page that needs to load exactly once? And using a CDN it might already be cached anyway. That being said, I also like clean, minimal JS code.

manuletroll 13y ago
I think the focus on file size comes from the fact that moot is supposed to be embedded on sites, much like Disqus.

sync 13y ago

Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.

hadem 13y ago
Whereas had they decided to use Backbone or AngularJS I wouldn't have to invest tons of effort...? Regardless of framework (or lack there of), effort will be needed for those utilizing the API.
mattgreenrocks 13y ago
This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?
- aaronem 13y ago
  Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...
  - mattgreenrocks 13y ago
    Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
    - aaronem 13y ago
      Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.
      - Zelphyr 13y ago
        You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
        scarecrowbob 13y ago
        "And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together." Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything? I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
Chris_Newton 13y ago
Congratulations, you've just built your own ad hoc JS Framework. We used to call that part of software development “design”, and learning basic design skills and becoming familiar with the common strategies and techniques were prerequisites for being a useful developer. Perhaps losing that baseline is an unfortunate side effect of having readily available black box code to do many common jobs in the Internet age and being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.
- SkyMarshal 13y ago
  In my experience, using a framework and learning design aren't mutually exclusive. Learning a framework often requires studying its source code and grokking how it works, there's simply no better documentation. Granted that may not be quite at the level of designing your own complete framework from scratch, but imho it's the happiest middle ground between personal skill development and standing on the shoulders of giants that FOSS has enabled.
mrottenkolber 13y ago
I don't use any 3rd party code for my current work as of now. So yes I have built my own "toolkit". Maybe a vector rendering library wil be required at some point, but I started off on bare bones to see how far you get. It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.
codingdave 13y ago
Every non-trivial app will add enough custom code to a framework that new developers have a learning curve.
coldtea 13y ago
>Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running. That's the framework party line. Not necesarilly true. For one, somebody not familiar with, say, Angular would still have to get to know Angular (a huge task in itself) and then your application code too. Why not just have them understand the application code only? Since it's tailored to your application it also omits needless features and workarounds for framework issues.
- jdewald 13y ago
  I've never seen a non-trivial application that is "application code only". Most frameworks weren't built out of thin air, but because of real application needs. Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you (which now you have to support even though it's not core to what your application does, but is just a support layer). Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.
  - coldtea 13y ago
    >Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. There are trivial apps (no need of framework, small enough), medium apps (can use a framework maybe) and serious non-trivial large apps, apps you bet your company on. The latter are often better to NOT base into a framework. If they do anything novel, and they want to do, they'd hit framework limits. The framework will impose its logic upon your code, whether it fits or not, and you'll have all the baggage of assorted layers it offers you'll feel obliged to use. >Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you That's totally orthogonal. That you don't use a framework, doesn't mean you can handpick any of the popular template language libs, database mapper libs etc. Instead of being constrained by the set the framework authors chose. That is: libs, instead of frameworks. >Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit. That's not ironic in the slightest though. It reinforces what I said: since those teams evaluated whats available and they didn't fit their needs and rolled their one to solve their particular problems they way they want to solve them, what makes third companies think those "hand-rolled" frameworks are a good fit for THEIR needs? The message to take away, when a company rolls her own framework is not "frameworks are good, I should use theirs", but "they saw it fit to roll their own stuff. Perhaps I should too". After all, if you're a startup your competitive advantage is your code. You shouldn't constrain it to fit anything external. Now, if you are a consultant or web designer delivering cookie cutter projects for a company, or an enterprise developer doing some CRUD, by all means use a framework. Especially if you aren't doing anything very creative or original in the first place.
twerquie 13y ago
What if, instead of needing a framework, we just wrote tiny modules of functionality and composed them into an application? This is how the nodejs guys are doing this via npm and I must say, it's staggering. The core node "framework" has a tiny API, and the heart of it is simply require().
- frik 13y ago
  Yes exactly! Modules like in Node.js or libraries as in PHP are a lot more flexible and IMHO better than frameworks. I coded single page HTML5 apps in JS and Node.js/PHP and avoided any frameworks. A few helper functions are enough and I got a codebase that is easy to read, refactore and the overall code size is small and the execution is fast.
- ianstormtaylor 13y ago
  Exactly. If this kind of thing seems like your cup of tea check out component[1]. [1]: https://github.com/component/component https://github.com/component/component
- ben_mcmahen 13y ago
  This, entirely. You can effectively construct your own framework by combining other pre-established routers, models, and views (plus whatever other modules you might want). You still get many of the benefits of using frameworks (testing, docs), but it's much more flexible and has the potential to be leaner. You still need to establish best practices and a relatively consistent application design, but these are things you'd want to do anyway... even if using Backbone, or whatevs.
rfnslyr 13y ago
It's SO much effort to spend a weekend studying a code base and playing with it. Get over yourself.
jonny_eh 13y ago
On top of that, their new knowledge of said framework is not transferrable to their next job. If someone works on a popular framework, it makes it easier to get the next job.

onion2k 13y ago

Suggesting that frameworks are too complicated because they "add tens of redundant methods, adding complexity for the end user" is ridiculous. The number of methods in something doesn't always add to the complexity - in a lot of cases a framework vastly reduces the difficulty of using something by abstracting away the hard stuff so the user doesn't need to worry about it. That's pretty much the point of a framework. Further though, using an established framework improves things through the "many eyes" principle - if tens of thousands of people have used a piece of code, chances are it's going to be pretty damn bulletproof and it'll have a swathe of documentation backing it up (as official docs, blog posts, StackOverflow questions, etc). No startup can even dream of competing with that. Specifically in the case of moot.it, perhaps as a thing that's dropped into a website to provide a discussion forum having tight code is a bonus, but if you're writing something for other people to extend then using a well known framework as a starting point is a very, very obvious choice.

nailer 13y ago
I think the 'redundancy' here is more just unnecessary complexity. Eg, the primary value of Angular is binding DOM -> data. As a developer, I want to specify: - The template for the DOM - The data That's all. I don't care about $scope.$apply, a second module system (even if it's better) or anything else I have to read about. Ractive.JS (The Guardian's framework) does this. It's just mustache templates you bind to data, and when the data changes, the relevant parts of the DOM do. The 'how to' fits in a tweet, it's backed by a major media company and the lib is 32 kilobytes.
- nawitus 13y ago
  Ractive.JS doesn't need $scope.$apply because it uses it's own model system. AngularJS doesn't use it's own model system, the model is a plain old JavaScript object. The author of 'Frameworkless JavaScript' criticizes the Ember way of using a "complex model system". $scope.$apply exist because of limitations in JavaScript. Apparently this will be fixed in ES6, so ES6-version of AngularJS theoretically won't need $scope.$apply. Ractive.JS's data-binding looks similar to Ember.js, which also has it's own model system to learn (learning complex frameworks was criticized in the article).

jbrooksuk 13y ago

This has been discussed before. https://news.ycombinator.com/item?id=6653024 https://news.ycombinator.com/item?id=6653024 A massive discussion between Backbone.js developer and the developer of Riot.js kicked off. It's an interesting read that's for sure. You can find the library here https://github.com/moot/riotjs https://github.com/moot/riotjs

nkuttler 13y ago
Oh, so they wrote their own framework but the site doesn't use a framework.. now I get it.
- danneu 13y ago
  The blogpost explains why they didn't use an off-the-shelf framework. (Spoiler: "We wanted control.") That they can generalize their homebrew abstractions into a new framework only shows that they didn't use an off-the-shelf framework.

binarymax 13y ago

It is refreshing to see this post. As someone who has tried, and not really taken to, all three of those frameworks I sympathize. Stick with what works for you. Shipping code on your own terms is the end goal. The customer viewing the page does not care one iota what framework you are using.

onion2k 13y ago
Moot's customers are not the people viewing the discussions; their customer is the developer integrating their code into a website. A framework might be important to them. If their argument was "We didn't like any of the frameworks so we built moot without one" that'd be great, but they're making the case that all developers would be better off without, and that's pretty damn dubious.
- aaronem 13y ago
  My thoughts exactly. Moot's specific use case militates strongly against any of the frameworks discussed in the linked article, but it's specious to infer from that that frameworks are never of value, and especially questionable to do so in an article whose trailing "Read next" link points to an article about the framework Moot themselves invented.
- Arnor 13y ago
  I fail to see where the article proselytized against JS frameworks for anyone. They highlighted their specific needs and explained why each of the big 3 JS frameworks didn't fill that need. Can you point out where I missed this "all developers would be better off without..." tone?

crabasa 13y ago

Unfortunately, the title is misleading. It should be titled "Angular, Ember and Backbone are too heavyweight so I created riot.js".

puppetmaster3 13y ago

By no framework, I think don't use an MVC framework, it does not add value. (I wrote a book on MVC framework). Great is the enemy of good, they are bad for you. There are non MVC frameworks that focus on UI/DOM/CSS. I based this on Enity/System more w/ events management, I call it module buss. Don't have time to evagelise it ( http://github.com/puppetMaster3/ModuleBU http://github.com/puppetMaster3/ModuleBU ) Don't use MVC, code is just all over place, there are other patterns. I know this is shocking.

splatcollision 13y ago

Great post, needs to be said sometimes that custom code is always going to be smaller and do just enough. I'm also working on a real-time socket.io app and find that I can keep most of the data model logic on the server, and the front-end is focused on user interactions & rendering data. I do use Backbone but only the Views, but the overall architecture of the front end is clean, simple, and minimal.

Zelphyr 13y ago
You sir/madam, are doing it right.

terabytest 13y ago

Unless I'm blind, this post contains everything except usage examples or source code for your framework. I'd be interested in seeing it for myself, not only in hearing how cool it is.

tipiirai 13y ago
It's here: https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...

mietek 13y ago

I've just gone through a similar process of reviewing and discarding a number of JavaScript frameworks. I've settled on React, and I can't recommend it enough! React handles mostly the V in MVC, and does an admirable job of it. It even provides a cross-platform event abstraction, which would've saved the author some trouble. http://facebook.github.io/react/ http://facebook.github.io/react/ http://facebook.github.io/react/blog/2013/06/05/why-react.html http://facebook.github.io/react/blog/2013/06/05/why-react.ht... http://facebook.github.io/react/blog/2013/11/05/thinking-in-react.html http://facebook.github.io/react/blog/2013/11/05/thinking-in-... Now, how about CSS? So far, I've reluctantly chosen Bourbon + Neat + Bitters, which are nice, but not ideal. I appreciate the Sass and semanticism (semanticness, semanticitivity) of it all — no more Bootstrap-like class names in my HTML! However, there aren't enough examples of real pages built with these tools. Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages? http://bourbon.io http://bourbon.io http://neat.bourbon.io http://neat.bourbon.io http://bitters.bourbon.io http://bitters.bourbon.io

polskibus 13y ago
I had the same thought while reading the article. React seems great for people who don't need many libraries to develop complex web apps.
akbar501 13y ago
React is a view + template, not a framework. From the React site: "React as the V in MVC". It's perfectly normal to combine react with something like Backbone as more complete solution.
- Touche 13y ago
  React components are controllers too. "componentDidMount" == controller event. They are lightweight controllers, though.
  - akbar501 13y ago
    @Touche True. It's perfectly reasonable to add a model/data layer to React as a final/complete solution. In such a situation a heavy weight controller can be skipped.

jon_kuperman 13y ago

Really interesting post for sure. I'm not really seeing the size advantage here. All of the mentioned frameworks are cached on popular CDN's and I just don't think you're really getting much of a win out of creating your own, smaller files. Also, I'm always wary of companies that want to re-invent the wheel as opposed to using open-sourced, well-documented projects. If I start at your company and you use Backbone, not only is there a good chance I can come in with a good understanding of your code -- but I can easily check on Google for any questions I have. If I start at a company that has built their own, closed-source, custom JS framework -- I'll have to ask internally every time I have trouble figuring something out. It may be necessary for your product, but to me it always raises a flag when people create their own proprietary version of something that already has been done. Anyway, a great read for sure!

pauljonas 13y ago
It's not just the download size and CDN utility in caching JS on the client side for reuse -- on older machines or devices with less than shiny new execute power, all that code make for a sluggish UX experience. Maybe not in seconds, but even a hundred milliseconds can make for a huge difference, even if it's not readily apparent.
- jon_kuperman 13y ago
  If the code is already cached on the device, which I'm assuming it is in most cases. What is it that is slowing down the UX experience?
  - userbinator 13y ago
    Cached doesn't mean free. Every byte of JS still has to get parsed even if it won't ever be used. I really like how this demoscene-like mentality of being efficient with our computing power by only applying the minimal, needed complexity has started to get a more mainstream following. The traditional approach of piling on more complexity in the form of abstractions and other things is simply not sustainable. "The fastest way to do something is to not do it at all."

sheetjs 13y ago

While I agree with the salient point in the article, I disagree with the emphasis on the size of the script. If using a framework reduces headaches and saves developer time, it will be significantly less expensive to use the framework than to roll and host your own solution. ALSO, there exist cheap/free CDNs that host many of these libraries: backbone -- http://cdnjs.com/libraries/backbone.js/ http://cdnjs.com/libraries/backbone.js/ rainbow -- http://cdnjs.com/libraries/rainbow/ http://cdnjs.com/libraries/rainbow/ socket.io -- http://cdnjs.com/libraries/socket.io/ http://cdnjs.com/libraries/socket.io/

acdha 13y ago
CDNs are not magic and there's a lot more than bandwidth to consider: you still have the overhead of doing DNS lookups, additional server connections and response latency before bandwidth enters the picture and the client overhead of decompressing, parsing and processing the response, where CSS will block rendering until it transfers and JavaScript will not only block rendering but also further loads until it finishes executing. Latency is almost always far more important to the user experience than the actual bandwidth and, particularly if you have many users on wireless networks, with blocking resources the concern isn't the average or best-case latency but the worst-case. Libraries are still usually a reasonable trade for the reasons you mentioned but it puts a solid limit on your site's performance. If most of your users won't execute most of that code, it makes sense to reconsider – for example, if you could replace most of your jQuery usage with APIs like e.g. querySelector/querySelectorAll and your site only supports IE8+, it's quite reasonable to question whether you're getting enough benefit to be worth that download or whether there's a way to defer anything which isn't used all of the time. For example, much as I love LeafletJS, I'll toss in a rel=prefetch header for it but won't load the script until I need to display a map.
- gavinlynch 13y ago
  I find this specious: What modern web app isn't minifying/concatenating it's Javascript and CSS source? All of your concerns are easily remedied via a proper build procedure. And we're talking about, in relative terms, miniscule amounts of data for the web. 33 kb? C'mon now.

akbar501 13y ago

Backbone + Marionette (http://marionettejs.com http://marionettejs.com) reduces the amount of boilerplate.

warfangle 13y ago

>Why not Angular? The author points out that they just want two-way databinding, and don't want the entire overhead of Angular. Most of the Angular overhead is directives that you probably would use /anyways/, and are actually just written in Angular. Ostensibly, you could fork Angular, take out all the custom directives, and end up with a much smaller starting codebase. But then you'd end up re-implementing a lot of the default Angular directives (like ng-loop), and likely have a buggier application for it.

etanazir 13y ago

Reasonable argument for preferring small optional packages v. shipping the kitchen sink with a big package. But hubris to roll your own everything.

Arnor 13y ago

I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these frameworks get in the way for most of my projects. I tend to use the following structure: (function () { 'use strict' var n; $(document).ready(function () { // Event listeners here $('#some-id').on('click', n.Product.respond_to_some_click); } // Sometimes I omit the n variable and just pollute the global namespace because I'm BA like that. n = { Product: { respond_to_some_click: function() { // Do some stuff } }, Cart: { }, Whatever: { } } }()); This structure keeps things pretty well organized without a real need for a framework. So far this has been a really comfortable alternative to a heavy framework. I can't wait to get it ripped to shreds and see how I can improve :)

popotamonga 13y ago
Launching a massive project with that exact same structure soon. No problems at all. Feels so flexible.
ktusznio 13y ago
This approach is fine for small projects but you'll run into organizational problems once your application's complexity grows. For example, how many event listeners are you going to pile into that $(document).ready callback before you decide to break things up? How do you organize your code if/when you separate your listeners. Another aspect your code doesn't address is fetching/posting data from/to the server, which leads to many more tangles, especially once you start duplicating code between models, etc. Anyway, this isn't a criticism by any means. If such a lightweight approach is working well then you're doing it right. I'm just pointing out that things can get hairy as your app needs to do more and more.
- Arnor 13y ago
  In my current project I have 20 listeners in the ready function. I can see how it would get pretty nasty if I got up to the 100+ range. I think that would be settled by tacking on a listeners method to each of the models: ... $(document).ready(function () { n.Product.listeners(); n.Cart.listeners(); }); ... Ooo... I like that, maybe I'll implement that... Regarding the fetching/posting data, I have an ajax method on the applicable model. Fortunately, I'm writing the server app as well so I got to make some decisions on that end that simplify the approach (e.g. everything goes through POST, all data comes back as JSON.) I suppose that makes the AJAX acronym imprecise... AJAJ?

nawitus 13y ago

This article criticizes the time spent learning a new framework. However, it doesn't seem to note that creating a new bulletproof JavaScript framework will likely take a lot of more time.

mrcwinn 13y ago

No.

cdata 13y ago

As a JavaScript developer who spent much of his early career writing framework-less JavaScript (as many of us did in the not too distant past), the sentiment behind this post really rings true to the way I feel about programming for a client like the browser. Modern frameworks are all young and imperfect in their own ways, every byte counts and JavaScript is certainly powerful and expressive enough to get you by without a framework. On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. The reality I have experienced is this: as your project and team grow, not everyone you work with will hit the ground with the architectural ambition to contribute to or absorb a new paradigm. Many developers will come to the table with useful domain experience related to a specific framework, or a desire to learn a tool that will be useful to them in a future job. Asking developers to learn your company's proprietary paradigm is asking them to invest time and effort developing a skill that they often can't even use in a side project if they wanted to; putting aside questions of commoditization of the profession, I think that this can be a potential enthusiasm killer for your team mates. The ability to think beyond the framework and self-solve problems with code is a great skill to engender in a team. That said, the pursuit of that skill often must be balanced with the business need of crafting a product.

SkyMarshal 13y ago
The other big benefit of popular frameworks to businesses is that they're more likely to reach maturity faster with more people using, fixing, and contributing to them. With frameworks, bugs, security holes, and performance issues - especially the hard-to-find edge cases and gremlins - once solved are solved forever (more or less), whereas every time you start your own new framework you have to deal with that again. It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.

CmonDev 13y ago

Doesn't matter which kind of icing you put on a bad cake, but it can make it look a bit better. Does author suggest we just eat a very small bad cake with no icing on top? Also POJO historically stands for "Plain Old Java Object".

js4all 13y ago

You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, your app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint. Using a proprietary framework has none of these advantages. Every new developer needs more time to find his way into the code and that time multiplies as your team grows. Just think about this before starting a new project.

coldtea 13y ago
>You are going a dangerous way. As long as your team and code base are small, a self-cocked solution has its advantages. But when you use one of the frameworks, you app gets a structure that other developers can easily understand, because they know the concept. They easily find points where to debug and where to breakpoint. For one, your app can have a structure even with your self-coded solution. That's the job of the programmer, not of the framework. Besides, the framework's structure is not tailored for you app. It's the one-size-fits-all structure its developer likes to think in. Second, while using a framework might has some benefits for a slightly larger team, when you go even big it loses the benefits again. In fact a lot of the big companies are using their own framework (which they self-coded).

gedrap 13y ago

>> First, it's about the same size as Moot as a whole (91kb) I am feeling a bit of a fool to ask that but... what's the obsession with the code size when it comes to client side JS? Bandwidth? Well, unless you are running at Google's scale, some extra bandwith is much cheaper than the time spent on writing your own solutions to well known and solved problems (and some of the problems you were not aware of yet). Performance, since more code - more stuff to execute - will take longer? It's good to have performance in mind and maybe benchmarks will tell you that it's X times faster but what will it be once translated to seconds?

adamcw 13y ago
Bandwidth concerns cut both ways. I typically worry less about my server being able to serve it, than I do about the client having to receive it. For desktop users it's less of an issue, but site size matters a great deal to mobile users. At least that's where I tend to worry about it, not sure if this is the common reason.
robmcm 13y ago
They want small JS files so their designers can have a 2MB background image...
owenversteeg 13y ago
As I said here (https://news.ycombinator.com/item?id=7032169 https://news.ycombinator.com/item?id=7032169) it's usually because of front-end performance. Users are very concerned with performance, and loading a 150kb library doesn't help. The extra kilobytes translate into seconds at an alarming rate if you're not on Google Fiber, and I've found that in rural NH Bootstrap usually takes 3 seconds to load vs. Min takes 300ms to load. Min (http://minfwk.com http://minfwk.com) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.
ultimatedelman 13y ago
it all comes down to load times. because users will leave if a page takes a long time to load, the less code you have to transfer over the wire, the better. it is different from server side code because it must be transferred and executed by the user. also, this applies heavily to mobile. not everyone has high-speed internet connections or wifi on their phones, so the less data transfer you have, the faster your page will load, and the less likely your user will leave before it's done loading.

yeukhon 13y ago

So when OP says none of the popular framework works for him, he doesn't want to be locked in with another framework, he created his own MVC framework Motto. That sounds contradicting. You now locked into your own framework.

pka 13y ago

So you're mixing view logic (rendering DOM elements, listening to events) with controller logic, and from my experience this is exactly the type of stuff that leads to an unmaintainable mess when your codebase grows. For one, you can't test your controllers unless you mock the DOM (and nobody is ever gonna waste time doing that). And what happens when you decide to create a mobile version of your app with a new set of touch optimized views? Duplicate all controllers? Then you decide to split a view into two or more independent views. Rewrite that controller logic again. And so on... This is exactly what MVC frameworks try to help you with, and with good reason. And I'm not even talking about the dozens of other well-tested and carefully designed features you'll probably end up duplicating. Taking everything into consideration, I really don't think smaller file sizes justify all that.

moron4hire 13y ago

Love HN. "I, not knowing your exact requirements and constraints, know better than you what is best for your project. You are a fool for having defied us. At last, my intellectual superiority is proven."

dougk16 13y ago

What's interesting to note, for all those disparaging this approach, is that this is how all those other JS frameworks came into being in the first place...developer isn't satisfied with what's out there, rolls their own stuff, and lo and behold it can be generalized to other applications. I wouldn't be surprised to see a Moot framework in the next year or so!

teleclimber 13y ago
Next year? Try right now: https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...

oesmith 13y ago

I wonder why Google's Closure Compiler hasn't taken off more in the open-source world. At the cost of some mandatory comments to help the compiler, it's able to analyze and remove unused library code from your application.

programminggeek 13y ago

Every app has its own framework/DSL. What a "framework" that isn't your app gives you is the ability to have a common language to describe and build your app's framework/DSL. The larger the team, the more important a framework becomes. The smaller the team, the easier it is to have "less framework" that you aren't totally defining yourself. That said, the real benefit in most frameworks is the solved problems. They might not solve them in the most optimal way, but is reinventing the wheel adding the most value in most cases? Nah, probably not. Then again, sometimes reinventing the wheel is fun.

mjackson 13y ago

The very next post on this blog is all about ... drum roll ... a custom framework that the moot team built, after deciding to not use any frameworks. https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework... Sadly, this behavior is very common among those who have a hard time adopting existing libraries/frameworks. In the end, they almost always re-invent their own obscure wheel that does the same job.

felxh 13y ago
The irony doesn't escape me, but for what it's worth, here is a previous HN discussion about their framework you mentioned: https://news.ycombinator.com/item?id=6653024 https://news.ycombinator.com/item?id=6653024 A complaint I remember was that "there isn't much to see here except jQuery"
badman_ting 13y ago
Boooooo.
ataggart 13y ago
I think it's important to distinguish frameworks from libraries. With libraries, your code is the caller; you can compose things as you like, including with your own code for cases not covered by the library. But with frameworks, your code tends to be the callee; you must conform to (and are thus limited by) the assumptions the calling code has baked-in by the framework authors. My sense is that the pain from this inverted directionality is what drives these bespoke frameworks.
ntoshev 13y ago
Of course. Not using any framework (external or built in-house) would mean that the team didn't find any useful abstractions that could be layered on the raw JavaScript. Very unlikely.
evolve2k 13y ago
Obligatory XKCD http://xkcd.com/927/ http://xkcd.com/927/

WalterSear 13y ago

if(frameworkLess == MadeYourOwnFramework){ this.author = aHipster } On second thoughts, the message seems more like "Go frameworkless, with our new framework."

usingpond 13y ago
Re: hipster-- I don't think that word means what you think it means.

owenversteeg 13y ago

It seems that a large motivation to not use JS frameworks is their large size. Of course, the same can be said for CSS - the frameworks are quite large. Unfortunately, since most developers don't interact with CSS as much, people typically ignore the fact that Bootstrap and Foundation are 130kb and 150kb respectively - at the same time they complain about a 24kb JS library's size. This inspired me to create Min, a 995 byte CSS framework: http://minfwk.com http://minfwk.com

peterhunt 13y ago

These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. This type of thinking is going to hold back frontend web development as a whole unless we address it. Disclaimer: I am on the React team. "API first" -- just layer your API on top of whatever you're using to implement it. Abstraction is an important part of what we do as SW engineers. This post describes a particularly leaky abstraction, which is easily fixed. "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc). By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. The lesson to be learned here is that if add a single image you've pretty much blown away any JS savings you would have had. Another thing: usually multiple server round-trips matter more than bytes down the wire. "Full control" -- this is a legit reason. Some of the bullet points are indicative of the state of client-side JS tooling though which are fixable. "Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. This is totally OK, but not a good reason to tell everyone that code reuse is bad. "Technology lock-in" -- somewhat of a legit reason, but more of a commentary on monolithic architectures than anything else.

twerquie 13y ago
Comparing images and javascript in terms of payload size is apples and oranges. Images do not block the rendering of a page, are trivial to decode and display, and do not have long execution paths for the duration of their life.
- tomkin 13y ago
  If your argument is "byte size", images matter. There's no getting away from that. This Marco Polo, Columbus-esc view of "rediscovering the basics" is on ego, not efficiency. You're not discovering new territory by rebuilding the wheel, passing it off as "efficiency". Bandwidth costs would be the only point I could possibly side with - but as mentioned, you add a JPG or any resource for that matter, and the benefits are gone. If you are going to go about the busy work of rebuilding the wheel, ask yourself, is there a single user's life you are improving? If you have sacrificed the user experience at all - to save 10kb - then you've disserviced them, while patting yourself on the back needlessly. 10k barely changed my experience on a 14.4-33.6kb modem, so I am unsure of how to make the argument today.

andyl 13y ago

I've built apps with Backbone, Marionette, Angular, and React. All very interesting and innovative. But for me none of them beats the productivity of a 'component' system built from simple jQuery plugins.

fogus 13y ago

This sounds like every project that I've ever been on. My co-workers could have written a series of these types of posts: * MVCless GWT * Makeless Builds * Eclipseless Java IDEs * Hibernateless ORMs * Freemarkerless Templating I've seen this story many many times. I'll give you one guess as to how many of these *less solutions were worth the effort put into them.

vhiremath4 13y ago
Is the answer 42?

asattarmd 13y ago

tl;dr They are realtime. They don't want full blown Rest frameworks for just reactive views. So, no AngularJS or EmberJS. What about Knockout.js? It's just 16kb.

mVChr 13y ago
Exactly, I'm just waiting for a greenfield project where I can try Knockout + React.

jsnk 13y ago

What a joke! He complains about frameworks being too bulky but unquestionably uses jQuery without questioning it the same way.

akamaka 13y ago

Amen, I agree 100% with this blog post. I work on a popular web application that's built on AngularJS, and these are the exact same conclusions that I've come to. * Code size is a huge issue for us. When something goes wrong, it's terrible to have to dig deep into mountains of code. * I haven't yet interviewed a developer who truly has a deep knowledge of AngularJS out of the box. There are lots of people who have shipped little projects with it, but at the end of the day, we hire smart guys and train them. Framework knowledge doesn't really matter. * I might be "hubris" to write your own framework for a small throwaway client project, but when you are heavily invested in your own product, every option is on the table. We borrowed time at the beginning by using Angular, and we are slowly paying it back, one frustrating problem at a time.

fiatjaf 13y ago

Framewoks shouldn't do everything for you, they should provide you the bases for separation of code, and them you should implement anything you want on the top of it. Angular and Ember force you to do their way -- and charge a byte price for it. That's why a simple thing like http://aurajs.com/ http://aurajs.com/ is so good and beautiful.

ulisesrmzroche 13y ago

On the other hand, if you're on a budget and don't have the money to implement your own solution to single-page web apps, you've gotta make some compromises. And that's where a framework comes in.

super-serial 13y ago
I've always thought the opposite while working on my own projects with limited budget... I don't have enough time to learn all these js framework idiosyncrasies, and learn the way a framework wants me to do things. I know how to separate data from the application code, and use events to communicate between parts of my app. That seems much simpler to me than trying to learn a framework.

mcmire 13y ago

Is this the same guy who wrote head.js?

kinofcain 13y ago

How on earth is using JQuery considered "frameworkless"?

iends 13y ago
jQuery is considered a library and not a framework.

spikels 13y ago

The authors of the recent book "Single Page Web Applications", Mike Mikowski and Josh Powell, took a similar approach - avoiding frameworks and using jQuery and just a few JavaScript libraries. Mike gave good talks on their philosophy at a couple of the HTML5 Dev Confs (available on YouTube). Made a lot of sense to me.

dikei 13y ago

I don't have time to write my own framework and teach my team to use it, so I use Backbone and tell them to google it :)

bphogan 13y ago

Seems to me that the smartest thing to do is write your application independent of any framework. That way you insulate your stuff from the framework and it doesn't become the app. That's sort of the big lesson I've learned over the years working with Rails, where too many projects become "Rails apps" rather than apps that use by Rails.

deevus 13y ago

When I'm working on a deadline it's super easy to just grab x, y & z framework and use the bits I need from each. And in the end, I've added what... 150kb of scripts? Unless I'm targeting users with bad connections, what's the problem?

ddebernardy 13y ago
Hehe. The answer is in the question. Mobile browsing is what... a third of the web nowadays?

jheriko 13y ago

> Goals for a web application should not be in imperative DOM manipulation, object oriented practices, or in "pure" MVC. A successful application aims to be simple, and there is no room for academic jargon. I highlight this particular pair of sentences because I believe it is very important... I've had too many discussions over why code is 'bad' when what people mean is "doesn't precisely fit this particular idea of how to implement a particular paradigm". What they really mean is that they have a philosophical objection. This effect has even poisoned programming languages... look at static class in C# - really thats a hack around having omitted free standing variables and functions with no associated object - something completely against the spirit of OO but ultimately necessary, practical and /better/ than shoehorning it into an object (singleton).

Aardwolf 13y ago

As nice as the frameworkless javascript of that website may be, I had to turn off javascript to properly read the content of that website, because otherwise it made the page title flash in a distracting way to say "Someone is writing...".

tipiirai 13y ago

New document: "Building modular applications with Riot.js" https://news.ycombinator.com/item?id=7036274 https://news.ycombinator.com/item?id=7036274