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.
AR
Abhinav Rastogi
@abhinav_rastogi
UI @ Flipkart: A Node Direction
Submitted Aug 10, 2014
Section:
Full talk
Technical level:
Intermediate
Flipkart.com sees a pretty huge number of daily visitors across the website. Serving content to them, reliably and efficiently is a problem which is only getting more complicated with more users connecting to the internet via mobile and more users getting comfortable with online shopping.
In this session, we talk about how we came up with a new framework for serving front-end content efficiently and effectively. Using a good mix of new technologies like Node, Express and ReactJS, we are creating a way to serve content in a beautiful manner to the user without compromising on developer comfort.
Specifically, amongst other things, we talk about isomorphic javascript, profiling node code and an efficient css delivery mechanism which balances code optimization and delivery optimization.
Outline
I will give an insight into the overall philosophy and the architecture we developed for moving away from a PHP based stack to a Node based stack. We faced a lot of problems like prioritizing maintainability, code readability, testability, availability, extensibility and reusability. Figuring out if a certain change might help out in the future bigtime, or is it just a case of premature optimization? How do we migrate the core stack of a website without any downtime or slowing down the feature launches? Single page apps are the bee’s knees, but what about SEO? These are just some of the questions we faced and tried finding the answers to.
Some things we will definitely touch upon are:
- Code maintainability: a small team of 3-4 people might come up with a new and better way of doing things. But how do you get 100 or 1000 other people to work on it without adding hacks and ‘quick fixes’ every day?
- High availability: For a website like Flipkart.com, 100% uptime is very important and keeping servers up and running in case of high loads, errors or attacks is crucial.
- Rich UI and Performance: Customers expect a fully functional, rich interfaces across all their devices. And any lag or jank is a strict no-no. Building rich UI without compromising on performance is key.
- Testability: Testing is important and helpful. No matter how tedious and boring it might seem, putting some time in it definitely helps in the long run. One key point here being, what should be tested and what is ok to be left to manual testing only.
- Profiling: Finding out what is slowing down the application and why
- Isomorphism: Sharing code between client and servers makes the development much more efficient as you can “code once, run everywhere”
- CSS: “inline css? NEVER!” That might be true in a lot of cases, but we will see how some of the old idealogies no longer apply, and might actually be slowing the internet down.
Requirements
An open mind :)
Speaker bio
I am a UI engineer at Flipkart. I’ve been active in web development and UI for over 4 years. Having solved many interesting problems with my team, involving scale, cross-browser issues and UI performance, my interest in UI just keeps increasing day by day!
On the personal front, I love music, photography, travelling and driving. And its always fun to hack with new libraries and frameworks, trying to see what they can do, and what I can build using them :)
You can find me on:
Twitter: https://twitter.com/_abhinavrastogi
Github: https://github.com/abhinavrastogi
{{ gettext('Login to leave a comment') }}
{{ gettext('Post a comment…') }}{{ errorMsg }}
{{ gettext('No comments posted yet') }}