
Frameworkless JavaScript - pauljonas
https://moot.it/blog/technology/frameworkless-javascript.html
======
cdata
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.

~~~
jamesbritt
_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._

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.

~~~
mattmanser
I worked somewhere with a similar brilliant framework. It was so much easier,
etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap
stuff together fast.

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.

~~~
jamesbritt
_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._

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.

~~~
i_s
To back you up: Backbone and Rails are two examples of popular frameworks that
grew out of in-house frameworks. So no, it is not far fetched at all to to
think "that a small group of smart developers with business domain knowledge
can build fast, lean, code".

~~~
spikels
Exactly right! Same with PHP (originally "Personal Home Page" scripts for an
talented individual) and Djanjo (two talented hackers at small newspaper).
Most of today's popular web framework had humble beginnings while many of
those promoted by big tech companies have fallen by the wayside.

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

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

~~~
kllrnohj
> "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

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.

~~~
bad_user
Code reuse or the lack thereof also affects the users, because there is more
potential for bugs. Reinventing the wheel may be warranted, the end result may
actually be more stable depending on who works on that wheel reinvention, but
lets not kid ourselves - every line of code written increases the potential
for bugs and there's nothing that affects the user experience more than a
broken app.

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.

~~~
nostrademons
Tree-shaking optimizations aren't a magic bullet. I argued for about a year
and a half to get Google Search to use JQuery, but it turned out to be a
complete non-starter because the way the JQuery library is constructed is not
amenable to compilation or static analysis. JQuery often dynamically assigns
methods to the JQuery object by building a base function and then customizing
it with some data-driven properties, then splitting a string to get the method
names. For example, .width() and .height() are the same method, but one
returns .offsetWidth while the other returns .offsetHeight; this distinction
is encoded into a closure when the JQuery object is created.

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.

~~~
peterhunt
I think lodash is doing this the right way:
[https://npmjs.org/browse/keyword/lodash-
modularized](https://npmjs.org/browse/keyword/lodash-modularized)

------
mjackson
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...](https://moot.it/blog/technology/riotjs-the-1kb-mvp-
framework.html)

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.

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

------
mietek
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.ht...](http://facebook.github.io/react/blog/2013/06/05/why-react.html)

[http://facebook.github.io/react/blog/2013/11/05/thinking-
in-...](http://facebook.github.io/react/blog/2013/11/05/thinking-in-
react.html)

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)

~~~
vjeux
The biggest cause of bugs before we used React is the fact that the "state" of
the app is leaking all over the place. Symptoms were things like looking for
dom nodes that didn't exist, events that triggered on code that was no longer
active, bugs due to the app being in a state extremely complex to reproduce
with crazy conditions all over the place, race conditions...

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.

~~~
codygman
Mutable state can be a huge time sink. It's why I'm putting more and more time
into functional programming, since I think that Haskell (and Clojure) is
closer to what programming in the future will be like.

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.

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

~~~
mattgreenrocks
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?

~~~
cliffbean
This sentiment, expressed collectively and somewhat unsympathetically,
portrays the entire profession as prioritizing job security over true
excellence.

~~~
chongli
Or one could say that it reveals the fatal flaw in our current system of
capitalism:

Automation is desirable because it increases efficiency and lowers costs.

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

~~~
vidarh
That was Marx main argument for the inevitability of a socialist revolution:
That capitalism will eventually become efficient enough to on one hand create
enough goods to make it possible to totally eradicate poverty, but on the
other hand become efficient enough to substantially reduce employment.

------
Arnor
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
:)

~~~
ktusznio
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
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?

~~~
waltsu
I hope that you realize that when you've divided your listeners to Product and
Cart objects, you've created a "lightweight" Model representation. Next thing
you probably need is to fetch those Products and Carts from the server, and
you add fetch()-function to them. Soon you'll realize that you've rewritten
for example Backbone's Model class. With the exception that your solution has
probably more bugs.

~~~
Arnor
That's a good point. However, it's till tempered by the fact that I haven't
added ~40kb to the app to get it.

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

~~~
nailer
Ractive uses POJSOs. Each binding has a POJSO (ie, an Object, nothing magical,
no new inheritance system or unrelated class-based OO system) and a template
(in mustache format). That's all.

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

~~~
nawitus
I stand corrected. I thought you needed ES6 for that, but apparently ES5 is
nearly enough.

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](http://docs.ractivejs.org/latest/magic-mode)

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

~~~
dodyg
The thing is it's better set things manually so the boundary between your DOM
data and other parts of the application become clear. There's no chance of
mistaking this.set('keypath', data) with something else.

~~~
nawitus
I don't think the model should care about the view. It should be possible to
change the model without caring about view, or even knowing if a view exists.
A view should be able to use the model, but the model shouldn't care.

~~~
dodyg
It's just data for ractive.js to display on the DOM. There's no assumption on
whether this is a Model, a View Model or whatever pattern you adopt for your
app.

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

------
jbrooksuk
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
Oh, so they wrote their own framework but the site doesn't use a framework..
now I get it.

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

~~~
Arnor
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?

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

~~~
antihero
The magic of CDNs is caching. So, if you are using, for instance, the URL
"//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already
visited a bunch of sites which are using that URL for their jQuery (highly
likely), it means that there is no re-download because the browser already has
the DNS and JS cached. Perhaps one extra hit to check for a 302 (and sometimes
not even), so the thing about CDNs is the idea that when people hit your site,
they _already have_ the libraries you are using locally.

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

~~~
acdha
> So, if you are using, for instance, the URL
> "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has
> already visited a bunch of sites which are using that URL for their jQuery
> (highly likely), it means that there is no re-download because the browser
> already has the DNS and JS cached.

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.

~~~
antihero
Ok, but trade that off against the latency for sending cookies and whatnot,
and I think the difference is likely trivial.

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...](http://files.blackflags.co.uk/officenumbers.herokuapp.com.har)

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

~~~
acdha
> 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 :)

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...](https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present#slide=id.gebc26cd7_6_0)
does look appealing, though

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

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

------
nkuttler
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
I think the focus on file size comes from the fact that moot is supposed to be
embedded on sites, much like Disqus.

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

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

------
fogus
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
Is the answer 42?

------
splatcollision
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
You sir/madam, are doing it right.

------
dougk16
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
Next year? Try right now:

[https://moot.it/blog/technology/riotjs-the-1kb-mvp-
framework...](https://moot.it/blog/technology/riotjs-the-1kb-mvp-
framework.html)

------
gedrap
>> 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?

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

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

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

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

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

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

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

------
WalterSear

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

On second thoughts, the message seems more like "Go frameworkless, with our
new framework."

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

------
kinofcain
How on earth is using JQuery considered "frameworkless"?

~~~
iends
jQuery is considered a library and not a framework.

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

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

------
asattarmd
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
Exactly, I'm just waiting for a greenfield project where I can try Knockout +
React.

------
terabytest
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
It's here: [https://moot.it/blog/technology/riotjs-the-1kb-mvp-
framework...](https://moot.it/blog/technology/riotjs-the-1kb-mvp-
framework.html)

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

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

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

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

------
deevus
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
Hehe. The answer is in the question. Mobile browsing is what... a third of the
web nowadays?

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

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

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

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

------
tipiirai
New document: "Building modular applications with Riot.js"

[https://news.ycombinator.com/item?id=7036274](https://news.ycombinator.com/item?id=7036274)

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

------
dikei
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 :)

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

------
mcmire
Is this the same guy who wrote head.js?

------
mrcwinn
No.

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

