JSFoo 2014

JavaScript as the centerpiece of a complex web stack

In 2011, Node.js put JavaScript firmly in the backend, making JavaScript developers productive at both ends of the stack, and making it possible for business logic to finally be moved into JavaScript.

In 2012, AngularJS made us think about moving business logic completely into the client-side as an actually sensible idea. Meteor give that idea two thumbs up.

In 2013, we went wild thinking of all the possibilities. JavaScript phones! Robots!

In 2014, it’s time for some sobering up. The backends we built over a decade in Ruby and Python aren’t going away. New languages like Go and Hack are tantalising us with new possibilities. Our applications are increasingly distributed, often involving third party APIs. In such a scenario, where does your business logic reside?

In 2014, JavaScript is no longer a toothless child or a rebellious teenager that wants to do everything itself. JSFoo 2014 is about working with JavaScript as the centerpiece of a complex web stack.

Format

This year’s edition spans four days, with two days of workshops and two days of conference. All days feature a single track. We invite proposals for:

  • Full-length 40 minute talks
  • A crisp 15-minute presentation
  • Sponsored sessions, 40 minute duration
  • Flash talks of 5 minutes duration. Submissions for flash talks will be accepted during the event
  • Three hour workshops where everybody gets their laptop out and follows along

Criteria to submit

You must be a practising web developer or designer, and must be able to show how your own work has advanced the state of the web in the past year. You are expected to present original work that your peers — this event’s audience — recognise as being notable enough to deserve a stage.

If you are excited about someone’s work and believe it deserves wider recognition, we recommend you contact them and ask them to submit a proposal.

Selection Process

Voting is open to attendees who have purchased event tickets. If there is a proposal you find notable, please vote for it and leave a comment to initiate discussions. Your vote will be reflected immediately, but will be counted towards selections only if you purchase a ticket.

Proposers must submit presentation drafts as part of the selection process to ensure that the talk is in line with the original proposal, and to help the editorial panel build a strong line-up for the event.

There is only one speaker per session. Entry is free for selected speakers. HasGeek will cover your travel to and accommodation in Bangalore from anywhere in the world for speakers delivering full sessions (30 minutes or longer). As our budget is limited, we will prefer speakers from locations closer home, but will do our best to cover for anyone exceptional. If you are able to raise support for your trip, we will count that as speaker travel sponsorship.

If your proposal is not accepted, you can buy a ticket at the same rate as was available on the day you proposed. We’ll send you a code.

Commitment to Open Source

HasGeek believes in open source as the binding force of our community. If you are describing a codebase for developers to work with, we’d like it to be available under a permissive open source license. If your software is commercially licensed or available under a combination of commercial and restrictive open source licenses (such as the various forms of the GPL), please consider picking up a sponsorship. We recognize that there are valid reasons for commercial licensing, but ask that you support us in return for giving you an audience. Your session will be marked on the schedule as a sponsored session.

Hosted by

JSFoo is a forum for discussing UI engineering; fullstack development; web applications engineering, performance, security and design; accessibility; and latest developments in #JavaScript. Follow JSFoo on Twitter more

Himanshu Kapoor

@fleonus

Managing API Resources and Their Relationships on the Front-end

Submitted Aug 6, 2014

With the advent of Single Page Apps, a lot has changed in the world of web development. The days of server-side rendering are waning away, and the world is moving towards static HTML apps that communicate with a back-end API to drive the user experience.

Such transformation requires rapid communication between the Single Page App (front-end) and an API (back-end). This exchange of information brings about various challenges like maintaining consistency, optimizing for performance and scalability.

This talk would go over the challenges, we at Wingify, faced while making our Angular.js based Single Page App – Visual Website Optimizer. One of the core challenges is efficiently communicating with a back-end service. Finally, the talk would conclude with the solutions we came up with to tackle these problems.

Outline

This talk would detail problems faced with the seemingly trivial task of using Angular.js, to get and post data from a back-end API. I would go over these problems (questions) one by one, and propose a solution to them by providing relevant examples. These questions include:

  • Fetching data from the server is as easy as making an AJAX request, but as the app logic becomes complex, how do you avoid making your codebase a tangled mess of AJAX requests?
  • How do you ensure that multiple instances of the same resource are updated as soon as the resource is updated with the most up-to-date data, effectively maintaining a single source of truth across the app?
  • How do you handle relationships between two resources? Fetching a resource could require fetching another child or related resource simultaneously; how would you go about instructing the app to do so?
  • If you send a request to get something, how do you effectively cache its response so that you don’t have to send a request to fetch that resource again? How do you make sure that this storage mechanism performs well enough to return resources and sub-resources as quickly as possible?
  • An app would involve several instances where the user inputs data that is posted to the server. How do you ensure only what the user changed is posted to the server, effectively making the payload as small as possible?
  • The server might have its constraints when accepting data from the client. It could need some transformation before accepting a response. How would you serialize and transform this data before sending it to the server and still maintain consistency across the app?
  • Similarly, such transformation might be necessary before receiving the response from the server. How do you make sure that request serialization and response unserialization works consistently?

The challenges listed above are based on real world problems we faced while developing version 3.0 of our website optimization software – Visual Website Optimizer. While solving some of the problems above, we abstracted out a lot of solutions to these problems into a service for Angular.js.

Requirements

Intermediate knowledge of JavaScript. Experience with Angular.js desirable but not necessary.

Speaker bio

Himanshu is a front-end engineer at Wingify. He has been working with JavaScript for the past 5 years, and has done several projects based on front-end frameworks like Backbone, Ember.js and most recently Angular.js. His role at Wingify involves solving challenges related to data visualization, communication and performance optimization on the front-end.

Slides

http://www.slideshare.net/wingify_engineering/resources-and-relationships-at-frontend

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

JSFoo is a forum for discussing UI engineering; fullstack development; web applications engineering, performance, security and design; accessibility; and latest developments in #JavaScript. Follow JSFoo on Twitter more