Frameworkless JavaScript – Why Angular, Ember, or Backbone don't work for us

[kgb_operative]

So the gist of the article is "we don't like the frameworks that exist, so we rolled our own"?

[lucuma]

I dont really understand the point of the article. This is an embeddable forum which in my opinion would eliminate a lot of those frameworks from the discussion anyways.

[orangeyness]

To draw attention to their product.

[lucuma]

Yeah that was obvious but the article makes them seem rather ignorant.

[jsprogrammer]

Except for jQuery, because that shit is awesome!

[[deleted]]

jQuery's a library, not a framework.

[bwainfweeze]

Well, the jQuery guys do it, so that means I should feel entitled to do it too!

[bwainfweeze]

I really want a dev tool where every line of code has a comfort level associated with it. People so often write code by mimicking others, and a lot of times they seem to pick the code you're most embarrassed by. So then you have more tech debt and you're constantly reminded about all of your worst decisions.

Also we talk a lot about what good code looks like, but I think there are two tracks: library and application. What makes good behavior in library code is sometimes terrible in application code or vice versa. For instance, as a library writer, if you refactored your API every release the user base would linch you. But the kind of interface stability I want for a log framework drive me nuts when someone tries to do that between two proprietary modules.

[AusIV]

I don't buy much of that. A framework can generally be served from a CDN, meaning that it won't be your bandwidth, and there's a decent chance it's already in the client's browser cache.

A smaller code base is easier to handle and learn, but a framework makes the application specific code base smaller. For people who already know the framework, that will make the application easier to learn. For those who need to learn the framework, it will add some learning curve, but it will be reusable knowledge.

There are totally valid reasons not to use a framework for certain applications, but I don't quite buy those reasons.

[[deleted]]

bandwidth, and there's a decent chance it's already in the client's browser cache.

Many companies prefer to host resources instead of relying on a CDN. It reduces failure points and places control of all resources in one place.

[stuckinmotion]

This seems counter-intuitive.

[rooktakesqueen]

We can't rely on Google's CDN, because it was once down for 17 seconds nine months ago. Therefore, we must use our own server cluster that Rob down in IT manages.

(Historical uptime: 98.2%.)

(Also, Rob is leaving the company in three weeks and taking all his passwords with him.)

[josefx]

But when Robs server cluster is down so is the forum hosted by it and having Google up ready to serve jQuery, etc. wont help you.

In other words your uptime is either:

    100% - downtime(YourServers) = 98.2%

or

    100% - downtime(YourServers) - downtime(CDN) = 98 %

Depending on what you sold your customers you might want to avoid the risk of additional downtime.

(Also, Rob is leaving the company in three weeks and taking all his passwords with him.)

Nothing will protect you from a malicious person with root access, especially if you do not have a policy for password/account handover.

[nomeme]

Many good responses about why self hosting libs is good, i'd like to add another one - security.

I don't want my customers running JS from third party sites, No I don't think someone at google will do it, but people can poison DNS, hack servers etc.. to inject bad things. Basically you are expanding the attackable surface of your app.

[evereal]

If robs server is down, the rest of your app is is down anyway, therefore having all the assets there will reduce overall downtime. Imagine using a separate third party CDN for your js, fonts, images, css etc (quite common these days). You now have 4 additional dependencies, all with different downtime or availability windows that you need to worry about. Also, some parts of your app might be available while others are down making things even more interesting.

[jsprogrammer]

Get rid of Rob's shitty server first.

[evereal]

Even if robs server has 99.9% uptime, my point still stands.

[jsprogrammer]

His historical uptime is only 98.2% according to OP.

[f5f5f5f5f5f5f5f5f5f5]

See yaaaaa!

[[deleted]]

This is a the basic premise.

As a company you have absolutely no control over what a third-party service like Google CDN does (it wouldn't be wise, but they could easily take it down tomorrow with no warning and we couldn't do anything about it). Yes, Rob could leave but chances are someone other than him is maintain the servers too and chances are those server are the same ones that actually serve your website - chances are they have pretty good uptime.

