The post is a little dense, I'll try to summarize: it's basically Backbone split into NPM modules so you can pick & choose. For instance, you want Backbone's collections, but don't want the whole Backbone library, so you `npm install ampersand-collection`. They've setup a registry of recommended modules [1] and you compile with browserify.
Good for folks that are used to the node modules philosophy - Seems like a logical extension of the browserify effort (bringing Backbone into the frontend modules system). I dig it.
That's true, although many of the core backbone components have been significantly modified/basically completely rewritten, keeping a fair amount of similarity with the backbone APIs but extending them too, for example:
* Views have declarative data bindings for updating your html with model data automatically; out of the box, sensible render and remove methods just work; collection rendering is easy.
* Models have explicitly declared properties and types, as well as evented + cached derived/computed properties. You can access model properties without .get('name') and .set('name', value) and events and things just work.
> You can access model properties without .get('name') and .set('name', value) and events and things just work.
[when IE >= 9]
Honestly though I'm excited by getters and setters. I always disliked calling them explicitly in Backbone—it feels like a hack.
On the other hand, there's something nice to be said about explicit setters (you might not expect events to fire when it doesn't look like a function call).
Still, I'd rather have real looking code than a bunch of xxx.set('propA', yyy.get('propB')) nonsense.
But seriously, I agree that the code is what matters, not some blog post. However, I don't know if you could really unpack a framework in a single blog post anyways...
I agree with @inglor, the post could do a bit more to reel you in. From skimming over the content I could only understand that it is not backbone, modulesmodulesmodules. I found the page has issues conveying their surely valid and useful point, but they are using all the lazy folks, which are also potentially the lazy people that want to build apps using a framework.
Two clicks? I don't even have time for one click! The thing is, in the front-end world, people really can't afford to spider the website of every new framework that comes out. I don't call that "lazy"; I call it having a limited amount of time to allocate to researching cutting edge stuff.
A few inline fragments to contrast with Backbone would be super helpful.
Sorry, we just wanted to give the background to the project and why in the post, rather than focussing too heavily on code. There's plenty of API docs for the core components in http://ampersandjs.com
I hate to say it, but there is a nugget of truth to this; the post is a giant wall of text when there should really be a summary of what the project is first, with the 'why' second.
It took some browsing of the GitHub repos for me to figure out what this is. But I like it, and will probably use it, so the code is not the issue, just the presentation. :)
You don't link to it clearly enough. I also had a "just show me the code" reaction, and all I saw was the example of how to create a restful collections module.
I think it's good that people explain why they created something. If you don't know WHY they created it, WHY would you use it? And when you know the 'why', the 'what' becomes much more clear.
I think the problem is the article lacks a clear hook. I had to go to the site to find out why I should care. In the post itself, the list at the end is the most engaging part - but you've probably lost a lot of readers before you get there.
> Sorry, we just wanted to give the background to the project and why in the post, rather than focussing too heavily on code.
Your landing page should contain what your users want to see, not what you want to put there. You might be excited about the motivation behind your project but nobody cares, really.
I clicked on the link and I spent ten minutes reading a wall of text hoping to find good reasons why I should switch from Angular, Backbone or Ember. Instead, I just closed the window without knowing anything about your framework.
> There's plenty of API docs for the core components
Still not a substitute for a user manual, even tiny.
A little harsh, don't you think? The link is to a blog post - not a landing page - and it seems to me it can contain whatever the author wanted it to. The post wasn't submitted here by anyone from &yet, but by Jeremy Ashkenas (the creator of Backbone which is partly the basis for ampersand).
But the landing page doesn't say much as well. The first section is "Why?," and the only "what" is "Ampersand.js is a well-defined approach to combining (get it?) a series of intentionally tiny modules."
I don't know what that means, and the reasons for it are "simplicity of tiny modules and npm dependency," which are not exactly convincing by itself, as I can do that just fine with plain Browserify. Then, going to the "Learn" page I get my hands busy.. with something I know nothing about.
This is heavily marketed towards Backbone users, I'm guessing.
> You might be excited about the motivation behind your project but nobody cares, really.
Yes we'll try and improve the content on the homepage to make it more focussed. Though I guarantee if we didn't talk about the motivation we'd have people saying "why did you make another framework?!"
> Still not a substitute for a user manual, even tiny.
I'm not suggesting we've got it perfect by any stretch, but I'm not sure exactly what you're hoping to see? There's also http://ampersandjs.com/learn with some more detail around the various pieces.
There was a link earlier on HN about declarative programming.
In my opinion that's the best solution to the front-end dev issue.No amount of Backbone based framework ,as good as they are(and I use some) really solve the "how do I build a complex interactive view" problem on the client.
Setting intents and expectations and letting the framework drive the view life cycle solves many issues.AngularJS and React success are a proof of that fact.
So hardest thing to manage in an client app is the view . Backbone never solved that problem.It just had an opinion about the Domain Layer(Backbone models/collections) and the Data Access Layer(ajax).
Didnt try Ampersand but i'm curious as to how it solves that issue.
No reason why you can't roll with React to do this. Although backbone supplies a "View", it's very thin and makes it easy to use your own method of getting data into the dom.
Marionette takes care of this quite well for very complex views, results in much cleaner markup than angular etc, and is built on backbone. Give it a shot.
"One of the problems we’ve had at &yet especially when working on large Backbone applications is a sane way to document the type of properties a model is supposed to contain.
Backbone models, by default, don’t enforce any structure. You don’t have to declare anywhere what properties you’re going to store. As a result, people inevitably start saving miscellaneous properties on models from within a view somewhere, and there’s no good way for a new dev starting in on the project to be able to read the models and see exactly what state is being tracked."
I really wish more people would try Dart. Maintaining structure, declaring types, readability... these things can be solved at the language level.
I think that the best investment today for any Web developer is to start learning Dart. Why?
As a developer and a university professor, for the first time in my long career, I can do the following with Dart:
I can use Dart both on the client and on the server;
I can apply both object-oriented and functional way of programming;
I can develop in Dart and deploy applications in JavaScript;
I can be a productive developer with many Dart tools and libraries, and get a very good performance in either Dart applications or their JavaScript versions;
I can start developing a prototype without data types and introduce them when I need to convert the prototype to a deployable application;
I can use Dart for both synchronous and asynchronous programming;
I can use many publicly available packages and reuse their libraries;
I can be a web engineer on the client-side and a software engineer on the server-side, with the same language and many reusable libraries.
I'm building a react/flux application and I've really been looking for something like this to enforce types, generate derived properties, and so on. Many encourage sending raw data through props to your individual components but I find that there is some duplication of code and not a lot of security in your data when playing this fast&loose with it.
This is exactly the project I needed; I will very soon be integrating Ampersand Collections & State into my app. Thanks for this!
Isn't Backbone.js already 6.5kb, Packed and gzipped? Why is the stress put on making it smaller/modular? I don't think that is the problem at all. The problem is one that frameworks like Ember.js are trying to solve... reuseable, convention-based and opinionated. This is what Rails got right and something I think that client-side frameworks lack. Rails' success, for the most part, is due to its really strong opinions and conventions. These client-side "frameworks" are often brought in with the byline that its intent is to be TINY. To me, that's not what these ambitious JS frameworks should be bullet-pointing first.
There's quite a bit about this library that I'm excited about, the small module philosophy, for one. But I started digging in and am finding typos and errors all over the place in the docs. Either this is still a work-in-progress (which would be surprising since it's major version 4) or the maintainers just aren't spending much time keeping up the documentation.
To the core team here and anyone making a library: please make sure your documentation is flawless and your example code exemplary. Thanks!
With regards to "major version 4" we are doing our best to follow semver, where backwards incompatible changes require a bump in the major version.
So yes and no, this is a work in progress (what isn't) and we will constantly be pushing to make the docs better. We've been working hard over the last couple of weeks to get this into some form of a publicly releasable state, but yes it's not perfect :)
If you want to help us out, feel free to submit PRs or issues on github. The main site is at http://github.com/ampersandjs/ampersandjs.com while the API references are generated from their individual readmes, all available in that github org.
I do often submit PRs for occasional typos in docs, but I don't really feel like copy-editing a whole README, which is what's required here. I'm not trying to be difficult, just honest.
I appreciate the use of semver, but I don't think the intent is to go through three major versions in as many days...
Thanks, it was actually the READMEs on GitHub that I was referring to originally. I'd bet those don't get the same level of care the website does.
I'm really not trying to be annoying, but I'd point out there was a week there in April where ampersand-state jumped from 0.5.0 to 3.0.1. Perhaps it's just that the initial decision to one-dot was premature and now you're locked in by semver?
Well generally with semantic versioning, you only get to major version 1 once you have a piece of software that is feature-complete and production-ready. Changes in the API don't require a major version bump if you're not at 1.0 yet.
Eran's post is definitely good. We've tried to do that "hard work of pulling together modules and make sure that work together" he refers to, for the core stuff in ampersand.
Also, it's worth noting that there's no cost in installing a big framework on the server side. It doesn't hurt to have a bit more text on the hard drive that isn't used. Clearly, that's not true on the client where we have to ship code down the pipe.
You'll notice we actually use hapi on the server for the cli app. So I don't believe these to be at odds. It's all about pragmatism and picking the right tool for the job.
Great to see the efforts on keeping web applications simple. Coming from a Ruby-on-Rails background, I discovered similar principles while writing the book "Full Stack JavaScript appliactions with BackboneJS" http://shop.oreilly.com/product/0636920030799.do
> We <3 Backbone.js at &yet. It’s brilliantly simple code and it solves many common problems in developing clientside applications.
No offense but I completely disagree. I don't know what problems does backbone solve.
> But we missed the focused simplicity of tiny modules in node-land. We wanted something similar in style and philosophy, but that fully embraced tiny modules, npm, and browserify.
> So we made Ampersand.js, a well-defined approach to combining (get it?) a series of intentionally tiny, and loosely coupled modules for building JS apps.
So .. what is it exactly? a module system for the client side?
RequireJS[0] has already solved this problem.
After reading the first 10 paragraphs, I still have no idea what is this all about.
CommonJS is far superior to AMD. This is an attempt to rewrite parts of backbone to make it better, one of the main parts of that is making it CommonJS compatible. The other part is simplifying the getters and setters and the way changing properties fires events.
I think that is debatable. CommonJS is certainly simpler, however it won't work for browser-based javascript unless you wrap it with appropriate tooling. In that respect it's not just inferior to AMD, but it isn't even a viable solution.
Not that I'm against CommonJS. It just requires additional tooling to be "superior" so I don't think you should make such a blanket statement.
Browserify? Same wrapping as RequireJS would implement I believe, obviously not the 'same' but same level of performance hit and browser based tooling.
Parent should not have been downvoted and it irritates me that it was
1. hasenhj is correct, Backbone has been superseded for "advanced" webapps for at least two years and should not be used for new webapp development
2. I had the same confusion and question about what exactly ampersand is and what "advanced app" problems it sovles
emotional edit: I've used Backbone, Knockout and React in "advanced" (enterprise-scale) production apps, and studied TodoMVC and skimmed the book for Angular and Ember. My original decision to use backbone & knockout in enterprise scale app almost wrecked my first greenfield project, we spent multiple months ripping out Backbone based code. In 2014, Backbone.Model and Backbone.View are very naive ways to approach frontend problems and it is not obvious why until you've been using them a few months. There is an entire ecosystem of blog posts on HN of people attempting to explain why. Any and all of the above dependencies are better than Backbone/Knockout for new webapp development. They of course have the advantage of learning from Backbone, Knockout, YUI, Sencha etc, so it is no surprise that they tackle the hard problems that backbone makes no attempt to solve.
Complete shenanigans. Backbone is still heavily used in production for tons of "advanced" web apps. You can't just make statements like this because you decided you like angular or something better.
> 4. Strict semver all the things
> 5. Tiny module all the things!
> The smaller the feature set of the low-level modules, the easier it is to avoid breaking changes.
> 6. Expose the simplest API possible.
This is great, but what I would rather see is strict code coverage guidelines on contributions. The whole point behind having micro libraries is that writing unit tests should be easier, because there are simpler dependencies and each simple dependency is easier to mock.
Similarly,
> 7. Optimize for minimal DOM manipulation and performance.
The best way to optimize for performance is to include various performance testing, and never let performance get slower when considering patch contributions.
In short, less marketing fluff, more community process.
4. we are enforcing this with jshint and pre-commit hooks (should better document that, but we are doing that).
7. Yup, we'll keep doing more here. We just announced it! :)
"less marketing fluff" well, it's an intro post attempting to explain something new. And hey, you're reading it so maybe the marketing worked ;) But, point taken.
I'm not saying you should use it, it's what we use and we're sharing it with the world. If you're already happy with your tools, just keep on keepin' on.
Also, why does your ampersand-forms code return string objects for error messages? Seems very limiting, and a pain in the butt to extend. If you have a getErrorMessage() method, why aren't you returning an ErrorMessage object, which clients can then extend with error types (hard/soft, failure/warning/information), etc. Technically, it should just be an Error object. This would then lend itself well to advanced composition, where I can write program interactions in terms of signals (raising Error objects and Success objects, etc.)
In this case, they're meant to be as simple as possible and the individual field-views can do whatever they prefer, as they're the ones rendering them. The parent form only gets a `valid: true` and a `value` from the child. Since these are error messages meant to be used directly as error messages to users, it didn't seem like a big gain to do anything more.
With regard to "pain in the butt to extend" you could use `extend` and just replace that one method that returns those string, right?
Forms really are a pain, we tried to create a simple contract between a form-view an it's child field views that was as flexible as possible so you could easily write more input types.
1. The problem of adding more input types, as well as expressing more functions over existing and additional (unbound) input types, is a classical computer science problem called The Expression Problem.
2. It's really not about 'parents'. It is about workflows. "Can you lift 50 lbs?" may be a dependency for another question.
3. It's simple dependency inversion to use a list of Success and Failure objects to determine the state of a Submit button. This way Submit.Enabled = !list.Any(i => i.Failure). Why should Submit be responsible for knowing the structure of a form, such as fragile parent-child relationships that have no basis in reality.
4. There are really two kinds of dependencies. Layout and workflow. It's too easy to commingle these. Spreadsheets, for example, contain no such visual dependency between cells, only flow.
Great work. This looks like such an easy way to extend the great things that Backbone already does, but in a controlled and simple manner. Can't wait to dive in!
Very excited to play with this. I like Backbone but I always feel like I'm fighting .sync if it's not mapped 1:1 with a rest API. Plus npm + browserify ftw!
Looks promising.
Few suggestions
1)A basic "Contact" and/or "Community" link on your site would be useful
2)Although this may be obvious for many of us
npm install ampersand -g
you may want to change to
sudo npm install ampersand -g
Anyone writing about humanizing javascript, has my respects. Worth a serious look. However, I would have pitched it, based on its own merits rather than trying to highlight the shortcomings---if any---of backbone.
That works for native types but gets trickier for custom datatypes, and ones where you want to specify custom getters and setters for example, and then specifying some as strings and some as constructors gets messy.
We do need to do some more documentation/cleanup around custom datatypes though for sure.
Ampersand has evolved out of the client and product work we've done at &yet over the years. So there are a number of client projects with various evolutions of it in production, as well as our own products: http://andbang.com and http://talky.io, and https://otalk.im/
I am hesitant to try a framework written by people who clearly spent more time on a verbose blog post then actually working on their product. Clearly they didn't test their sites on any size viewport beyond standard desktop displays :p
>>>> Backbone models, by default, don’t enforce any structure. You don’t have to declare anywhere what properties you’re going to store. As a result, people inevitably start saving miscellaneous properties on models from within a view somewhere, and there’s no good way for a new dev starting in on the project to be able to read the models and see exactly what state is being tracked.
What a terrible lead-in example for justifying Ampersand.js. If you want structure, why not use a strongly typed language that transpiles to JavaScript? I don't understand how all these micro libraries you created get you any assurance of what you were after.
Can you please explain further why I would use Ampersand.js? Coming from TypeScript, I just see no substantive argument. If I were a Backbone developer who had monolithic dependencies, I could see your argument. I also get AMD modules or CommonJS modules for free with TypeScript.
Of course. It is a general purpose programming language, which allows deploying JavaScript code as CommonJS or AMD modules. It provides fairly rich type definitions.
I realize you are trying to say I am comparing apples to oranges, but the site explicitly mentions Human Javascript approach as inspiration, and Human Javascript is all about choosing your tools. I am pointing out that there is an incredibly powerful tool that works extremely well for large-scale software development.
There are probably good use cases for Ampersand.js. The argument in this article is a really mediocre at best use case.
Good for folks that are used to the node modules philosophy - Seems like a logical extension of the browserify effort (bringing Backbone into the frontend modules system). I dig it.
1. http://tools.ampersandjs.com/