CSE 134B: Client-Side Web Languages

Winter 2017 | University of California, San Diego CSE Department

Homework #5 - Final Execution and Optimizations

The final step of our homework project is to bring our TopicDex to life in a final form that we hope that the users might be happy with. We split the assignment into two parts -- a required MVP form that works with the Internet is fast and available and a second optional part using “PWA” ideas that even more performance oriented. You are only required to do the first part, but you may do the second part to make up points or add to your point totals

Part 1 - Required : Polished CRUD

The required form of our app is fully working and styled application that allows a user to login and maintain their “Dex” of information using the CRUD actions you experimented with in HW4. The app presentation should present a final style execution with images and employs Bootstrap or Vanilla CSS (not both - pick one). That is fully executed with polish at or beyond what you defined in Homework 1-3. Note: You are not required to stick to these screens if you have figured out how to do things better. That is your base requirement the TAs will look at. They may reward more points if you have exceeded your prototype.

Code execution wise you may use a SPA pattern (single page application) or not. Also you may use VueJS or VanillaJS/jQuery if you find it appropriate. Regardless of your approach you should have all your code bundled in a .min.js form for users and performance testing and have an unminified version in your repo for inspection. Make sure you performance test your application and record some baseline numbers for the required step using a real device at a 3G throttle and/or using WebPageTest.org.

Part 2 - Optional : PWA Like Optimization

If you made a lot of progress on HW4 or are more interested in trying emerging technologies you can attempt to add PWAesque ideas to your application. This may be difficult and should be approached progressively starting first with simple ideas like adding a Web app manifest, offline page, offline caching and maybe finally some offline functions. Firebase can make some of this easy or not, but it will depend quite a bit on decisions made previously.

The point of Part 2 is to take the speed measurement from your first version and see how far you can go performance wise to improve the first meaningful paint and final load time (for both first and repeat visit) using PWA and related ideas. To speed up your site there are many tactics, you may employ an app shell architecture (SPA style), you might use service workers, you might do preloading techniques, employ the PRPL pattern or many other related technologies and patterns. We won’t restrict your interest.

Students are warned not to attempt the optional part until you have finished part 1 and taken measurements. Furthermore, appropriate time and patience should be reserved for the second part as there are many sharp edges with these emerging technologies. You will certainly find that the easy to follow tutorials you may find online won’t use your particular technology, pattern, or simply be out of date. To assist in part 2, the professor will provide a short post of links that may have faster paths to better data, but understand there will be no quick or guaranteed answers even with such hints.

Part 3 - Required : Handoff Preparation and Analysis

We won’t be working on this code in this class much longer, so we need to prepare now for a final handoff. Also consider that many students may want to have a Github repo to show what they accomplished so this part aims to format and prep your code and project for others to look at.

To accomplish this step well you most importantly should format and clean your unminified code in the repo for easy readability as well as providing a live link to the working app online. Consider the grader for points (and an interviewer for jobs) will look at the site and demo and judge you maybe harshly! Beyond your source code and directory organization, provide appropriate documentation in your repo both to the app and the code. Make sure this effort is not limited to just README files but is built-out with screen captures, the demo link and any other things you think would make it easier for others to understand your app and potentially use your code. Make sure to document the architecture of the code, the organization of files and most importantly any concerns, limitations, caveats or TODOs that may still be in place upon turn-in. Even if you are not successful in finishing your code you can recover many points doing a good job here.

Back to CSE134B


  • 5pts for authentication (2.5pts for email, 2.5pts for Google)
  • 10pts for CRUD (2.5 points for each function).
  • 5pts for asset management (2.5 points for each CRUD function against image or other assets used)
  • 30pts for relative full UX/visual/flow execution to your peers stack ranked by the TAs (Top Third - 30, Mid-Third 20, Bottom Third 10pts)
  • 15pts for Code Quality
  • 15pts for Documentation
Optional Part
  • Up to 50pts or PWA features. Use Lighthouse for verification. We will take your Lighthouse score and divide by two
  • 15pts Fastest three apps in class (3G, Android tested) get an extra 15pts. Only part 2 projects can qualify for the speed test points. We reserve the right to disqualify any submission that uses an inappropriate content free or non-user focused design solely to win the speed test.

Total: 80pts plus up to 50pts extra

Due Date: 9PM Thursday March 16th