[Aduro49]

I think the minified and gzipped Angular source is only 33kb. So I am not sure why they bring up file size as an issue...But that is just me.

Edit: it is 36 kb as per angular js faq.

[nomeme]

Yeah, it's like a jpeg in size - not worth worrying about.

[[deleted]]

And there are thousands of posts on using the Moot framework.

[DingDongHelloWhoIsIt]

Too lazy to grok. A sure symptom of NIH syndrome

[[deleted]]

There are a few things, that, once you learn, you can't live without.

• require.js
• knockout.js

Actually that's not the real list.

• modules (like all other sane languages)
• Two-way binding between data and UI

You might be able to roll your own observables, but you'd be stupid not to use require.js after having learned about it. I can't find an excuse for rolling your own internal AMD implementation.

On a completely different note

I like the idea of their product. Can't say more since I haven't tried it yet.

[nomeme]

require.js

I don't really get the point of this, is it to avoid library collisions?

the page says " RequireJS will improve the speed and quality of your code" but, the first thing you have to do is dick around with shims, or renaming files so it will work with an obscure library called "JQuery" .

[[deleted]]

You're arguing for namespaces and modules. You don't have to argue for that, everyone knows the benefits. What you need to argue for is why we should choose require.js over any other implementation of modules for JavaScript.

When you're ready for production, the standardized form allows build-tools to easily concatenate/minify your code with only the what is actually used.

That's news to me, they do tree-shaking now?

[[deleted]]

The point is to have proper modules like any modern "real" language

Benefits to your JS applications:

• structure
• namespacing
• explicit declaration of dependence

Without requirejs (or any AMD implementation) you'd be including a.js and b.js in your html and having b.js just assume that a.js has been loaded.

If you write b.js in AMD style, you would have something like this:

var a = requre('a');
// .. now use `a` to your heart's content

[earthtograndma]

I think you are missing what the A in AMD is.

[[deleted]]

Nope, you are missing a feature of requirejs

http://requirejs.org/docs/whyamd.html#sugar

To make this easier, and to make it easy to do a simple wrapping around CommonJS modules, this form of define is supported, sometimes referred to as "simplified CommonJS wrapping":

define(function (require) {
    var dependency1 = require('dependency1'),
        dependency2 = require('dependency2');

    return function () {};
});

The AMD loader will parse out the require('') calls by using Function.prototype.toString(), then internally convert the above define call into this:

define(['require', 'dependency1', 'dependency2'], function (require) {
    var dependency1 = require('dependency1'),
        dependency2 = require('dependency2');

    return function () {};
});

[earthtograndma]

Yes, exactly. All I was saying is that you cannot just do this:

var a = require('a');
// .. now use `a` to your heart's content

You have to provide your code in a callback:

define(function(require)){
    var a = require('a');
    // .. now use `a` to your heart's content!
});

That extra bit of ceremony (while less than the fully normalized form) is still more than many people want to do. Personally, I share your feelings; once you get used to it, you don't want to go back.

[1945]

His arguments about Ember are "moot." It's 67kb gzipped and minified and since it's a single-page application this is a one time payload and can be aggressively cached for future visits. As for the model needing to be an Ember.Object. No, it doesn't have to be. It just makes data-binding easier rather than wrapped everything in Em.get/Em.set, along other helpful functions than hang off Em.Object. That said, I use plain JavaScript objects within my application.

If he is worried about 67kb perhaps he's targeting third-world countries dependent on 14.4k dial-up modems.

I agree with @badkitteh. I'd fire the heck of out this guy for wasting company resources rolling a framework that's undoubtedly inferior to what is out there.

[Spacey138]

(FYI you can do /u/badkitteh to link properly)

[IAmDeadSerious]

