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.

Yes, but choose wisely. :)

Back in the late '90s I worked for a company that had their own home-grown Java Web application framework. It was conceptually clean, ran fast, and was fun to work with. URLs mapped to classes and methods; example.com/foo/bar basically located and loaded the Foo class and invoked the bar method. Domains were used to select "skins": XSLT files transformed the output. Internally it was URLs and XML all-around, making it easy to grab and verify data.

(I realize that describing an application framework using the words "Java", "XML", and "XSLT" might cause some to flinch. Believe it or not this was a really, really sweet tool. I was lucky to work with some very smart people who wrote very good code. We took some liberties with how XML was handled for some interesting parsing advantages. Not a fan of XSLT, but I learned some useful coding techniques.)

Teaching this to bright and motivated developers was not hard. It ran on relatively low-powered commodity hardware and customers loved it. Everyone was happy.

Then the company was acquired, and the new bosses decided that they didn't want to have to train new devs on some hand-rolled framework. J2EE and EJB become the new frontier.

Yes, it was easier to find devs who already knew about EJBs, WAR files, and so on. Was it worth it? No. In this case they would have been better served keeping the old framework. It was just better.

If your company is using custom tools and you are concerned that this will make it harder to bring on new developers consider how your tools tack up against what's publicly available. Maybe the better choice would be to open-source what your're using, or just take the hit of training people when they get hired.

If you make things too easy for run-of-the-mill developers you may end up with run-of-the-mill developers.

I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing.

Know how many times Ive used my crazy mad XSLT skills since?

Never.

In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways.

And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again.

And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

I think the lesson is that tech is a harsh industry to be in regardless of which tech you choose, and you should count on your skillset being obsolete in 3-5 years regardless. And your goal should be to learn the latest and greatest as quickly as possible, grab all the riches and other goodies around you while you can, and bank them for the lean years when the industry completely shifts around you and you have to learn something else.

Also key is to not let what you're told to do at work decide what you're going to learn. Even if your current company is using whatever is the latest and hottest framework you need to be learning other languages, other ways of doing things.

Here's an anecdote: I did some consulting work for an Indian-owned company in the US. I was helping out with some Rails stuff. It was a curious case of out-sourcing reversal. They had a hard time finding devs in India to do Rails because those developers felt that Java and EJB would be better for their resumes so that was the work they went for.

No, that's like your experience man. Mine has been different, and I've worked with stuff from Portlets, Struts and Webwork (remember those?) to Django and Express.js

Domain specific knowledge doesn't cause this. If you are limited by how much of it you have or don't have then you have a long way to come as a programmer... having used a language or framework before is only really useful so that you don't get snagged by gotchas or weird and wonderful eccentricities of the framework or language.

In reality getting employed is more difficult without experience on a CV, but if you are intelligent and can get an interview its not usually a problem - smart people know, or can be taught quickly, the lack of value specific experience has in most contexts (i.e. anything where you aren't just urgently crunching something out of the door). :)

Well, at the time it was alta-vista not google we turned to. :)

The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us.

We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win.

It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after.

When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs.

And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again.

No, not at all.

I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare.

The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare.

Somehow we avoided over-engineering stuff. It actually worked, and worked well.

And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language.

Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework.

Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer.

I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.

http://www.php.net/manual/en/history.php.php http://en.wikipedia.org/wiki/Django_(web_framework)#History

I've had people tell me about in-house tools they use, and some sound quite good.

One reason some companies do not release their source is because part of their business is in the licensing of the code. If a client could just take it and have others work on it because it was fundamentally OSS they'd lose that.

But hey, XSLT 1.0 runs in like, every browser in the world, and is practically designed for emitting DOM. I wonder why it's not used more often.

XSLT is a functional language with a very weird syntax, and a very domain specific default mode - transforming XML trees in streaming mode. XSLT was the translation of SGML's DSSSL [1] into an XML syntax, DSSSL is (was?) a subset of Scheme.

XSLT is actually a pretty good tool for streaming "push" templating - writing a stylesheet that generically specifies how to handle certain kinds of elements. It really sucks at "pull" templating, i.e. writing the result and indicating where data from the input should go, how most templating languages work.

It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. On top of that, it inherited XML with all its baggage, and is forever coupled to that one particular data model.

I'd still use XSLT if I had to format something like a book, or a massive manual. Put for formatting programmatic results in a web app, I never would.

[1] http://www.jclark.com/dsssl/

