Brisket – A new single-page application framework | Hacker News Reader

Brisket – A new single-page application framework

bloomberg.com

68 pointsapaprocki61 comments

>>> We’ve been hard at work deploying Brisket to power three of the best and fastest sites on the web — BloombergView.com, BloombergPolitics.com, and BloombergBusiness.com.

Okay so after throwing up a bit at the hyperbole I played around with said sites. They feel fairly slow and loading different sections seems to be random how long it will take to register my click event. UX for showing page loading seems very limited and the differences in times of load for things feels very off.

Content sites like the ones Bloomberg mentions should not be done as single page webapps! The problem of rendering pages that have HTML on them has been solved - probably best to leave stuff like Brisket for apps that need it, like stock exchanges or real time analytics.

And those 3 sites render with javascript off(I guess thanks to "isomorphism")... which means they don't need to be single page apps at first place.

Which would you prefer, a full page refresh that will refetch a large portion of the page that you're already looking at or an ajax call that will return far less bytes than a full page refresh would have and then replacing only the parts of the page that needs changing?

Also if its truly isomorphic, everything would still work as usual if javascript is off.

I want the page I'm looking at to be mostly the content I'm interested in, so when I follow a link to get more content most of the page should be updated. Under those conditions, a full page refresh is preferable because it works nicely with the browser history, bookmarking, "Email this Link" feature, and anything else I might want to do with the page of content.

I should have prefaced my original question with "all other things being equal...".

I believe you can have browser history, bookmarking, email this link any thing else you might want to do with the page in a single page application and also get the benefit of not doing a full page refresh.

Single page application are reletively new and kinks are being worked out but if I could have my cake and eat it too, I wouldn't stand in the way of those trying to make that a reality.

How about loading the whole page on each click, and front caching the parts of the page (nav etc.) that are repeated on each page. This would have really good performance, and be simpler than building a single page app when one isn't really required.

>>> probably best to leave stuff like Brisket for apps that need it, like stock exchanges or real time analytics.

I had the same reaction and was confused, thinking they were going to add a bunch of real time data streams or something. After I re-read the article again, I realized they're not going to use it for something really useful to their industry.

Is this a good case for creating something where a need has already been solved a thousand times by several other frameworks?

Btw, does "Isomorphic Javascript" rub anyone the wrong way or am I the only one.

It seems like someone watched a Haskell tutorial and copied a smart sounding word and just appended it to Javascript. This used to be called "code reuse". But that doesn't sound as cool anymore.

Hear hear! It's even the wrong word. Isomorphic means "same shape", which that means that the "shape" of the code is the same between client and server on these apps.

Huh? What's the "shape" of code?

It's not actually the "shape" that's the same, it's the HTML that it produces. It would be more accurate to call this Isohtml or Isoproduce or Isooutput apps.

People say Isomorphic when they don't know what they are saying, and want to sound smart in greek. Idiots.

> Huh? What's the "shape" of code?

The code itself is the shape of the code, to an appoximation. Isomorphic applications run the same code (or big swathes thereof) on the client and the server, so that the common core exists only in one place.

> It's not actually the "shape" that's the same, it's the HTML that it produces. It would be more accurate to call this Isohtml or Isoproduce or Isooutput apps.

A port of an application would satisfy that criteria, but would not fall under the moniker of isomorphic. If you have a better term to qualify applications with extensive to almost complete code-sharing between the client and the server, feel free to try and popularise it, but so far your demonstrations have been sorely lacking.

> People say Isomorphic when they don't know what they are saying, and want to sound smart in greek. Idiots.

Heh.

> This used to be called "code reuse".

Code reuse intuitively has a much smaller scope, you can use a function on both sides it's code reuse, you can use your templates on both sides it might be (pretty advanced) code reuse. The idea behind "isomorphic" applications is that almost all of the application runs on either side of the network, it's closer to multiplatform or portable computer applications where there's a low-level substrate papering over differences and everything above that is identical.

> It seems like someone watched a Haskell tutorial and copied a smart sounding word and just appended it to Javascript.

It's not completely nonsensical though, isomorphic objects are identical on the properties used to define the morphism. The idea behind "isomorphic javascript" is that you're running (more or less) identical applications on the client and the server.

Unfortunately, no one has yet come up with a better word to capture the idea for a shared codebase client- and server-side. I'm really hoping it happens soon, because the abusage of the term drives me insane, too.

It's more than just sharing code. It's all about your routes. In an isomorphic web framework: You write a single description of a route handler as a function from JSON to VDOM. That handler will load different dependencies on the client/server to create DOM/HTML. This is where the isomorphism thing comes from: the HTML generated on the server, once loaded by the clients HTML parser, will be equivalent to the DOM that would have been generated on the client. You could of course do this normally but you'd be responsible for maintaining a server operating on HTML in coordination with a client operating on DOM. An isomorphic web framework unifies these two worlds.

