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

81–90 of 100 posts

Re: Ember Fastboot

#81

Post by mhart »

tomdale wrote: post #6
__derek__ wrote: post #5

Earlier quoted context omitted.

It's been possible with React for quite some time[1], and it appears to be included in Angular 2[2]. [1]: https://github.com/mhart/react-server-example [2]: https://angular.io

Sorry to nitpick, but I don't think the React example is an analogous initiative. ;) There is a huge gulf between "synchronously render a component in Node" and "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently." I touch on this a little bit in this talk[1], but the bulk of the work we've done over the last year is conventionalizing app boot and figuring out how to run multi…

Author of the simple React example here – Tom says there's a "huge gulf", but forgot to mention there's literally an example[1] of an asynchronous routing and data fetching app linked to in the first section of that page that's a logical progression of the first. (and others have pointed out much more complex examples you can achieve with React if you so wish)

The goal of those small examples is to illustrate that you don't need complex frameworks to achieve server-side rendering with data fetching and routing.

I have no doubt that FastBoot was a huge undertaking, and I think a large part of the reason for that is that it's aiming to fit into a very comprehensive existing framework, with pieces for routing, fetching data, "application instances", etc – there's a lot more work involved in that (for the framework author I mean, not the end user) than there is starting off with just a view library and adding your own pieces around that.

1: https://github.com/mhart/react-server-routing-example

Re: Ember Fastboot

#82

Post by alanning »

lotyrin wrote: post #3

This is great! Anyone know how far analogous initiatives are for competing projects?

FastRender [1] for Meteor is a similar but not analogous project. Similar in that it improves initial render speed. Different in that it does so by delivering the data required to render the page along with the initial payload so things are still client-side rendered, not rendered for you on the server.

For what its worth, FastRender was first released in 2013. The just-released Meteor 1.3 now has ES2016 module support which should enable more improvements in this area.

1. https://meteorhacks.com/fast-render-internals-and-how-it-wor...

Re: Ember Fastboot

#83

Post by mschoening »

tucosan wrote: post #44
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.)

What is the font face you use for the logotype? It looks quite nice.

A slightly modified version of Tablet Gothic (https://typekit.com/fonts/tablet-gothic).

Re: Ember Fastboot

#84

Post by gavinjoyce »

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?

We're running Ember 2.2 on Intercom and we've found it to be faster than 1.x. In addition to this, it looks like Glimmer 2 will bring significant render time improvement for both initial render and subsequent DOM updates.

Re: Ember Fastboot

#85

Post by awalGarg »

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

Most frameworks I have used (yes React included) don't require any of those. Their documentation is lacking/confusing, and the community build "documentation" is not designed to bring a newbie from the newbie level to the guru level gradually - it is designed for jumping straightway up. Several hundreds of "starter" templates are one good place where the dependency bloat starts because the template maker wanted to cover every single usecase ever, but not help the user start (see the irony?).

You can very well use React/Angular(1, atleast)/etc. just by including a script file in your markup and continuing to write your application code. There was a tutorial series for React posted on HN sometime before that made you learn React just this way.

Re: Ember Fastboot

#86

Post by staticelf »

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

I use Ember everyday. But still I don't understand the most basic questions:

What is this? And why should I use it? I slummed through the quick start but that didn't make me any wiser.

EDIT: I read up on your blog post and you guys should definitely put some of that into the web page.

Re: Ember Fastboot

#87

Post by Kiro »

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…

With Django, RoR etc all subsequent navigation would require full page reloads while this only does it the first time.

Re: Ember Fastboot

#88

Post by orf »

takno wrote: post #80
orf wrote: post #69

Earlier quoted context omitted.

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

It really isn't. Jumping into using a huge performance sink like ember to add a little interactivity to a content page is a horrible decision to start with. This just seems to drag the poor performance back to kill your server

That's a straw man though. Sure, adding Ember for a "little interactivity" is kind of stupid. But if you want to add a lot of interactivity? Is a load of "$.click" function soup better?

Re: Ember Fastboot

#89

Post by reitoei »

hatsix wrote: post #53
sotojuan wrote: post #20

Earlier quoted context omitted.

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.

> haven't gone through setting up production yet, but I don't foresee any big issues

Famous last words :)

Re: Ember Fastboot

#90

Post by e12e »

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…

> I think FastBoot is a great option for (...) supporting JavaScript-less clients.

Wait, is one use-case that works out of the box to have a view that works both in text-mode browsers, like w3m and lynx (or graphical browsers with js disabled due to security or other reasons), and also "ramps up" to work well as "regular" SPAs?

Because that's one thing I've yet to see anyone really pull off: being able to define sane, simple components/widgets that also works reasonably without javascript (eg: the ability to render data as a table, and have click-able headings for sort that works both in lynx and without hitting the server in a modern js browser).

[ed: It certainly appears that http://www.ember-fastboot.com/docs/user-guide works well enough with js off, except for a couple of images not rendering.]

Post reply on HN