Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Ampersand.js

blog.andyet.com

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Introducing Ampersand.js

#21

Post by thenduks »

laureny wrote: post #15
philip_roberts wrote: post #14

Earlier quoted context omitted.

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 And the clientside code for the example application generated by the cli is here: https://github.com/AmpersandJS/ampersand/tree/master/templat...

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

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

The actual landing page is http://ampersandjs.com (linked in the first sentence of the blog post) and has plenty of technical content like the user manual/guides you wanted (http://ampersandjs.com/learn) and api docs (http://ampersandjs.com/docs).

Re: Introducing Ampersand.js

#22

Post by spankalee »

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.

Re: Introducing Ampersand.js

#24

Post by aikah »

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.

Re: Introducing Ampersand.js

#25

Post by wiremine »

inglor wrote: post #13

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.

> I hate posts that don't show code.

The quickstart (called "Learn") is 2 clicks away, well written, and full of code samples:

http://ampersandjs.com/learn

I hate it when people are lazy. ;-)

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

Re: Introducing Ampersand.js

#26

Post by __david__ »

philip_roberts wrote: post #10
pfraze wrote: post #4

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

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

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

Re: Introducing Ampersand.js

#27

Post by latentflip »

__david__ wrote: post #26
philip_roberts wrote: post #10

Earlier quoted context omitted.

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

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

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

Re: Introducing Ampersand.js

#29

Post by hasenj »

> We 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/

Re: Introducing Ampersand.js

#30

Post by rezistik »

hasenj wrote: post #29

> We 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 J…

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.
Post reply on HN