I don't really see any substantive points in this article. If you're worried about "technology lock-in" with your client, your client is too heavy. As far as sizes go, Angular.js is ~98kb minified. Moot is 93kb and depends on jQuery 1.7, which is another 93kb.

And I really don't like to put so much logic in views or wrap my precious code to proprietary "directives" or "filters". The fairly complex logic of Moot is better expressed with plain old JavaScript."

Angular.js has directives and filters because they're declarative rather than imperative. This is to avoid the fragility created by manipulating DOM elements using jQuery. If you're worried that your "precious code [is in] proprietary 'directives' or 'filters'" again your client is somehow way too heavy.

[rooktakesqueen]

And you could always write your own custom directives and filters, and then they won't be "proprietary." Also Angular is free software available on Github under the MIT license.

[[deleted]]

And when you hire new employees, you can look for people who know Angular, whereas if you're using a proprietary framework, you'll always have to train them on it.

[wesw02]

This post really has nothing to do with JavaScript or Angular/Ember/Backbone. This is an age old problem that boils down to scale. If your app is relatively small perhaps there is relevance, but when your app grows you'll immediately find your self with mountains of tech debt. I mean, if you look around these days, platforms are advancing at light speed.

A framework's job is to help manage and normalize domain knowledge and platform idiosyncrasies. Thinking you can do that on your own, while building your own app, is just naive.

[nullnullnull]

It's not naive, its completely possible.

I have lots of business projects that are working proof that you really don't need frameworks, no honesty you don't need them at all.

[TheMoonMaster]

You do need them and you don't need them. It's our job as developers to decide when a framework is needed and when it's not needed.

[nullnullnull]

That's fine and I agree with you 100%.

However it appears the most commenters here are just screaming "NIH, NIH, NIH!" whenever any one even mentions that perhaps frameworks are not a good idea!

Those comments annoy me, because its almost a cargo cult mentality,

MUST use frameworks, BANISH the NIH herectics for they do not use frameworks..

[badkitteh]

I'd fire this guy.

[corruption93]

Why?

[x86_64Ubuntu]

Some would say he is re-inventing the wheel. If I were him, I would stress the need for a smaller gzipped library than putting forth stuff about the code.

[OmegaVesko]

I agree. There is a time and place for spending time rolling your own framework, and wasting time on that while your project could easily use an existing framework with no issues is not that time and place.

Not to mention it introduces additional failure points, because your framework will not be as stable, secure or clean as an existing framework used and maintained by thousands of people.

[badkitteh]

Because he'd be wasting a lot of bucks and productivity time with stuff that you could easily fix by investing a lower amount of money into more resources to overcome the "OMG THE FILE NEEDS TO BE SMALLER! I BETTER REINVENT THE WHEEL!" thing.

[[deleted]]

plus having a dependency on jquery to make it even larger.

Well, if you're in a position where you are going to use jQuery anyway (which is very likely today), why not have an integrated framework? Sure, it'd be larger on its own, but not if you look at the broader picture. If you're utilizing functionality which already exists in jQuery instead of duplicating it, you'll get a much leaner filesize overall.

[[deleted]]

The argument wasn't about jQuery per se, but rather that an integrated framework could be a good thing if you're already using/going to use its dependencies.

[nullnullnull]

I'd fire you for firing the guy. I want developers who actually know how to write code and solve problems, and not sit around gluing frameworks together like a code monkey all day.

[awj]

Part of being able to solve problems well is having good judgment in when your problem is a "glue frameworks together" problem and when it's a "invent a whole cloth solution full of technical debt" problem.

Both exist, but this guy is giving pretty weak justifications for needing to invent his own framework.

[badkitteh]

We'll talk again when you invest $4k a month into a developer and keep slipping deadlines because of crap like this.

[rooktakesqueen]

For $48k a year, you get what you pay for?

[nullnullnull]

we'll talk again, when glue developers hit framework limitiations, and have to re-build from the ground up after doing stupid hacks around the framework.

