Cooking With Brisket
•Als PPTX, PDF herunterladen•
0 gefällt mir•796 views
Brisket provides the tools that you need to spend your time focusing on your application's logic rather than on "what environment is my code running in?". He will talk about why they started the project, stumbling blocks they found, and experiences building applications with it. Wayne will demo a simple app built with Brisket and illustrate what separates Brisket from every other isomorphic framework out there – “code freedom”, a familiar “just Backbone” development experience, and tools to enable developers to build robust applications.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Cooking With Brisket
- 1. Wayne Warner / @wawjr3d Cooking with Brisket
- 3. Reception
- 4. 1736 1524 8586 3764 1475 3384 1548 1808 900 700 2426 3574 712 2278 1019 1502 BloombergView.com Bloomberg.com Bing.com USATODAY.com Speed matters
- 6. Reception
- 8. Our MANDATE Build a site that serves HTML from the server AND behaves like a single page application on the client side
- 9. Why did we want that?
- 11. What we want 50% 0% 50% Standard site code breakdown 10% 80% 10% Code breakdown we want Server Shared Client
- 14. How do we code how we want?
- 15. BRISKET Bloomberg’s Isomorphic application framework Template Adapters View Rendering Workflow Routing Data Bootstrapping View Reattaching express Engine Child View Management Environment Agnostic MVC
- 16. A taste of Brisket
- 19. Stumbling Blocks
- 20. WINS
- 21. CONSUME npm install brisket FORK THE BRISKET!! http://github.com/bloomberg/brisket
- 22. Questions??
- 23. THE END Barriga llena...corazon contento!!
- 24. Photo Credits • “Art of sharing” by Frits Ahlefeldt-Laurvig • “Happy Panda Has Bamboo” by Joseph Bylund • Chef picture - http://pixabay.com/p-23462/?no_redirect • “Funny sign: Tripping Hazard” by Jonathan Colman • “A wild question” by Raymond Bryson • “Confused chimp” by Tambako The Jaguar • “148073543DI00120_Olympics_D” by Trcanje Rs • “Do not confuse…” by Stéfan
Hinweis der Redaktion
- Good afternoon. thank you all for coming today. My name is Wayne Warner. I am a senior front end engineer at Bloomberg. As part of Bloomberg’s Consumer Web team, I work on some of Bloomberg’s most popular products like Businessweek, and bloomberg.com. For the past year, I’ve been leading development on a series of new sites designed to reposition Bloomberg in the digital media space.
- The first product that we built was BloombergView - bloombergview.com for those who havent seen. BloombergView is our opinion site. It houses some famous contributors that some of you may know like Megan McCardle, Matt Levine and of course the boss Mikey B. We started work on BloombergView a little over a year ago. We built it completely from scratch with a new tech stack in about 3 months. We launched it on February 25th
- Bview was well received by the community not only for it’s design but for how fast it feels. The coolest comment I heard came from Mikey B himself. He told us that it was the best mobile experience he’s ever had on a website
- Speed Index is a measure of user’s perceived speed, i.e. the time it takes for the user to fulfill intent. (Lower is better) Compare BloombergView.com to Bloomberg.com, Bing.com, Yahoo Tech, and USA Today. Green is the first load and blue is the subsequent load BloombergView articles feel the fastest to users and are comparable to the performance of the Bing.com homepage BloombergView homepage feels ~5x faster than Bloomberg.com and is comparable to the USATODAY.com homepage
- no rest for the weary though. we set out to build the next one. it ultimately turned out to be BloombergPolitics. For BloombergPolitics we had a whole different design direction. after the success of bloombergview, the expectations were even higher. politics was certainly a more challenging product than bloombergview and we were able to get it out in less time we started work on politics around august and had it out by oct 6.
- Things went pretty well. Politics was another success. it changed the narrative on Bloomberg’s web products. quote from strup’s friend get quote from famous dude on twitter despite the picture, im not so sure how happy joe biden or herman cain were about the launch
- Now with expectations EVEN higher, I am working on building the new Bloomberg Business. we just announced that Bloomberg Business will be the successor to both bloomberg.com AND businessweek.com. we’re working hard on the site right now. we’re planning to launch the new site in late january
- Going back to the beginning Our goal was to write our app once
- historically all of our products had been rails apps on the server side with some combo of Backbone and jquery soup on the client side. Not sharing things like templates, validation rules, etc From a tech perspective, our code would often be disjoint with a part of it in rails world and another part in css land, and yet another part on jQuery island. From a product standpoint, because we were only building traditional sites, we couldn't build the best experiences for our users however we couldn't afford to lose the SEO power that is so vital to digital media products So we want the best of all worlds - fast between pages, interesting experiences while keeping the SEO power, progressive enhancement
- The only solution is isomorphic javascript the term isomorphic javascript refers to javascript code that can be run in any environment - server or client. like most people, we got our feet wet with isomorphic by investigating if we could share templates. it didn't take long to figure out ok we can share templates. what else can we share? can we share data models? what about application logic? why not EVERYTHING?
- Before we started writing these isomorphic apps, we didn't really share ANY code between client and server. about half of our code rendered content on the client and half on the server. we wanted to share everything. realistically, it’s not possible to share all the code. the browser and the server have different responsibilities (browser serves 1, server serves many) and also different tools available (window vs process)
- Building this sounds terrifying and hard (if not interesting). Whats out there? At the time, only Rendr was available. Rendr is also an isomorphic javascript framework that is based on Backbone Rendr works. No control over code organization As you can see in the example:
- the code style was extremely prescriptive. as you can see in the code example, while controllers are simple, the boilerplate is awkward we want to use advanced techniques like in-application event bubbling, and on the fly View creation. we couldn't figure out how to do it in rendr so
- how can we do something as seemingly complex as run our app on both client and server while also being able to write it any way we want?
- All of our new consumer products are powered by Brisket. Brisket is an isomorphic javascript framework designed to let you focus on your application logic rather than “what environment is my code running in?”. It endeavors to give you maximum “code freedom” while providing you all the tools to make an application that runs agnostic to it’s environment Brisket is based on Backbone so it uses all the familiar MVC tools - Model view router. Built on promises rather than callbacks. Async code should feel flat Just some of the features that Brisket provides: environment agnostic models, views, routers, express engine highly configurable graceful degradation in older browsers There are many subsystems that make brisket work. each one could probably be it’s own talk. due to time, i’ll only touch on them at a high level. feel free to reach out to me after the talk if you want to get more in depth
- open terminal, run yo brisket && grunt show express server entry point to the application on the server is ServerApp (server specific instrumentation) highlight console output of server start use chrome for the side console view entry point to the app on the client is ClientApp (jquery plugins) highlight browser console of client start highlight, as clicking around, what ajax calls/work is happening. highlight mocking view source - show actual code highlight Router code looks similar to backbone Look at model highlight View is missing render method, Brisket rendering methods look at some more complex examples (onDOM, using normalized request, Clientside only initialization)
- a request begins when the user enters a url that request is funneled to express which forwards onto to your application (backbone rendering engine) the input to the black box is a request, and the output is a single Brisket View. the View is passed to the server renderer and combined with the layout then returned back to the browser.
- once the view reaches the browser, your application picks up where it left off to on the server. now your View is animated and ready to handle user interaction then when you click a link in your application, rather than heading all the way back to the server, the request is handled by your application in the browser. your application works the same as on the server - it accepts a request, and returns a View. your view is sent to the client renderer which updates the content in the layout
- while brisket has completely transformed our workflow, it’s not without it’s stumbling blocks the framework isn’t done - we don't know all the use cases, no stackoverflow unopinionated so you HAVE to form your own. we want that when we have free time to make opinions it is hard to let go of “where my code runs” it is hard to let go of jquery soup and even spaghettified backbone sometimes you forget your code runs on a server. singletons and not cleaning up events leads to memory leaks how do we interop with tools not designed for brisket? e.g. jQuery
- Tech write the code once incredibly high perceived speed (only thing stopping us is fonts) site works in all environments without much extra thought (e.g. javascript is off, mobile, search engines) “Code freedom” Organization SEO much more flexible (we could run a our app as server side only or client side app if we wanted) tech team speed - writing code once, we are turning out much more in less time shared knowledge on the server side and the client side Overall, I think it’s been a great experience.
- Please fork the project on github. we open sourced it because we’re genuinely interested in not only feedback but help solving some really interesting problems. we want the consumer web team to be a member of the open source community. please contribute