JSFoo 2017

JSFoo is a conference about JavaScript and everything related.

About the conference: JSFoo is a JavaScript conference hosted by HasGeek.

Theme this year: The broad theme this year is going to be Building Reliable Web Apps. Please refer to the Topics section below for the subject of talks and workshops we are looking for.

##Format
We are inviting proposals for:
Full-length 40 minute talks.
Crisp 15 minute talks.
Sponsored sessions, of 15 minutes and 40 minutes duration (limited slots available; subject to editorial scrutiny and approval).
Hands-on Workshop sessions, 3 and 6 hour duration.

##Selection process
Proposals will be filtered and shortlisted by an Editorial Panel. Please make sure to add links to videos / slide decks when submitting proposals. This will help us understand your speaking experience and delivery style. Blurbs or blog posts covering the relevance of a particular problem statement and how it is tackled will help the Editorial Panel better judge your proposals. We might contact you to ask if you’d like to repost your content on the official conference blog.

We expect you to submit an outline of your proposed talk – either in the form of a mind map or a text document or draft slides within two weeks of submitting your proposal.

Selection Process Flowchart

You can check back on this page for the status of your proposal. We will notify you if we either move your proposal to the next round or if we reject it. Selected speakers must participate in one or two rounds of rehearsals before the conference. This is mandatory and helps you to prepare well for the conference.

A speaker is NOT confirmed a slot unless we explicitly mention so in an email or over any other medium of communication.

There is only one speaker per session. Entry is free for selected speakers. As our budget is limited, we prefer speakers from locations closer home, but will do our best to cover for anyone exceptional. HasGeek provides these limited grants where applicable: two international travel and accommodation grants, three domestic travel and accommodation grants. Grants are limited and made available to speakers delivering full sessions (40 minutes or longer). Speaker travel grants will be given in order of preference to students, women, persons of non-binary genders, and individuals for Asia and Africa first.

##Topics
Updated (19 April 2017): We are currently looking for talks in the following topics:

Testing: Testing tools and strategies; test driven development and testing culture; continuous integration and testing workflows; and case studies around testing your application.

Performance optimization: Performance analysis tools and techniques; best practices for building performant applications; browser, NodeJS, and framework internals; network protocols; and performance case studies.

Debugging: Tools for locating and fixing bugs in JavaScript applications; real world post-mortems of bugs that affected your organization; and using telemetry for debugging.

Immutability, type checking, and alternative programming languages: Alternatives to vanilla JavaScript; functional programming and immutability; types and type systems; and real-world case studies of introducing alternative programming languages and tools in your organization.

Build tooling: Build tools and automation, including task runners, linters, JavaScript bundlers, CSS pre- and post-processors, continuous integration tools, static analysis tools, and optimization tools.

Crash and performance monitoring: Monitoring applications for crashes and performance issues while in production.

##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 for it to be available under a permissive open source licence. If your software is commercially licensed or available under a combination of commercial and restrictive open source licences (such as the various forms of the GPL), please consider picking up a sponsorship. We recognise 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”.

##Important dates
Deadline for submitting proposals: 15 June 2017

**Conference dates: ** 15–16 September 2017

##Contact
For more information about speaking proposals, tickets and sponsorships, contact info@hasgeek.com or call +91 76763 32020.

Note: We aren’t accepting any new talks.

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

Nikhil John

@nikjohn

Developing Websites for Low Bandwidth Markets

Submitted Jun 2, 2017

Does your website work everywhere in the world? How about developing countries? Bangladesh, India, Sri Lanka, Pakistan?

Internet is slow and expensive in the developing world, and devices not as powerful. Consequently a lot of modern web applications simply fail in these markets, which means they miss out on almost a Billion potential users.

This session will deal with how to:

  1. Develop for slow network connections
  2. Deal with proxy browsers (Opera Mini, UCBrowser etc.)
  3. Factor for legacy and low performance devices (Feature phones, older smartphones etc.)

during Archtecture, Development and Testing. Topics covered will include

  • Progressive Enhancement
  • Adaptive Web Development
  • Performance Monitoring

Outline

The Issue with Low Bandwidth Markets (LBMs)

Low Bandwidth Markets are areas where network speeds are slow, latency is high, and are often developing nations in the Indian Subcontinent, South East Asia, South America and Africa

  • Most websites are built and tested on high speed internet. Chances are that these applications would fare poorly or fail completely in Low Bandwith Markets.
  • LBMs have over 1 billion users, 40% of all internet users. But these markets have an average speed of less than ~4 Mbps.
  • Mobile web is even slower, adding to the problem. Mobile devices are also often older and less performant owing to low purchasing power, and legacy technology.
  • Data is also often expensive, pushing the use of proxy browsers (Opera Mini and UCBrowser) that strip CSS and Javascript before serving pages, making them unpredictable.
  • These factors cumulatively make the web User Experience notoriously horrible in these markets, keeping the web away from millions of people.
  • Bad UX means higher bounce rates. Ergo, a number of popular websites are missing out on massive revenue due to this often unaddressed problem.

Is it for everyone?

  • Not every website needs to cater to LBMs, but page load performance is should always be top priority.
  • Solid performance drives User Retention. So even if LBMs aren’t your primary concern, good performance ought to be.

Assessing the state of your Website

  • Run Analytics: Which countries do your users come from? What devices do they use? What browsers do they use?
  • Monitor Performance: Get an idea of how fast your website loads, through tools like NewRelic or DynaTrace.

Issue #1: Giant Web Applications, commonly > 5MB don’t load

Issue #2: Single Page Applications do everything client side

Issue #3: Proxy Browsers trim Javascript, CSS and large network requests

Issue #4: Javascript is often disabled

So what’s the solution?

There is no one all encompassing solution

  • The aim of the Web Architect should be to attain the delicate between Feature richness, Performance and Time to Market
  • Performance should be constantly monitored, and performance bugs should be seen as at par with others.
  • Have performance sprints

Architecture

  1. Progressive Enhancement and PWAs (Progressive Web Applications)
  • These are Connectivity independent, safe and installable applications
  • Universal Javascript is the future
  1. Adaptive Web Development
  • This uses static layouts based on breakpoints which don’t respond once they’re initially loaded.
  • Not ideal, but if push comes to shove and you need your app to work on a feature phone, you might need to serve out a different page altogether
  1. Server Side Rendering when possible
  • Sometimes, you don’t need Single Page Applications. A simple server redered static website would do.
  • Static sites work across browsers, network conditions, geographies and require little to no Javascript. If you can make do with one, then your work is cut out for you.

Development

  1. Develop mobile first - it always helps with perf
  2. Best Practices - Trim, Bundle, GZIP and Tree Shake your code to make it lean.

Testing

Testing should be done on

  1. Real devices
  2. Real networks

Monitoring

  1. Performance should be constantly monitored, and performance bugs should be seen as at par with others.
  2. Performance Sprints between regular development cycles

Requirements

This talk does not have any prerequisites. Some background in Javascript will be useful, but even non-technical folks will find this.

Speaker bio

Nikhil is a freelance Web Engineer with Six years of experience developing Responsive and Adaptive Web Applications, with frameworks such as ReactJS, AngularJS, EmberJS, BackboneJS, ExpressJS for Deloitte Digital, Saltside.se, Creatubbles.com and Mobi Corp.

Slides

http://slides.com/nikjohn/deck-3/fullscreen#/

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