An isomorphic framework itself is effectively a proof (in the mathematical sense) of the statement: client-side rendering and server-side rendering are isomorphic.

That still seems like an overly pseudo-mathy way of describing that you render some data structure (possibly just a string, in the case of Rendr), and then the framework produces either HTML or DOM operations. Regardless, to my knowledge, it's not necessarily the case that isomorphic frameworks produce VDOM, rather than HTML on both sides. If I'm reading their site right, Meteor only seems to have gained VDOM-like functionality with the release of Blaze less than a year ago.

Totally agree on VDOM, it's an implementation detail.

I also agree that isomorphic is an intimidating and esoteric term. There are examples however, like the word function, which are "overly psuedo-mathy" in exactly the same way. The mapping between rendering technologies is basically an isomorphism. Each category has objects (html OR dom) and a we can map them with the html parser (html => dom). Each category has morphisms (json => html OR json => dom) and we can map them between by loading the client modules ((json => html) => (json => dom)). Finally, for some json input (J), a renderer (R) and a function (F) that performs those mappings, the framework ensures that: F(R(J)) === F(R)(J). That's not exactly an isomorphism but it's VERY similar.

Its an old concept. It describes the same code running on both the client and the server. Its been called isomorphism for at lest 20 years, when it was first used in networked video games.

It mainly rubs me up the wrong way for reminding me there is an all-too plausible future where I'll forced to write javascript on the server. :-(

I feel your pain, but you're wrong. There are lots of languages that compile to JavaScript, so there's an even-more-plausible future where you can continue writing in your favorite server-side language.

Yes, but without an obviously better coinage it may be entrenched (especially given ~adrusi's testimony it's been used for at least 20 years in the context of networked gaming).

Any proposals?

In 10 seconds the best alternative I've come up with is "Clerverable", as in "CLient-or-sERVER-ABLE". HEY DON'T SNICKER ALL IDEAS ARE OK IN THE BRAINSTORMING PHASE. And this term 100% solves the problem of people sounding pretentiously-smart when they say it.

(So far 'isomorphic' seems pretty secure.)

Brisket also depends on the following libraries:

jQuery ~1.11.1 jsdom ~0.11.1 Underscore ~1.6.0 Backbone ~1.1.2 bluebird ~2.2.1 jquery-mockjax ~1.5.3 express ~4.0.0 qs 1.2.2

ಠ_ಠ

LOL!

Are you suggesting that's a lot? Or just making an observation?

What a joke! Whats wrong with using those dependencies by themselves? YAJSL (Yet Another JS Library)

Unless they're using jquery-mockjax for anything other than testing, I don't see anything strange about this list, old versions of some libraries?

Hmm, it seems like that is a bit out of date. Look at package.json for a more accurate list of dependencies. I'll get that cleaned up.

https://github.com/bloomberg/brisket/issues/119

Link to actual GitHub repo:

https://github.com/bloomberg/brisket

At a glance it looks unnecessarily heavy but nice to see more open sourcing.

What exactly is a "single-page application"?

Wikipedia states that it "is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions." [1]

How is this any different from any other web application?

[1] http://en.wikipedia.org/wiki/Single-page_application

Consider a page like wikipedia. Every time you click on a link to another article a new request is made, the page is loaded along with all its dependencies and resources.

A SPA would instead only get the text of the new article and write it in place. Therefore, removing the need to re-download the entire page again. You can also read about this in the blog post by bloomberg: http://www.bloomberg.com/company/2015-03-24/bloomberg-weve-m...

A little misleading since most of the non-article content (e.g. javascript, CSS) is cached locally by your browser. You can also utilize AJAX to have responsive user interactions as needed.

I think the main distinction is that there's only one HTML document that ever gets loaded during the course of your usage of the app. In other words, you never have to navigate anywhere else.

Or are you making the point that anything that doesn't function this way isn't really a web application?

No, what I didn't initially understand is that only one page is loaded (and then reused, etc).

They way I think about it is like this:

SPA looks more like a mobile app. As you click the links the page doesn't refresh, content just gets replaced dynamically.

Traditional web page honors web standards a bit more and looks like the traditional structure of pages linked with hyperlinks. Want to read about the product? Click a link. Want to refresh the current price? Click refresh button.

Tomayto Tomahto

Both great with a little salt.

It's different in that before you might have:

home.html profile.html group.html

and all of those pages are literally different views and you use ajax to grab the data.

Now you build:

index.html

with subviews and essentially index is doing all of it. Picking your subviews, handling making urls, rendering, making the requests.

I still haven't found a "class" of app that is "better" with SPAs. Just about anything you would do with an SPA you can do another way. SPAs are just the "cool new thing".

This is a pretty good explanation, and I'd also add that SPAs move away from the traditional server-structure URL path mentality, which wasn't very user friendly and never really needed. Now URLs are kept mostly for sharing or bookmarking.

i.e. www.domain.com/user/profile/update.html can just be handled in index.html

