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.<p>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.<p>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.<p>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.
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.<p>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.<p>"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.<p>"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.<p>Another thing: usually multiple server round-trips matter more than bytes down the wire.<p>"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.<p>"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.<p>"Technology lock-in" -- somewhat of a legit reason, but more of a commentary on monolithic architectures than anything else.
The very next post on this blog is all about ... drum roll ... a custom <i>framework</i> that the moot team built, after deciding to not use any frameworks.<p><a href="https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html" rel="nofollow">https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...</a><p>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.
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!<p>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.<p><a href="http://facebook.github.io/react/" rel="nofollow">http://facebook.github.io/react/</a><p><a href="http://facebook.github.io/react/blog/2013/06/05/why-react.html" rel="nofollow">http://facebook.github.io/react/blog/2013/06/05/why-react.ht...</a><p><a href="http://facebook.github.io/react/blog/2013/11/05/thinking-in-react.html" rel="nofollow">http://facebook.github.io/react/blog/2013/11/05/thinking-in-...</a><p>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.<p>Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages?<p><a href="http://bourbon.io" rel="nofollow">http://bourbon.io</a><p><a href="http://neat.bourbon.io" rel="nofollow">http://neat.bourbon.io</a><p><a href="http://bitters.bourbon.io" rel="nofollow">http://bitters.bourbon.io</a>
Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework.<p>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.
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:<p><pre><code> (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: {
}
}
}());
</code></pre>
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 :)
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. <i>That's pretty much the point of a framework.</i> 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.<p>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, <i>very</i> obvious choice.
Amen, I agree 100% with this blog post.<p>I work on a popular web application that's built on AngularJS, and these are the exact same conclusions that I've come to.<p>* Code size is a huge issue for us. When something goes wrong, it's terrible to have to dig deep into mountains of code.<p>* 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.<p>* 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.
This has been discussed before. <a href="https://news.ycombinator.com/item?id=6653024" rel="nofollow">https://news.ycombinator.com/item?id=6653024</a><p>A massive discussion between Backbone.js developer and the developer of Riot.js kicked off. It's an interesting read that's for sure.<p>You can find the library here <a href="https://github.com/moot/riotjs" rel="nofollow">https://github.com/moot/riotjs</a>
It is refreshing to see this post. As someone who has tried, and not really taken to, all three of those frameworks I sympathize.<p>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.
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:<p>backbone -- <a href="http://cdnjs.com/libraries/backbone.js/" rel="nofollow">http://cdnjs.com/libraries/backbone.js/</a><p>rainbow -- <a href="http://cdnjs.com/libraries/rainbow/" rel="nofollow">http://cdnjs.com/libraries/rainbow/</a><p>socket.io -- <a href="http://cdnjs.com/libraries/socket.io/" rel="nofollow">http://cdnjs.com/libraries/socket.io/</a>
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.<p>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.
How disappointing, the article is called "Frameworkless JavaScript", but the author uses jQuery for the application. Yeah, I get it, jQuery a library...<p>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.<p>That being said, I also like clean, minimal JS code.
Really interesting post for sure.<p>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.<p>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.<p>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.<p>Anyway, a great read for sure!
>Why not Angular?<p>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.<p>Ostensibly, you could fork Angular, take out all the custom directives, and end up with a much smaller starting codebase.<p>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.
This sounds like every project that I've ever been on. My co-workers could have written a series of these types of posts:<p>* MVCless GWT<p>* Makeless Builds<p>* Eclipseless Java IDEs<p>* Hibernateless ORMs<p>* Freemarkerless Templating<p>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.
Great post, needs to be said sometimes that custom code is always going to be smaller and do just enough.<p>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.
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.<p>I wouldn't be surprised to see a Moot framework in the next year or so!
>> First, it's about the same size as Moot as a whole (91kb)<p>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?<p>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).<p>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?
Every app has its own framework/DSL.<p>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.<p>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.<p>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.<p>Then again, sometimes reinventing the wheel is fun.
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.<p>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 ( <a href="http://github.com/puppetMaster3/ModuleBU" rel="nofollow">http://github.com/puppetMaster3/ModuleBU</a> )
Don't use MVC, code is just all over place, there are other patterns. I know this is shocking.
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."
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.
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.
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.<p>This inspired me to create Min, a 995 byte CSS framework: <a href="http://minfwk.com" rel="nofollow">http://minfwk.com</a>
<p><pre><code> if(frameworkLess == MadeYourOwnFramework){
this.author = aHipster
}
</code></pre>
On second thoughts, the message seems more like "Go frameworkless, with our new framework."
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.
> 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.<p>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.<p>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).
tl;dr They are realtime. They don't want full blown Rest frameworks for just reactive views. So, no AngularJS or EmberJS.<p>What about Knockout.js? It's just 16kb.
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.
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.<p>That's why a simple thing like <a href="http://aurajs.com/" rel="nofollow">http://aurajs.com/</a> is so good and beautiful.
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.<p>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.
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...".
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?<p>Unless I'm targeting users with bad connections, what's the problem?
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".
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.<p>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...<p>This is <i>exactly</i> 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.
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.
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.<p>And that's where a framework comes in.
New document: "Building modular applications with Riot.js"<p><a href="https://news.ycombinator.com/item?id=7036274" rel="nofollow">https://news.ycombinator.com/item?id=7036274</a>
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.