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

51–60 of 83 posts

Re: Introducing Ampersand.js

#51

Post by HenrikJoreteg »

tonycoco wrote: post #35

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…

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

Re: Introducing Ampersand.js

#52

Post by HenrikJoreteg »

johnzabroski wrote: post #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 compos…

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

But hey, also... easy enough to use something else entirely, it's not like the forms stuff is bundled :)

Re: Introducing Ampersand.js

#53

Post by HenrikJoreteg »

dribnet wrote: post #50

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... https://news.ycombinator.com/item?id=7822383

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.

Re: Introducing Ampersand.js

#54

Post by HenrikJoreteg »

johnzabroski wrote: post #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 s…

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 All the codez: https://github.com/AmpersandJS Guides: 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.

Re: Introducing Ampersand.js

#55

Post by HenrikJoreteg »

aikah wrote: post #24

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

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

Re: Introducing Ampersand.js

#56

Post by callum85 »

yannis wrote: post #9

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.

Explaining it by comparison to something the target audience already knows about is just practical

Re: Introducing Ampersand.js

#57

Post by Rodeoclash »

aikah wrote: post #24

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

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.

Re: Introducing Ampersand.js

#58

Post by blktiger »

rezistik wrote: post #34
blktiger wrote: post #33

Earlier quoted context omitted.

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.

Not necessarily since you can just concatenate everything and use almond.js. Much more lightweight on the tooling front.

Re: Introducing Ampersand.js

#59

Post by vidarh »

philip_roberts wrote: post #14
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.

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

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.

Re: Introducing Ampersand.js

#60

Post by mkishi »

thenduks wrote: post #21
laureny wrote: post #15

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

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.

Post reply on HN