And for that I found I was happier using a streaming parser and writing event handlers to grab data as it went by and formatting as needed in my handler code.

XSLT might be a good fit if your logic depends on whole-document handling. For example, you need to know how many foo elements there are in order to generate a TOC. Or something where you're explicitly working of irregularities and optional data so you need to have the whole XML doc at hand and apply your transformations "all at once" so to speak.

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.

It helped us to begin with, but my view is you have to factor in what the abandonment cost might be when the industry standard starts pulling ahead of you, and that could be big. As soon as it looks like the industry is settling on a standard way of doing something, start skating to where that puck will be.

You really shouldn't be doing (2) unless you've had several go-arounds with (1). (3) is, of course, undesirable.

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.

So something like "the UNIX way". And that's wrong because?

>Abstraction is an important part of what we do as SW engineers.

Which is why we should be able to handle it and craft it properly, and not outsource it to some ready-made one-size-fits-all framework.

There are other outlets for code reuse, and they are called libraries.

>"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).

Code reuse? Ever heard of libraries?

In fact adopting a framework makes pretty sure that it will be hard to reuse both best-of-breed third party libraries (because frameworks favor their built-in stuff) and it also makes it pretty sure that your code will not be reusable outside of it, e.g when you move to a better framework. E.g. all those Ember objects will be tied to Embder, and the logic will be tied to Ember logic of doing things.

>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.

Beside the point, for one his app is not his blog, and second, a one-page style app can function while some image is loading, but not while the main JS files are.

>"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks.

Moots might not have been, but your startups better be, else you're doing commodity work churning out stuff. In which case, yes, use a framework.

I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.

Besides, bytes count is important, but it's only a problem because people aren't using tree-shaking optimizers, like Google Closure. E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need. A smart tree-shaker is able to detect unused branches and eliminate everything you don't use.

And it's a solvable problem. Google Closure in "advanced" optimizations mode is amazing. Unfortunately the popular libraries are not written for Closure's advanced optimizations and thus are incompatible. This is where compilers can help us. ClojureScript for example compiles to Google Closure optimized Javascript. There's also a fork of an older version of TypeScript that does the same thing. Google's Dart does tree shaking too. Maybe we'll also see EcmaScript 6 compilers that will do it too.

We don't need to sacrifice code reuse because of bytes count. I mean, sure, if you don't find a library that matches your architectural needs, wheel reinvention is fine. But optimizing for bytes count is a stupid reason to do it and we only feel the need for it because our tool-chains are primitive.

It's a really cool programming technique that unfortunately kills the possibility of statically analyzing the library.

The other interesting thing is that this technique actually makes the JQuery codebase significantly smaller than defining separate methods for each function that appears in the API. So it optimizes for byte-size of apps that use all JQuery functionality, at the cost of apps that use only a little bit of JQuery functionality. And I think this trade-off is why people continue to like no-framework approaches: it is possible for the application author to know what functionality from a library they will need and write code accordingly, but it is not possible for a library author to know what functionality a particular application will need and optimize for that. When you make your library more amenable to tree-shaking compilers, you increase the byte-size of it in the absence of those compilers (through reduced code-sharing or dynamism in your own codebase), which makes you look worse in head-to-head comparisons. When you build your library to be small and clever but assume it'll all be used as one unit, you impose a tax on people who just want some of the functionality and not all of it. And when you use no library at all, then you often end up reinventing parts of the functionality of a JS library poorly, in a less optimized form, and as your app grows it becomes both slower and less productive than if you'd just used one of the leading frameworks.

We ensure that React is advanced mode compatible and people routinely get pissed at me because I'm a stickler for bytes. But that's because React is a shared core library where it's our job to be small and fast.

When you're building an app, the trade-offs and priorities are different.

Although a plus of something like jQuery, if you get it off google's cdn, is that probably most users will already have it sitting on their disk so you they won't actually need to download it. It gets cached by default for up to a year.

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.

Also, I'm not suggesting we "re-invent the wheel" or code everything from scratch. I'm an advocate for composing your app from small modules. Modern js is incredibly good at this.

Boom Baby!

Sorry, I just love how you picked up on that. Yeah, lets complain about size of our code, but hey look at my pretty high-res image!

"The lady doth protest too much, me thinks".

Anyway, at the end of the day its about creating an experience that gets the job done (and ultimately get more $$$ in your pocket). Many of the problems I see (here and in the office) are debates on which framework is the best for this and that. Though those are good debates to have, one shouldn't sacrifice the end goal for the "proper" software solution.

