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

Ember Fastboot

ember-fastboot.com

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Ember Fastboot

#51

Post by girvo »

tomdale wrote: post #9

One of the authors of FastBoot here. I'm happy to answer any questions anyone has. (P.S. One thing I think that's pretty meta-cool about the FastBoot site is that it is, itself, a FastBoot site, running on Heroku.)

Having implemented a similar concept using React (and Flummox), I'm curious how FastBoot solves the async data fetching problem; does it require the developer to be careful about how things are set up, or does a solution naturally fall out of how Ember works? Running what amounts to an event-loop once to get the HTML result wasn't that difficult, but ensuring that the app wasn't relying on said event-loop to render parts we needed out as HTML on the server was slightly annoying (but not insurmountable).

Re: Ember Fastboot

#52

Post by elliotec »

girvo wrote: post #50
elliotec wrote: post #48

Earlier quoted context omitted.

I love Ember. It seems to be one of the only sources of sanity and reason in this community.

> only sources of sanity and reason in this community Oh come on now, lets not be hyperbolic. I'm a massive fan of Ember, but I'm a bigger fan of Redux with React; the reason that Ember can afford to be opinionated is because the team is extremely smart and takes the best winning ideas from the outside "insane" community.

I'm not being hyperbolic, and I think the React ecosystem deserves a large part of the blame for this mess. I am totally aware that is an unpopular opinion.

The fact that Ember can distill the insanity of the community into an opinionated and usable framework (and also take wonderful ideas from things like Rails) is exactly what I mean by a source of reason.

Re: Ember Fastboot

#53

Post by hatsix »

sotojuan wrote: post #20
diegorbaquero wrote: post #10

Amazing work. Just read all of this: http://tomdale.net/2015/02/youre-missing-the-point-of-server... This is probably the thing I hate the most from client-side apps. Can't wait to test this and Angular 2 on production!

And I just read the quickstart[1], amazingly it only seems to take two commands to do (obviously just the basic example, but still). [1] http://www.ember-fastboot.com/quickstart

Good news is that on a medium-sized project (10s of routes and models), it still just takes two commands... haven't gone through setting up production yet, but I don't foresee any big issues.

Re: Ember Fastboot

#54

Post by morgante »

savanaly wrote: post #37
morgante wrote: post #32

Earlier quoted context omitted.

Honestly, it comes off pretty poorly for you to downplay the work of your competitors. It might be easier to get server-side rendering working with React, but pretending that it's not the same thing is just condescending. There are dozens of examples out there showing how to render React pages on the server, including fetching the necessary data for that rendering. The mechanisms you use might be different, but prete…

From one point of view (a user of the framework who doesn't care how the sausage gets made) they are analogous. But from the point of view of someone who developed the solution or who has to micro optimize the solution I believe tom dale is right that it is quite different. You're right that tomdale came off condescending (as he often does when promoting/defending ember...ah well). But it certainly isn't "duplicitous…

I'd say that both are analogous.

Analogous doesn't mean identical. The results are similar, even though what's happening under the hood is different.

Re: Ember Fastboot

#55

Post by morgante »

tomdale wrote: post #36
morgante wrote: post #32

Earlier quoted context omitted.

Honestly, it comes off pretty poorly for you to downplay the work of your competitors. It might be easier to get server-side rendering working with React, but pretending that it's not the same thing is just condescending. There are dozens of examples out there showing how to render React pages on the server, including fetching the necessary data for that rendering. The mechanisms you use might be different, but prete…

If I wanted to downplay competitors, why would I acknowledge that Angular 2 is doing something similar? Angular has much larger marketshare at the moment than React. It is fundamentally different, as I outlined above. That's not downplaying the work of React—they've done significant work in advancing the state of the art of DOM rendering that has hugely inspired the work of both Glimmer and Glimmer 2, as we have said…

> I'm not downplaying their work—it just really, really, really is not the same thing.

The methods might very well be different, but the result is the same.

Pretending that you can't do server-side rendering with React is not helpful and untrue. Just because they haven't put the same work into conventionalizing it does not mean that analogous initiatives don't exist for React.

There are plenty of guides and tutorials out there showing how to do server side rendering in React.

Re: Ember Fastboot

#56

Post by hardwaresofton »

look_lookatme wrote: post #28

Ember continues to be an antidote to the insane package/build madness in the JS ecosystem. It's opinionated for sure but it's also very easy to get started with.

While I love Ember, one of it's biggest downfalls is definitely has a longer ramp up period, and more complexity than other frameworks. Ember's documentation is very good now, but still, there is a lot you have to read (and eventually experience to truly understand) about how ember works under the covers.

One of ember's greatest benefits is that it adapts to change and doesn't miss out on features for very long at all (you can look at fastboot as a reaction to isomorphic react apps, or something that the ember team would have just pursued anyway). However, that benefit can also be a pitfall for newcomers to ember as it's hard to find consistent discussion, help, and resources for a framework that changes so fast.

BTW, while Ember CLI makes things much easier, it does not improve the complexity situation, it just becomes one more thing you have to learn when learning Ember (even as a newbie). What if a newbie isn't familiar with node? what if they're not sure why you're precompiling? what if they're not familiar with task runners like grunt and gulp?

Contrasted with frameworks like Angular 1, Backbone+Marionette, Ember definitely has the most rampup and complexity, not the least.

Re: Ember Fastboot

#57

Post by sotojuan »

hardwaresofton wrote: post #56
look_lookatme wrote: post #28

Ember continues to be an antidote to the insane package/build madness in the JS ecosystem. It's opinionated for sure but it's also very easy to get started with.

While I love Ember, one of it's biggest downfalls is definitely has a longer ramp up period, and more complexity than other frameworks. Ember's documentation is very good now, but still, there is a lot you have to read (and eventually experience to truly understand) about how ember works under the covers. One of ember's greatest benefits is that it adapts to change and doesn't miss out on features for very long at al…

I think the CLI helps tremendously, even if you have to learn it (and for simple stuff you don't aside from `ember new` and `ember start`, maybe a few file generators). The biggest problem with beginners is setting up a JS environment—I've seen people waste hours doing it. Ember's CLI tool takes care of all of that.

Re: Ember Fastboot

#58

Post by qaq »

Was just about to start a new app in Angular 2 because it seamed progress on fastboot was slow now might need to re-evaluate.

Re: Ember Fastboot

#59

Post by qaq »

tomdale wrote: post #9

One of the authors of FastBoot here. I'm happy to answer any questions anyone has. (P.S. One thing I think that's pretty meta-cool about the FastBoot site is that it is, itself, a FastBoot site, running on Heroku.)

Congrats on great feature. Do you guys have any solid plans on when rehydration might become available?
Post reply on HN