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

61–70 of 100 posts

Re: Ember Fastboot

#61

Post by hardwaresofton »

sotojuan wrote: post #57
hardwaresofton wrote: post #56

Earlier quoted context omitted.

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.

I agree it helps -- but there is a hidden cost of people not understanding all the towers of abstraction that have been built up for them, despite sitting on top of it.

Ember CLI does file generation and a whole lot more. I'm not saying it shouldn't -- but that shouldn't be the easiest most approachable way to start with Ember.

Why should someone have to learn all the following things:

- transpiling

- nodejs

- npm & packaging

- bower

- broccoli/task runners

- livereload

... just to START with a web framework?

Maybe don't market Ember to beginners? Again, I like Ember, I think it's the most viable large framework out there right now -- but this is certainly an issue

Re: Ember Fastboot

#62

Post by zilean »

girvo wrote: post #51
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 p…

Ember has default model() hook for routes, and propose to add extra data fetching you need in children components into afterModel hook.

Everything is working just like you would set it up with React, except that with Ember declaring data dependencies on route is existing convention. And React gives you maybe a little bit more control around that.

Re: Ember Fastboot

#63

Post by qaq »

hardwaresofton wrote: post #61
sotojuan wrote: post #57

Earlier quoted context omitted.

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.

I agree it helps -- but there is a hidden cost of people not understanding all the towers of abstraction that have been built up for them, despite sitting on top of it. Ember CLI does file generation and a whole lot more. I'm not saying it shouldn't -- but that shouldn't be the easiest most approachable way to start with Ember. Why should someone have to learn all the following things: - transpiling - nodejs - npm &…

For the 3 major frameworks it's about the same list (minus bower but Ember is phasing it out too.

Re: Ember Fastboot

#64

Post by girvo »

zilean wrote: post #62
girvo wrote: post #51

Earlier quoted context omitted.

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

Ember has default model() hook for routes, and propose to add extra data fetching you need in children components into afterModel hook. Everything is working just like you would set it up with React, except that with Ember declaring data dependencies on route is existing convention. And React gives you maybe a little bit more control around that.

> declaring data dependencies on route is existing convention

That makes sense, I believe that's exactly what react-async does (if I recall correctly?) with react-router.

For our project, we basically call "await ApiActions.getData(routeParams)" in the server's route, after pulling that params out, which is effectively the same idea, and it worked quite well. I'm curious how one would tackle that from a different perspective, but it seems we all end up coming to the same conclusion!

Re: Ember Fastboot

#65

Post by sandstrom »

clessg wrote: post #43
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.)

How is initial render performance currently? If I recall correctly, Glimmer 1.x unintentionally slowed down initial render performance. Has this been or will this be addressed?

There were some regressions, but it's back on par since the last few releases (2.3+ or so).

In addition, Glimmer 2 is near completion, and when ready will provide further speed ups to initial rendering.

Re: Ember Fastboot

#66

Post by mtberatwork »

tomdale wrote: post #24
jakubp wrote: post #15

Earlier quoted context omitted.

Hi, I'm new to Ember and more complex JS apps in general. Can you confirm my initial "understanding" of what you did? Normally Ember app would render everything within the browser after all JS is downloaded and components etc. are processed. With Fastboot, somehow an additional, non-interfering layer of computation on the server does the same loop (without having to download anything and without significantly slowing…

With Fastboot, somehow an additional, non-interfering layer of computation on the server does the same loop (without having to download anything and without significantly slowing down overall client app JS initialization) Right. Typically, the way most client-side JavaScript applications (or "SPAs") work is by having a small, static HTML file that doesn't contain much content (beyond maybe a loading page). It contain…

> When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser.

Aren't we now just back to square one again in terms of MVC frameworks? What are the advantages here over simply implementing Django, RoR, Spring, Laravel, etc and cutting back on the JS (at least in terms of content-driven sites)?

Re: Ember Fastboot

#67

Post by sotojuan »

hardwaresofton wrote: post #61
sotojuan wrote: post #57

Earlier quoted context omitted.

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.

