HenrikJoreteg

Then by all means, don't use it.

The point is that Apple's policies don't allow other browsers to actually compete on their platform. So users don't get to make the choice. All browsers on iOS have to be WebKit based by explicit policy that's the issue at hand.

It sounds like you like the default choice, and that's great for you. But if it's truly better, they shouldn't be scared to allow users to make a difference choice for themselves, no?

Any mention of specific APIs misses the point.

It's fine if they want don't want to implement everything.

The point is that if they don't get to simultaneously say:

1. The Web is a viable way to compete with native apps (which they explicitly said in defense in a current court case). 2. While not implementing features necessary to compete. 3. While not allowing anyone else to build a browser for iOS that implements the features necessary to compete.

I use graphql extensively as an API for apps I've built this way. But I don't feel like it really fundamentally changes very much in the client (other than much more efficient data fetching). But you still have to compose the data into the view the client is trying to render. Defining data requirements in components is nice in theory, I just personally don't know of any examples where this approach is being used successfully at scale. There may be examples I don't know of. Do you know of any successful large Relay apps?

Hey, author of the post here... reframe does seem very similar conceptually (I wasn't aware of it, thanks for the link).

Another interesting parallel between the two is that I implement a "loop" mechanism as well. Essentially, if no actions are fired for a while, and APP_IDLE action is dispatched which just updates "appTime" in redux store. As a result any selectors that depend on time as an input will recompute. This allows for actions to be fired over time based on age of the data, etc.

Elm and others are very cool. I just think a pure JS solution is nice, since that's what the browser runs.

Another way to put it selectors are a particular view of the data that's in the store.

Just to clarify, I'm not suggesting doing we should do full page refreshes or that we shouldn't be doing single page apps.

I'm all for minimal server-side interactions once loaded too.

Related advisories:

https://nodesecurity.io/advisories/qs_dos_extended_event_loo...

https://nodesecurity.io/advisories/qs_dos_memory_exhaustion

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

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.

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.

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

Yup, I don't disagree, this fact sucks. If you keep reading you'll notice I suggest not doing this for apps that aren't behind a login.

You can use login pages to prime caches, pre-render, etc. That's certainly not a panacea, but can help.

With the right cache headers on the main application assets and a primed cache you can start executing code immediately and eliminate all but your data calls on a good portion of app loads. From my experience, with a primed cache it's not too difficult to get comparable load times to opening a native app.

I'm hoping ServiceWorkers, Improved local databases, and HTTP 2.0 can help us out here.

There's also the option of trying to do the initial render server-side. I've experimented a bit with this, and have some more thoughts and approaches I want to try for this. But, I have yet to see someone do this is a way that didn't add a significant amount of complexity to the codebase :-/

Oh, got it. I misread the original comment.

My main point was just that it's never felt right for me personally when I try to write too much logic into templates directly. Because at the point where you hit the limit of what that abstraction supports you now have to solve that problem outside of the abstraction, fragmenting your code.

/me shrugs

It's all about how much you actually need to customize beyond what you get from something like angular out of the box.

I'm not wanting to fight a framework war, that's for sure. If angular works well for someone, that's awesome they should keep using it.

The item you pointed out in the second quote, yup... that's a big deal for us.

Sencha/ExtJS does certainly give you a lot of stuff out of the box, which is really cool. The main pain points I had were when building with it emerged when I had to do something that wasn't supported out of the box.

Picking the right abstraction layer is a fine line to walk. As you pointed out, there's tradeoffs on both sides.

Haha, this is an epic typo :) Sorry, will fix.

It's merely an opinion, to each their own. If AMD works well for you, that's great.

It seems a tad silly to argue about price when it's free, no? ;)

If you pick up a single tip that saves you an hour of effort you've paid for the book.

Browserify has had source maps since v2: http://thlorenz.com/blog/browserify-sourcemaps

Just pass {debug: true} to build function.

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

Here it is, it's really simple: https://github.com/andyet/signalmaster

It's what we use for this (I wrote it).

you need to enable the peerconnection flag in about:config for the nightlies

dust looks neat, for sure.

Judging by the response, it appears to not be basic knowledge. But, I'm glad to hear that you and others are taking a similar approach as I think it just makes a lot more sense as a concept.

Perhaps I should have been a bit more specific. I don't really care so much about how you do it whether it's with jade or handlebars + grunt or whatnot (I happen to like jade). The main point is that pre-compiling and sending JS functions instead of strings is way faster and makes more sense.

You can just pre-process them with node and then use the generated template functions in whatever app you want. It's just client-side JS at that point. This isn't unlike pre-process SASS, or SCSS, etc.

care to elaborate?

That's a pretty awesome hack.

We've been enjoying it a lot at &yet. We use it for daily checkins and developer discussions. Like a private mailing list... without the mail :)

It's helped pull our team together and give a better sense of how people are feeling about their work and progress.

That's been huge for us.

Thanks! We've got lots of interesting integration ideas in the pipeline. Stay tuned :)