Jobs said it best here... http://www.youtube.com/watch?v=FF-tKLISfPE

I have also worked on projects that tried to build a framework for everything on their own. Good learning experience but not the best for code stability or predictable dev cycles.

Code reuse and security depend on developer's skill. You can have both in a home-brew microframework or have neither while using something more popular. Code size, on the other hand, is something you cannot get rid of, once you commit to a certain solution.

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.

This wouldn't be true if he had more JavaScript in his app. The argument doesn't make any sense.

I sense zero respect for people on slow internet connections from you. Yes, it is a real problem. Yes, modern framework-rich development makes the problem worse.

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.

https://news.ycombinator.com/item?id=6653024

A complaint I remember was that "there isn't much to see here except jQuery"

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/blog/2013/06/05/why-react.ht...

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://neat.bourbon.io

http://bitters.bourbon.io

https://github.com/thoughtbot/bourbon/tree/gh-pages

https://github.com/thoughtbot/neat/tree/gh-pages

https://github.com/thoughtbot/bitters/tree/gh-pages

I hope that helps! -Chad

React does many things to mitigate those problems and those classes of bugs nearly dropped to 0.

- The code you write is declarative: you say how you want the dom to look like. This means that you no longer have two pieces: creation and retrieval that need to be kept in sync.

- React manages the life cycle of the components. When the component is no longer being rendered, it is properly destroyed, all the listeners are destroyed ...

- The render function is pure. This means that it is easier to write and unit test.

- The code is organized into small, composable and unit testable modules. By having a lot of small components it makes writing complex bug-free code easier.

- Each component has a very well defined interface. It cannot use anything else without it being obvious. This prevents the creation of big chunks of interdependent modules that are impossible to separate.

- There is a single point for state update. This makes the high risk pieces of code stand out.

In the end, we found that React actually helped us write more reliable app compared to framework-less Javascript code.

I think many programmers don't respect how much complexity is reduced when state isn't leaking all over the place.

Of course there will always be times when you need state, but many times its worth jumping through a few hoops to make things work without state.

EDIT: If programmers learn C so they can think lower level, they should learn Haskell so they can think in terms of side effects, composability, and the advantages of pure functions. Just a reminder, pure functions can be created in any language though some (Clojure, Haskell) enforce purity.

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.

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.

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.

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.

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.

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.

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.

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?

Automation is desirable because it increases efficiency and lowers costs.

Automation is undesirable because it eliminates jobs and automatons are not consumers.

But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design).

This is yet another instance of Worse is Better.

In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have.

So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong.

That may be a testament to my skill, the problems I work on, or both.

The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things.

I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.

I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen.

For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that.

However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code.

Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP.

I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.

I never did desktop development so don't know about there, but some must have been good.

I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?

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".

More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too.

But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.

I prototype slower, but nobody cares.

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().

[1]: https://github.com/component/component

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.

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.

If someone works on a popular framework, it makes it easier to get the next job.

    (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: {
        }

        }

    }());

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.

    ...
    $(document).ready(function () {
        n.Product.listeners();
        n.Cart.listeners();
    });
    ...

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?

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.

This is precisely why we chose to build on top of Backbone.js. It has huge market saturation and easily understandable principles, but could benefit a lot from some of the killer features of Angular and Ember.

Rarely does a framework do everything you need. In the eventuality that you create another app you'll want a custom platform to build off of. It simply makes sense to base that custom platform on top of something stable and vetted by the community.

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.

$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).

You can make the binding live specifying 'magic: true' which requires ES5 (a reasonable requirement for modern web apps).

I didn't read about Ractive.js's magic mode. It's not automatic data-binding either, according to the docs[1]:

'Magic mode only works with properties that Ractive already knows about.'

1. http://docs.ractivejs.org/latest/magic-mode

AngularJS works with properties that it doesn't know about, if you use $apply.$scope.

We use it with jQuery, PubSub and TypeScript.

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.

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

That they can generalize their homebrew abstractions into a new framework only shows that they didn't use an off-the-shelf framework.

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.

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.

backbone -- http://cdnjs.com/libraries/backbone.js/

rainbow -- http://cdnjs.com/libraries/rainbow/

socket.io -- http://cdnjs.com/libraries/socket.io/

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.