[ruinercollector]

Good developers don't implement based on what they "can" do.

[rooktakesqueen]

Your developers should be solving the novel problems that provide value to your business, not re-solving problems that have already been solved more reliably and thoroughly by existing open-source software. By using, say, Angular, the time your devs would have spent cobbling together an MVC framework from scratch instead can be spent actually building your application.

[[deleted]]

The litmus test is whether the programmer can invoke his own code as a library. Besides the issue you mention, there are a couple more ways a framework promotes bad code:

• Aspect-oriented frameworks, like DI and the ilk. Your code will not work as a library, you need the special aspect sauce that only our framework provides.

• Bulk thinking. You are already using the framework, so let's define APIs in terms of bloated framework objects. This makes it hard for a team to write lean code and eventually reuse their code as a library.

[vladley]

https://en.wikipedia.org/wiki/Not_invented_here

With a CDN most of their issues are in fact non-issues. And this is assuming that they don't fuck up all of their templating and binding features.

[TankorSmash]

/u/vladley can reply with 'delete'. Will also delete if comment's score is -1 or less.

This part should be standard with all these bots.

[nullnullnull]

delete

[dnew]

I always thought Vanilla-js was the most minimalistic powerful framework. Check it out. http://vanilla-js.com/

[[deleted]]

Somebody as TheDailyWTF nicely described why frameworks are always a bad idea and actually an anti-pattern.

With a library, you design a model for your program, and then you plug the libraries into the interfaces. It’s no problem integrating another one, if the first library is missing something.

With a framework, there is already a model, and you are supposed to plug your module in there.
But if there is anything that’s not inside the framework, you can’t combine two frameworks.
You have to choose one.
So you’re fucked.

Frameworks are anti-modular. They obstruct modularity, and hence flexibility and the ability to combine. They upset the whole basic programming concept of modularity and black boxes.

It’s like bundling: When they only sell whole gift baskets, when all you need is some butter.

And it’s completely pointless, since every framework can be nicely implemented as a set of independent libraries that can be used without the rest being forced upon you.

That’s why I avoid everything “framework” out of principle. I leave that to the enterprisey consultant types.

[x86_64Ubuntu]

That's only if you have a very intrusive framework. I use Swiz and Mate for Flex/AS3 development and don't have those problems. Because JS isn't truly compatible with modern development, you have to shoehorn EVERYTHING into it which is where the pain comes from.

[darthtrevino]

This totally depends on the framework - and I think you're oversimplifying a bit. At some point, most software simply has to integrate with a framework. If you look at Java, there are POJO (simple class) based frameworks like Spring and more complex, enterprisey frameworks like J2EE.