I agree it helps -- but there is a hidden cost of people not understanding all the towers of abstraction that have been built up for them, despite sitting on top of it. Ember CLI does file generation and a whole lot more. I'm not saying it shouldn't -- but that shouldn't be the easiest most approachable way to start with Ember. Why should someone have to learn all the following things: - transpiling - nodejs - npm &…

Good points, though I'll say I've rarely seen Ember be recommended to beginners.

And to be fair, the same thing has been said about React, though both Ember and React allow you to use a CDN link like in the good old days.

Re: Ember Fastboot

#68

Post by orf »

sotojuan wrote: post #67
hardwaresofton wrote: post #61

Earlier quoted context omitted.

I agree it helps -- but there is a hidden cost of people not understanding all the towers of abstraction that have been built up for them, despite sitting on top of it. Ember CLI does file generation and a whole lot more. I'm not saying it shouldn't -- but that shouldn't be the easiest most approachable way to start with Ember. Why should someone have to learn all the following things: - transpiling - nodejs - npm &…

Good points, though I'll say I've rarely seen Ember be recommended to beginners. And to be fair, the same thing has been said about React, though both Ember and React allow you to use a CDN link like in the good old days.

> I've rarely seen Ember be recommended to beginners.

I started a new job and went from 0 JS (other than some JQuery and knowing the syntax) to 100 with Ember. Ember is really really good for beginners, grandparent talks of having to know transpiling, broccoli/task runners and livereload but doesn't understand that you need to know none of that to get working with Ember.

Write your app by editing the files ember-cli produces. No transpiling, or add transpiling with a single 'ember install' command. Who cares about broccoli, I just edit my ember-cli-build.js file with some paths and it all works. Livereload is hardly difficult to understand, with Ember you just run "ember serve" and it also all just works.

Re: Ember Fastboot

#69

Post by orf »

mtberatwork wrote: post #66
tomdale wrote: post #24

Earlier quoted context omitted.

With Fastboot, somehow an additional, non-interfering layer of computation on the server does the same loop (without having to download anything and without significantly slowing down overall client app JS initialization) Right. Typically, the way most client-side JavaScript applications (or "SPAs") work is by having a small, static HTML file that doesn't contain much content (beyond maybe a loading page). It contain…

> When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser. Aren't we now just back to square one again in terms of MVC frameworks? What are the advantages here over simply implementing Django, RoR, Spring, Laravel, etc and cutting back on the JS (at least in terms of content-driven sit…

> What are the advantages here over simply implementing...

You get all of the advantages of single page apps, without the unresponsive initial load time. There are also whole classes of apps you can't build with Django, RoR etc, so the question is a bit ridiculous IMO.

Re: Ember Fastboot

#70

Post by hardwaresofton »

sotojuan wrote: post #67
hardwaresofton wrote: post #61

Earlier quoted context omitted.

I agree it helps -- but there is a hidden cost of people not understanding all the towers of abstraction that have been built up for them, despite sitting on top of it. Ember CLI does file generation and a whole lot more. I'm not saying it shouldn't -- but that shouldn't be the easiest most approachable way to start with Ember. Why should someone have to learn all the following things: - transpiling - nodejs - npm &…

Good points, though I'll say I've rarely seen Ember be recommended to beginners. And to be fair, the same thing has been said about React, though both Ember and React allow you to use a CDN link like in the good old days.

Yeah, Ember maybe shouldn't be recommended to beginners... I think it has some of the best documentation however (especially true in recent versions, if your codebase is pre-1.10, you're donezo though).

Also react's documentation is terribad. I'm in the middle of teaching someone who is completely new to JS how to use React, and the documentation has been horrendous (for newbies), reasons:

- JSX is super hard to properly understand if you only know HTML and JS and don't know they normally don't mix, and aren't actually mixing

- Requiring precompilation (no more JSXTransformer, no more babel-browser)

- The entire concept of components-all-the-way-down

- Documentation (Reference) section that does not differentiate between code blocks you can use and function signatures

- Hints on how to deal with routing

- No explanation of where to store data/state

I, as an experienced developer, can very easily understand React (I've used it on 2 projects now I think, and I like it), but there is so much for beginners to stumble on.

Post reply on HN