In that case, you should learn more about web performance: minification is a useful tool but it's not magic. If you add code to a bundle, you're almost certainly transferring too much data for the initial request — which increases the time before anything can run — and making caching less efficient because any change to your JavaScript invalidates the entire cached object; if you serve it separately, caching works better but you'll incur the latency cost multiple times. Every site has to balance these factors against user capabilities and the site performance targets.

To illustrate why you're being entirely too cavalier, consider Ilya Grigorik's excellent Velocity 2013 presentation detailing exactly what it takes to reliably deliver a rendered webpage in 1 second on mobile:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

Note that his performance target is roughly 14KB transfer to deal with the way 3G performs in the real world. If you were thinking about including jQuery, you just blew that budget twice over: a fully compressed, gzipped copy of jQuery 2.0.2 is 29KB. If you concatenated everything, you not only blew your transfer budget but you ensured that none of your JavaScript, even the parts which are entirely self-contained, executes within that performance target.

The point isn't that CDNs aren't useful (they're great), asset packaging isn't good (it's a key tool), or even that jQuery is bloated, but rather that good engineers make decisions based on their performance goals and actual measured user performance rather than flippantly saying “We use a CDN so the site will be fast!” (contra: healthcare.gov) or “everything is minified, so it'll be fast”.

In this regard, you should exclude well-used resources that are on a CDN from your packaging/build process.

I wonder if someone has looked at the number of websites using the same CDN and calculated this probability. I'd be very interested in the results.

Have you actually measured this? I've found that the results are lot murkier because not every site uses the same CDN or the same version of jQuery, so a user might have a bunch of different copies cached and still need to load the version you use, and many browsers – particularly on mobile – still have very small cache size limits so the fact that they downloaded jQuery yesterday doesn't mean it's still cached when they visit your site again today. This becomes increasingly dubious for any library less popular than jQuery.

This also doesn't help as much as you think for latency: by the time the browser is requesting that copy of jQuery, it already has your site's DNS resolved and almost certainly has at least one connection already established to your webserver. Restarting those processes for another server adds a non-trivial amount of latency – more so for HTTPS — which is acceptable if you're going to be making many requests but might take longer than simply transferring something like jQuery over an existing connection, particularly for wireless users or anyone using SPDY. This is fine for something which doesn't block rendering or which can stream but for something like CSS/JS in the critical path you really need real world monitoring to see how well your CDN is actually performing.

If we look at the headers for jQuery 2.0.3, we get Expires:Thu, 31 Dec 2037 23:55:55 GMT, which means that it will not expire.

You make a good point in the fact that mobile won't have so much room to cache, however, I'd imagine this will increase as devices get more space and whatnot - in Android 4.4 with the latest Chrome Beta, I tried a few sites I'm using CDN on and got 304 for pretty much all CDN'd stuff:

http://files.blackflags.co.uk/officenumbers.herokuapp.com.ha...

So what I'm saying really is I think that whilst you have good arguments, I think that things are continuing to get better and better :)

That said, once everyone's on LTE, perhaps we don't even have to care ;)

Yeah, I don't want to come across as a complete downer on this – the situation is easily better than it's ever been with CDNs becoming not just available but cheap, distributed DNS a turnkey service, etc. etc. Working on a global website for awhile has definitely reminded me that performance / reliability work hits diminishing returns unless you have have near-Google budget.

> That said, once everyone's on LTE, perhaps we don't even have to care ;)

Didn't we used to say that about 3G? ;)

https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0... does look appealing, though

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.

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).

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.

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!

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."

But the "framework" riot.js has just one important function called "observable." It's 60 lines of code that sets up an event system. I have a similar custom event system in my projects and I do not use frameworks. It's not something people will need to Google or ask their coworkers much about. Backbone on the other hand... anyone unfamiliar with it will need to spend a significant amount of time learning it.

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.

* 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.

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.

I wouldn't be surprised to see a Moot framework in the next year or so!

https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework...

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?

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) is a 995 byte CSS framework I made to deal with the slow loading times of other CSS frameworks.

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.

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.

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.

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 ) Don't use MVC, code is just all over place, there are other patterns. I know this is shocking.

This inspired me to create Min, a 995 byte CSS framework: http://minfwk.com

  if(frameworkLess == MadeYourOwnFramework){
   this.author = aHipster
  }

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).

What about Knockout.js? It's just 16kb.

That's why a simple thing like http://aurajs.com/ is so good and beautiful.

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.

Unless I'm targeting users with bad connections, what's the problem?

And that's where a framework comes in.

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.

https://news.ycombinator.com/item?id=7036274