11 ms·

Introducing Ampersand.js

194 points by jashkenas 12y ago

duiker101 12y ago
I have to say, with this names, I thought it was a joke for a while...
- dpeck 12y ago
  same, I was expecting a competitor or add-on functionality for underscore.js
  - philip_roberts 12y ago
    Funny, I hadn't even thought of that. It comes from &yet (http://andyet.com http://andyet.com) :)
swah 12y ago
Was just reading this today https://news.ycombinator.com/item?id=7169299 https://news.ycombinator.com/item?id=7169299
- andrewliebchen 12y ago
  That would be an insightful and relevant comment, if it weren't for the strange digression into a pornography metaphor.
  - twerquie 12y ago
    I appreciate that the author distilled his thoughts about software down into porno terms we can all relate to.
    - andrewliebchen 12y ago
      You're kidding, right? Not all of use can relate to that metaphor.
      - twerquie 12y ago
        I was indeed.
- deleted 12y ago
  [deleted]
pfraze 12y ago
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. 1. http://tools.ampersandjs.com/ http://tools.ampersandjs.com/
- philip_roberts 12y ago
  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.
  - __david__ 12y ago
    > 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.
    - latentflip 12y ago
      Yup, we are basically targeting ie9 as a minimum, though some pieces will be okay in lesser browsers. Obviously that will mean some people can't use it, but hey, trade offs right :)
mrlase 12y ago
Anyone know of any applications using this in the wild yet?
- philip_roberts 12y ago
  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 http://andbang.com and http://talky.io http://talky.io, and https://otalk.im/ https://otalk.im/
yannis 12y ago
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.
- callum85 12y ago
  Explaining it by comparison to something the target audience already knows about is just practical
STRML 12y ago
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!
inglor 12y ago
I hate posts that don't show code. Show me the code, don't hide behind a huge post with buzzwords like "mobile first" and "modular". Show me what it actually does.
- philip_roberts 12y ago
  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 http://ampersandjs.com And the clientside code for the example application generated by the cli is here: https://github.com/AmpersandJS/ampersand/tree/master/template/shared/client https://github.com/AmpersandJS/ampersand/tree/master/templat...
  - laureny 12y ago
    > 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.
    - philip_roberts 12y ago
      > 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 http://ampersandjs.com/learn with some more detail around the various pieces.
    - 12y ago
bamboo_7 12y ago
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!
spankalee 12y ago
When I read something like this: "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.
- protoman22 12y ago
  This. Started recently a small project in Dart, was a breath of fresh air.
- johnzabroski 12y ago
  Dart, TypeScript, or any other similar strongly typed language that compiles down to JavaScript while still looking quite a bit like JavaScript.
  - thekaleb 12y ago
    Or even Google Closure JavaScript.
- dzenanr 12y ago
  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.
aikah 12y ago
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.
- jenius 12y ago
  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.
- HenrikJoreteg 12y ago
  We build lots of complex interactive views with it. Probably should share some more examples. We support declarative subviews, that might be what you're looking for: http://ampersandjs.com/docs#ampersand-view-subviews http://ampersandjs.com/docs#ampersand-view-subviews
- Rodeoclash 12y ago
  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.
bjryan 12y ago
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 https://andbang.com/support https://andbang.com/support
hasenj 12y ago
> 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. [0]: http://requirejs.org/ http://requirejs.org/
- rezistik 12y ago
  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.
  - blktiger 12y ago
    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.
    - rezistik 12y ago
      Browserify? Same wrapping as RequireJS would implement I believe, obviously not the 'same' but same level of performance hit and browser based tooling.
      - blktiger 12y ago
        Not necessarily since you can just concatenate everything and use almond.js. Much more lightweight on the tooling front.