By "traditional server-structure URL path mentality", do you mean the mapping of URLs directly to static files on the filesystem? If so, I'd argue that's a separate issue from SPA vs. MPA. After all, most MPA frameworks, like Django and Rails, break that equivalence. URLs map to controllers, rather than particular templates.

I meant the mentality, which started with URL static file mapping and continued with web routing. Not all URL path routing is bad, but with SPAs you get more focus on what the customer uses URLs for (i.e. URL paths for sharing a picture, etc.) rather than parsing page functionality out across different paths.

It's my opinion this URL simplicity makes a better user experience, but that's just my opinion.

Typically when I hear "Single-page application" I think of web apps that perform a dirty trick like starting out logged in making the main content section of the page an empty <div id="content"/> and letting some javascript add the necessary dom elements as information about them comes available through some asynchronous request.

Clicks on page elements that represent some user interaction with the app should usually not trigger a whole-page reload, but instead fire some On-Click action resulting in (maybe) some data being sent to the server and (maybe) some new content being added or updated on the screen without changing the URL of the loaded page.

The client might long-poll or maintain a websocket so that new information from the server can be received without a user action. These are the types of patterns you don't normally see in "any other web app" that differentiate an "Web 2.0" SPA from "old-school Web 1.0" applications.

Push solutions like long-polling and websockets are a separate concern. It's perfectly possible to use those technologies in a web app that's primarily still multi-page, such as a stock ticker on an otherwise static page.

I would draw the distinction in navigation. Are links primarily triggering built-in browser navigation (MPA) or are they handled by long-running in-browser code, backed by asynchronous requests for additional server data (SPA)?

Traditionally, web applications used sessions to maintain state while the user navigated the interface, with full page reloads for every screen (typically visible as a blank white page as the next screen loads from scratch).

By contrast, single-page application (SPA) architecture holds session state in a long running in-browser Javascript application. This style is particularly strong when user actions only need to modify a portion of the screen.

As an anecdote, the websites did seem to load slow for me. And as a previous commenter has added, I'm not sure a news hub is best suited as a SPA.

How do we feel about USA Today (http://www.usatoday.com/)? That's a Backbone SPA and it seems to work quite well (though the adverts cause some loading unpleasantness from time to time).

It's certainly highly debatable as to whether there is any genuine benefit in presenting a text-heavy (in theory) site as a SPA. Bloomberg does the moderately clever "one article follows another article" thing, which I personally quite like but others here were fairly negative about.

(though the adverts cause some loading unpleasantness from time to time)

It seems most sites that have speed/responsiveness/usability problems, get those problems mostly from their ads. It doesn't reflect well on the site or on the ad. I suspect it's because the metrics ad networks are using don't capture their crappy performance. I wish the original sites themselves would track ad problems and thus drive SLA compliance.

Agreed! With MPA, at least I can tell the browser's working. I don't think it's hopeless to do SPA for a news hub, but to me it seems like they should at least be prefetching to make transitions to new content seamless. They provided precious little context for how they're actually using SPA to enable them to do anything they could accomplish with MPA and caching.

The article itself is all fluff and big claims with very little info about what's novel here. I'd expect better from a news org.

SPA adds few advantages and possibility. For instance, the new bloomberg.com has infinite scroll of articles. And, new articles appear seamlessly at the bottom. This would be very clunky to do with non SPA approach. With SPA they can combine static htmls with dynamic content.

I don't think you need SPA just for infinite scroll. You could have a regular page that loads some minimum number of articles, then just add a little javascript to that page to ajax fetch articles as the user scrolls.

I find it interesting that this is coming through their main news channel (main website and Twitter), rather than a side channel, like an engineering blog.

Feels like April Fool's Day reading this.

When I saw the trademark, I immediately thought the same: Brisket™

And since I live in Austin, I feel especially offended for Yankees trademarking deliciousness.

I'm also in Austin and thought, "this is the most Austin named framework."

I'm in Austin too, we need to hurry up and make the Breakfast Taco™ framework before someone else does.

You joke, but I've heard worse names for frameworks.

Reminded me of @horse_js posts on Twitter haha.

I find Bloomberg an interesting company. The first start-up I worked for made all their money selling software to Bloomberg. Now Bloomberg is recruiting JavaScript programmers on my Uni campus offering salary on par with Twitter. Maybe they want to be hip ? who knows.

At first glance this just looks like a Backbone wrapper.

Is "brewery" the new "factory"? https://github.com/bloomberg/brisket/blob/master/docs/briske...

Brisket, breweries, and routers should never be mixed. The symbolism here is so disquieting.

Although I loved the open-source initiative, I'd be wary while taking it as a framework.

Wait. Did I wake up in 1988? Isn't this Hypercard?

greaaaat another front-end js framework, as if we didn't have enough already -_-

I wouldn't get too worried about needing to add Brisket to your bag of tricks anytime soon.

Reply on news.ycombinator.com