Live data from Hacker News

Introducing Ampersand.js

blog.andyet.com

41–50 of 83 posts

Re: Introducing Ampersand.js

#41

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 f…

This. Started recently a small project in Dart, was a breath of fresh air.

Re: Introducing Ampersand.js

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

Re: Introducing Ampersand.js

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

Re: Introducing Ampersand.js

#44

>>>> 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 fo…

TypeScript isn't a client-side framework.

Re: Introducing Ampersand.js

#45

>>>> 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 fo…

TypeScript isn't a client-side framework.

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.

Re: Introducing Ampersand.js

#46
post #16

Earlier quoted context omitted.

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

Did you see ampersandjs.com? Perhaps we don't link to that clearly enough. Though yes, a better overview would be useful.

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.

Re: Introducing Ampersand.js

#47

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 f…

Dart, TypeScript, or any other similar strongly typed language that compiles down to JavaScript while still looking quite a bit like JavaScript.

Re: Introducing Ampersand.js

#48
post #39

Earlier quoted context omitted.

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…

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.

Heavily used? Probably. Does that make it great? Not necessarily.

Re: Introducing Ampersand.js

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

Post reply on HN