johnzabroski 12y ago
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.) Just some hopefully helpful advice.
- HenrikJoreteg 12y ago
  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? InputView.extend({ getErrorMessage: function () { // return error objects instead? } }) /me shrugs 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. More on that contract here: http://ampersandjs.com/learn/forms#form-input-view-conventions http://ampersandjs.com/learn/forms#form-input-view-conventio... But hey, also... easy enough to use something else entirely, it's not like the forms stuff is bundled :)
  - johnzabroski 12y ago
    Just simple advice. 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.
2mur 12y ago
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!
poseid 12y ago
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 http://shop.oreilly.com/product/0636920030799.do
tonycoco 12y ago
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.
- HenrikJoreteg 12y ago
  I generally agree. This decision had everything to do with flexibility and composability of individual modules, not file size.
johnzabroski 12y ago
>>>> 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.
- rmrfrmrf 12y ago
  TypeScript isn't a client-side framework.
  - johnzabroski 12y ago
    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.
johnzabroski 12y ago
Also... > 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.
- HenrikJoreteg 12y ago
  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. API reference: http://ampersandjs.com/docs http://ampersandjs.com/docs All the codez: https://github.com/AmpersandJS https://github.com/AmpersandJS Guides: http://ampersandjs.com/learn/ http://ampersandjs.com/learn/ 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.
dribnet 12y ago
Interesting editorial decision by Jeremy to submit this today and "The Fallacy of Tiny Modules" a few weeks ago. I recommend reading both. http://hueniverse.com/2014/05/30/the-fallacy-of-tiny-modules/ http://hueniverse.com/2014/05/30/the-fallacy-of-tiny-modules... https://news.ycombinator.com/item?id=7822383 https://news.ycombinator.com/item?id=7822383
- HenrikJoreteg 12y ago
  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.
Kiro 12y ago
> We <3 Backbone.js at &yet. It’s brilliantly simple code and it solves many common problems in developing clientside applications. What does Backbone solve exactly?
- hasenj 12y ago
  It solves the buzzword-compliance requirements.
rtht 12y ago
I think properties should allow direct constructor assignment. I think it looks better than strings. props: { name: String, age: Number }
- philip_roberts 12y ago
  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.
couchand 12y ago
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!
- latentflip 12y ago
  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 http://github.com/ampersandjs/ampersandjs.com while the API references are generated from their individual readmes, all available in that github org.
  - theseoafs 12y ago
    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.
  - couchand 12y ago
    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...
    - philip_roberts 12y ago
grwongku 12y ago
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

194 points by jashkenas 12y ago

duiker101 12y ago

I have to say, with this names, I thought it was a joke for a while...

dpeck 12y ago
same, I was expecting a competitor or add-on functionality for underscore.js
- philip_roberts 12y ago
  Funny, I hadn't even thought of that. It comes from &yet (http://andyet.com http://andyet.com) :)

swah 12y ago

Was just reading this today https://news.ycombinator.com/item?id=7169299 https://news.ycombinator.com/item?id=7169299

andrewliebchen 12y ago
That would be an insightful and relevant comment, if it weren't for the strange digression into a pornography metaphor.
- twerquie 12y ago
  I appreciate that the author distilled his thoughts about software down into porno terms we can all relate to.
  - andrewliebchen 12y ago
    You're kidding, right? Not all of use can relate to that metaphor.
    - twerquie 12y ago
      I was indeed.
deleted 12y ago
[deleted]

pfraze 12y ago

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. 1. http://tools.ampersandjs.com/ http://tools.ampersandjs.com/

philip_roberts 12y ago
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.
- __david__ 12y ago
  > 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.
  - latentflip 12y ago
    Yup, we are basically targeting ie9 as a minimum, though some pieces will be okay in lesser browsers. Obviously that will mean some people can't use it, but hey, trade offs right :)

mrlase 12y ago

Anyone know of any applications using this in the wild yet?

philip_roberts 12y ago
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 http://andbang.com and http://talky.io http://talky.io, and https://otalk.im/ https://otalk.im/

yannis 12y ago

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.

callum85 12y ago
Explaining it by comparison to something the target audience already knows about is just practical

STRML 12y ago

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!

inglor 12y ago

I hate posts that don't show code. Show me the code, don't hide behind a huge post with buzzwords like "mobile first" and "modular". Show me what it actually does.

philip_roberts 12y ago
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 http://ampersandjs.com And the clientside code for the example application generated by the cli is here: https://github.com/AmpersandJS/ampersand/tree/master/template/shared/client https://github.com/AmpersandJS/ampersand/tree/master/templat...
- laureny 12y ago
  > 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.
  - philip_roberts 12y ago
    > 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 http://ampersandjs.com/learn with some more detail around the various pieces.
  - 12y ago

bamboo_7 12y ago

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!

spankalee 12y ago

When I read something like this: "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.

protoman22 12y ago
This. Started recently a small project in Dart, was a breath of fresh air.
johnzabroski 12y ago
Dart, TypeScript, or any other similar strongly typed language that compiles down to JavaScript while still looking quite a bit like JavaScript.
- thekaleb 12y ago
  Or even Google Closure JavaScript.
dzenanr 12y ago
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.

aikah 12y ago

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.

jenius 12y ago
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.
HenrikJoreteg 12y ago
We build lots of complex interactive views with it. Probably should share some more examples. We support declarative subviews, that might be what you're looking for: http://ampersandjs.com/docs#ampersand-view-subviews http://ampersandjs.com/docs#ampersand-view-subviews
Rodeoclash 12y ago
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.

bjryan 12y ago

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 https://andbang.com/support https://andbang.com/support

hasenj 12y ago

> 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. [0]: http://requirejs.org/ http://requirejs.org/

rezistik 12y ago
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.
- blktiger 12y ago
  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.
  - rezistik 12y ago
    Browserify? Same wrapping as RequireJS would implement I believe, obviously not the 'same' but same level of performance hit and browser based tooling.
    - blktiger 12y ago
      Not necessarily since you can just concatenate everything and use almond.js. Much more lightweight on the tooling front.

johnzabroski 12y ago

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.) Just some hopefully helpful advice.

HenrikJoreteg 12y ago
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? InputView.extend({ getErrorMessage: function () { // return error objects instead? } }) /me shrugs 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. More on that contract here: http://ampersandjs.com/learn/forms#form-input-view-conventions http://ampersandjs.com/learn/forms#form-input-view-conventio... But hey, also... easy enough to use something else entirely, it's not like the forms stuff is bundled :)
- johnzabroski 12y ago
  Just simple advice. 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.

2mur 12y ago

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!

poseid 12y ago

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 http://shop.oreilly.com/product/0636920030799.do

tonycoco 12y ago

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.

HenrikJoreteg 12y ago
I generally agree. This decision had everything to do with flexibility and composability of individual modules, not file size.

johnzabroski 12y ago

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

rmrfrmrf 12y ago
TypeScript isn't a client-side framework.
- johnzabroski 12y ago
  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.

johnzabroski 12y ago

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

HenrikJoreteg 12y ago
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. API reference: http://ampersandjs.com/docs http://ampersandjs.com/docs All the codez: https://github.com/AmpersandJS https://github.com/AmpersandJS Guides: http://ampersandjs.com/learn/ http://ampersandjs.com/learn/ 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.

dribnet 12y ago

Interesting editorial decision by Jeremy to submit this today and "The Fallacy of Tiny Modules" a few weeks ago. I recommend reading both. http://hueniverse.com/2014/05/30/the-fallacy-of-tiny-modules/ http://hueniverse.com/2014/05/30/the-fallacy-of-tiny-modules... https://news.ycombinator.com/item?id=7822383 https://news.ycombinator.com/item?id=7822383

HenrikJoreteg 12y ago
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.

Kiro 12y ago

> We <3 Backbone.js at &yet. It’s brilliantly simple code and it solves many common problems in developing clientside applications. What does Backbone solve exactly?

hasenj 12y ago
It solves the buzzword-compliance requirements.

rtht 12y ago

I think properties should allow direct constructor assignment. I think it looks better than strings. props: { name: String, age: Number }

philip_roberts 12y ago
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.

couchand 12y ago

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!

latentflip 12y ago
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 http://github.com/ampersandjs/ampersandjs.com while the API references are generated from their individual readmes, all available in that github org.
- theseoafs 12y ago
  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.
- couchand 12y ago
  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...
  - philip_roberts 12y ago

grwongku 12y ago

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