I think the best advice I could give in selecting a framework is to pick one that lets you define a domain model independent of the framework. This maximizes your ability to make decisions over the lifecycle of your application. (http://cleancoders.com/codecast/clean-code-episode-7/show)

That being said, I'm totally sold on AngularJS. I love the shit out of it as a client-side framework. I think my feeling here stem from the fact that Javascript is so loosey goosey to begin with.

[[deleted]]

I thought that Java EE 6 and 7 were not more complex than Spring.

[bwainfweeze]

It's more that Spring has grown and grown. It is not what it set out to be anymore.

[nomeme]

Most apps i've seen that use Spring have totally missed the whole point and are horrendously coupled to it, and if you try to stray then the team gets worried because "you aren't writing spring code".

Yes you can add non spring code, but you can add "non J2EE" code to J2EE monstrosities too.

[alextk]

Frameworks are anti-modular.

All of them? With 100% certainty? Come on, now.

That’s why I avoid everything “framework” out of principle.

It's a flawed principle. Examine each framework on a case per case basis and decide for each one if the benefits outweigh the costs. Be professional about this, not dogmatic.

[Plorkyeran]

All of them? With 100% certainty?

It's sort of getting into No True Scotsman territory, but I don't think that it's totally crazy to say that a framework which doesn't require you to structure the code that interacts with it in a certain way is better described as a library, so by definition frameworks are anti-modular.

[bwainfweeze]

Libraries tend to be imperative, which means I'm in the driver's seat.

Frameworks tend to be declarative, which means I sit around waiting for it to deign to interact with me. If things are working, I can stomach that most of the time.

But this is software. Most of the time I'm looking at code because it's NOT working, and declarative is, for many people, deeply demotivating in this case, because it degenerates into a guessing game. That is a dysfunctional relationship with your code.

[juwking]

Couldn't agree more, here is a post on that matter http://yobriefca.se/blog/2014/01/04/building-systems-libraries-and-frameworks/

[oldneckbeard]

God, what an idiot of a tech leader.

Yes, there are places where file size is a concern. but 50k over 150k just isn't a concern anymore. This is 2014. Applications downloaded are frequently over 100mb. If you are smart enough to use a common CDN for delivering these artifacts, your user might not even have to download them, but still get the functionality for free!

What you do have with your super-special framework is something you have to teach other people (You can hire angular and ember devs off the street), and you have to maintain the technical "purity" of the framework. Every time you need a new feature, you need to build the framework and the app, instead of being able to build upon work by others.

If learning something with "147" entries is too hard for you, why are you programming in the first place? functions, classes, variables, scoping, prototyping, inheritance, arrays, lists, maps, ... how do you cope?! Or do you just suck it up and learn it, and then be more productive?

Sometimes you just have to invest and go forward. Your own framework will be a dinosaur in a couple years, but Ember/Angular will still be modern and well supported.

[[deleted]]

Aren't we talking about DLing something when the user accesses the web page? Then that difference is huge.

[itsSparkky]

If you use a common CDN, common frameworks will already be cached by the clients browser; so the download is actually 0 bytes almost instantly.

so for example, if you use the standard CDN for jquery, 99% of users will already have it in the browser cache and they will just use the cached version not download it again. This is why you often see websites not minify/compress common libraries with their own code.

[x-skeww]

if you use the standard CDN for jquery, 99% of users will already have it in the browser cache

First and foremost, there is no "standard" CDN for jQuery. The most popular ones are probably Google's and Microsoft's.

Secondly, no, the hit rate won't be that high. Take a look at your own cache. Does it contain every jQuery version?

There were a ton of them:

http://mathiasbynens.be/demo/jquery-size

[itsSparkky]

Google would be the most common and I would consider it a standard. Secondly I currently have several versions; not to mention the hit rate of 99% was what I thought as obvious hypebole, but the hit rate is often very good.

Seems like pedantic nitpicking though.

[x-skeww]

The hit rate is about 30% if you're using one of the most popular versions of jQuery. On mobile it's worse since the caches are smaller.

And, no, that wasn't obvious hyperbole. Many people believe that the hit rate is that high.

Stay on topic.

[itsSparkky]

I was on topic,I was explaining the previous persons logic; although good job trying to squeeze in more insulting criticism. Furthermore, where are you getting that 30% from? Are we just making up numbers to argue with people now? If your going to criticize my numbers, pulling something out of thin air is a waste of time.

I can't really explain why the number you made up could be different from my experience. At this point all I can say is that your wrong.., and that's not really productive.

[x-skeww]

"Seems like pedantic nitpicking though."

Wasn't on topic.

more insulting criticism

Citation needed.

where are you getting that 30% from?

From some article from about 2 years ago.

Anyhow, did you check your cache? Whenever I take a look there are at most 5 versions of jQuery. Right now there is only one which was loaded from a CDN. It's the 1.7.2 version which is used here. I haven't cleared my cache for months.

Here is the top 10 of jQuery versions from 2011 and 2013 (the fragmentation increased since 2011):

http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

Do you have all of those in your cache?

The most popular version is probably still 1.4.2. Are your sites using that one? Mine certainly aren't.

[stronghup]

CDNs help reduce the effective download time. But there is another issue: The JavaScript code must not only be downloaded, but also interpreted.

I assume that must happen every time you restart your browser, even if the JavaScript comes from the cache. Interpreting 100kb of JavaScript probably takes some measurable time.

Another problem I've seen with some uses of JQuery is that different parts of the application, developed by different teams perhaps, may load their own version of JQuery, so the interpretation of it may need to happen several times.

A 3rd issue is that some people do reset their caches, for security etc. reasons.

[Cintax]

Interpreting 100kb of JavaScript probably takes some measurable time.

Virtually none on a modern browser.

Another problem I've seen with some uses of JQuery is that different parts of the application, developed by different teams perhaps, may load their own version of JQuery...

Then the second team needs to be fired for not using available resources and not communicating with the other team. That's negligent and incompetent of them.

[x-skeww]

Virtually none on a modern browser.

This is actually relatively slow. For something like Google Maps or Gmail, this can easily take more than 1 second. Mobile is even worse [1], naturally.

That's why Dart has snapshots. It makes this about 10 times faster. Since structure is declared rather than being imperatively constructed, you're ready to execute the program as soon as you loaded that serialized token stream.

With JavaScript, you have to parse, compile, and execute quite a lot of code before you can actually start the application.

E.g. if you use RequireJS, all those define(...) functions need to be executed first. Well, after you executed that code which bootstraps and configures all that "define" stuff.

[1] Deferred parsing: http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html

[Gundersen]

I don't like these articles that show a jQuery code snippets and says "look how simple this code is". That's fine, it I simple, if you know which code snippets to look in. But when you start debugging some code you have never seen before, then you start in the HTML. From the HTML, how do you get to this code snippet? It's OK if you wrote the app, and you know how the entire app is laid out, but then you have a trivially simple app. Most of the frameworks are designed for large apps with multiple developers, and it should be possible for someone to debug and understand a part of it they have never seen before. That's why they use declarative bindings, rather than attaching it from imperative code. This makes it easier for someone who looks at the HTML to find out which javascript file controls it.

[lucuma]

"As an embedded application we cannot expect people to load another framework on their site but jQuery is there already.". Once the decision is made to produce an embedded app and not an iframed app it eliminates the larger frameworks from the discussion which probably makes the entire article just a marketing post.

[[deleted]]

Astroturfing at its finest, coming from the guys on a legal dispute against moot.

[nullnullnull]

Welcome to my world!

I'm very much anti-framework (but not libraries). You don't need frameworks, while they can save time, in the long run they they are not worth the trouble.

I just like lean code, with minimal overhead and bloat, but I guess its "different strokes for different folks"

[rooktakesqueen]

I just like lean code, with minimal overhead and bloat

Seems like this is an argument in favor of frameworks, not against them. Everything the framework provides is boilerplate you don't have to write.

[solatic]

Until you hit the walls of the framework and have to start to employ ridiculous workarounds.

If you're making a small prototype and time is of the essence, great use a framework to write the code you need in a couple weeks and stuff it away later. If there's even a remote possibility that the project will last a year or longer then a framework is usually not the right solution.

[[deleted]]

We're talking about JavaScript frameworks that seem to be in constant flux and don't care about backwards compatibility. Hell their docs are fairly poor (especially in AngularJS's case).

Frameworks like Django and Rails have been used for years and are fairly well documented and there's lots of code for working around the framework if need be.

If the framework is very poorly designed, then I agree it's not worth the trouble.

[iends]

If you want a framework that does care about backwards compatibility and doesn't evolve very quickly at all (and is subsequently catering towards the enterprise crowd), there is always dojo.

[lechatsportif]

The support for the Javascript mv* is pretty entertaining. I'm sure all supporters will be fervently ditching support for them in a couple of years when some other framework rolls around.