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

71–80 of 83 posts

Re: Introducing Ampersand.js

#71

Post by couchand »

philip_roberts wrote: post #69
couchand wrote: post #68

Earlier quoted context omitted.

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

Sure, I wasn't expecting you to copy edit if you don't want to, just pointing you to the source. > I appreciate the use of semver, but... Oh, we aren't breaking things _that_ quickly! ampersand-state for example has been a repo since February.

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?

Re: Introducing Ampersand.js

#72

Post by gitaarik »

STRML wrote: post #16
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...

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

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.

Re: Introducing Ampersand.js

#73

Post by theseoafs »

latentflip wrote: post #67
couchand wrote: post #66

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

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

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.

Re: Introducing Ampersand.js

#74

Post by johnzabroski »

HenrikJoreteg wrote: post #52
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 `…

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.

Re: Introducing Ampersand.js

#75

Post by acjohnson55 »

wiremine wrote: post #25
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...

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.

Re: Introducing Ampersand.js

#76

Post by thenduks »

mkishi wrote: post #60
thenduks wrote: post #21

Earlier quoted context omitted.

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

Yea that's fair enough. This is an initial release so I'm sure they are reading these comments and working to improve their site/docs/etc.

You're right that it's basically for Backbone users:

> We

> But we missed the focused simplicity of tiny modules in node-land.

Read as: "This is like Backbone.js (almost a forked Backbone.js) but better." (better from some perspective, at least)

Re: Introducing Ampersand.js

#78

Post by dzenanr »

spankalee wrote: post #22

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…

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.

Re: Introducing Ampersand.js

#79

Post by thekaleb »

johnzabroski wrote: post #47
spankalee wrote: post #22

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.

Or even Google Closure JavaScript.

Re: Introducing Ampersand.js

#80

Post by grwongku »

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