Skip to content

Instantly share code, notes, and snippets.

@julianburr

julianburr/conferences-eu.md

Last active May 23, 2017 13:09
Show Gist options
  • Save julianburr/c9a60800eb98248dc957eb1bf986bce6 to your computer and use it in GitHub Desktop.
Save julianburr/c9a60800eb98248dc957eb1bf986bce6 to your computer and use it in GitHub Desktop.
Download ZIP
Notes from React Amsterdam, CSSConf EU and JSConf EU 2017
Raw
conferences-eu.md

Conference Summary (Europe)

Some short notes on the topics of the conference talks.

🖋 - I could write a blog post etc. about it if there is any interest
👨‍🏫 - I can even make a small talk if there is even more interest

⚡ - Lightning talks

Content

React Amsterdam - React Native

React Amsterdam - React (from online stream)

  • ...

CSSConf EU

JSConf EU



React Amsterdam - React Native (Stream)

Infinite Red

Some tools for building RN apps

Reactotron

  • allowes overview over actions, sagas, timelines, etc
  • easy way to trigger and snapshot actions (incl. time travel)
  • You can subscribe to actions
  • => all this without the need of remote debugging at all!

Expo

  • apparently lets you sync the app to your phone via QR codes (so great e.g. for test users)

Ignite

  • Boilerplate/Generator for RN apps
  • basically lets you plug n play available plugins such as maps more easily
  • also lets you modify the blueprints from the plugins (e.g. for creating map screens, etc)
  • Some related videos

IMO
Some interesting ideas, but nothing really extraordinary...

Microsoft Mobile Center

This was basically the same talk as in SanFran 😐

The main take aways were:

  • It is really easy to set up => he did it on stage and I also tried it with a private project within minutes...
  • It already gives you a lot of tooling around the app
    • Bugtracking
    • Signing
    • Test user tracking
    • Deploying (CodePush)
    • Tests
    • Analytics
    • ... with more tools such as Notifications etc in plan

IMO
This seems awesome. Not really transparent when it comes to the future pricing plans, but in general this seems very promising.

Offline concepts in React/RN 🖋 👨‍🏫

Was basically describing the concept and ideas behind redux-offline and redux-optimist.

  • UX/UI POV: 3 screen states
    • Optimal state
    • Loading state
    • Error state
  • The aim should be to eliminate the not-optimal states as much as possible!

Thoughts on reading data offline

  • With redux you already have something like a persistent data storage while the user moves through the app
  • One step further is local storage (e.g. redux-persist) that persists the data beyond app restart (redux state get saved a rehydrated)
    • this needs to be compressed and/or filtered at some point when the app and its state grows
    • Also you want to be able to update/migrate the store when the app changes => redux-persist-migrate
  • You want to think about caching

Sidenote: redux-offline already wraps around redux-persist, so if you use that library you don't really need to worry about the points above

Thoughts on writing data offline

  • Optimistic data handling (good, because of better responsiveness of the app, and the requests will be send once the app regains network connection)
  • The three stages of offline data writing
    • Trigger UI changes
    • Commit action if the server responded successful
    • Rollback action if the server responded with an error
  • => for that you can e.g. create a simple queue in the redux store
  • things start getting trickier when it comes to conflicts, that cannot be handled completely in the frontend (some backend conflict logic necessary)

Other things

  • redux-offline is really flexible, makes it quiet easy to create customized boilerplates around it

IMO
I think offline first is a great and more and more crucial way when building mobile apps. And frameworks like react-offline offer great guidelines handling data flows offline.

Also I think this way of programming just enforces a good practise when handling data (optimistic approaches etc.), meaning even without offline functionalities planned, building around this doesn't really hurt.

⚡ Performance optimization in React/RN

  • code splitting (!), e.g. route based or intend based chunks - 19,200ms => 4,500ms
  • ssr (not exclusive, but where it makes sense! E.g. with express) - 4,500ms => 920ms
  • compressing static assets - 920ms => 550ms
  • caching (incl. service workers) - 550ms => ~300ms (on second visit obv)
  • preloading (urls, assets, etc) -

The times next to the steps shows the saved time (measured by the time till first meaningful paint) in the speakers example application.

IMO
I basically just added this lightning talk to underline how important code splitting is in my opinion for web apps, even more when you think about how easy it is by now with webpack ... its all already there, you just need to use it.

Universal React (callstack.io CTO)

Talk about re-using JS between React, RN, ... apps. One of the main messages is that JS is the answer to shared code bases, and that programmers need to be aware that JS, as it runs on almost all devices and platforms, is the connection needed for that.

Another message is that programmers should be aware that it is impossible/not worth it building univeral code (a 100% shared code base), instead you should start thinking about which parts (logically and visual) can and should be shared between plattforms and code basis.

Solution: think rather in universal components and libraries rather than universal apps. E.g. if you have a utils folder, this should only contain code that could be pusblished on github, it should be independent.

Also he recommends setting projects up as monorepos, split by platform and containing a folder for all the universal code on the top level, to make the processes easier.

IMO
Nothing mind blowing, all pretty basic knowlegde in my understanding... the recommendation of building projects as monorepos is nice tho

Performance (and Animations) in RN 🖋 👨‍🏫

Talk by WIX, dealing with the general functionality of JS applications and where performance bottlenecks come from.

Crossplattform

  • JS holy grail to cross plattform, but that's not a new concept
  • But the concept hasn't caught on, reason: performance => hybrid apps have been way less performant than native apps

Game changer React/RN

  • RN doesn't build on webviews, it uses native components in the core
  • You have two realms: a JS realm and a native realm, that run next to each other
    • JS is the same as e.g. in the browser, runs single threaded
    • Native realm is the same as in native apps, where you have the main UI Thread and as many background threads as you want
  • The important part of this concept is the bridge between these two realms, cause this is the performance bottlenecks come up
    • data has to be serialized and sent from one realm to the other

Problem of synchronous updates

  • when updating the UI it has to be synchronous, since the single JS thread has to wait for the update to happen before continuing
    • same problem that ReactJS (and others) already solved for the web, using shadow DOM

Conclusion

  • to optimize performance in React and RN, you have to reduce the traffic over the bridge as much as possible
  • Two possible ways to do that:
    1. Write logic in native code
    2. Declare logic in JS and run it on native driver (=> this is what Animated.* lets you do 😊)

Example (RN)

  • You have a ScrollView and want to do something on scroll
  • You need to listen to the onScroll event on the native side, since you are dealing with a native View in the core
  • Sending the event over the bridge on each event leads to a lot of traffic, meaning once your JS thread does not run on 60fps anymore, your app becomes janky
  • So now you can either...
    1. write the logic directly on the native
    2. declare the logic in JS but handle it on the native side
  • RN Animated.* lets you declare the logic you want to happen on a given event, and allows you to run in on the native side without the need of using the bridge anymore!

Problem

  • unfortunately this is not possible for RN pan handlers, as they are completely handled by JS

Solution (or why WIX's react-native-interactable is so awesome 😉)

  • you would need to write the native code to handle these pan events for all plattforms, which wix did
  • that way, it doesn't matter how busy your JS thread is, your animations always run on 60fps

IMO
React Native Interactable is obv great and the right direction. I also liked the talk because he illustrated really good how React, React Native (and even JS in the core) work and where the performance bottlenecks usually come from.

RN Touch & Gestures (Krzysztof Magiera)

Basically the same core message as above, with an alternative (experimental) library for native animations (Android only 😧).

MLS: RN Navigation 🖋 👨‍🏫

TL;DW: there is no one solution for everyone, you have to check for your specific use case

  • compared several navigation solutions considering the following features/benchmarks
    • cross plattform
    • flexibility
    • great developer experience & high velocity
    • strong community
    • stable
    • supports deep linking
  • tested against the following libraries
  • repo with demos

PROS

  • native navigation
    • feels very native, cause it is (smooth animations, etc.)
    • in-code easy to set up
    • view and tab navigation build-in
    • shared element transitions 😍
    • custom navigation implementations (they expose a native interface for custom navigation solutions)
  • react navigation
    • very easy to set up (JS implementation)
    • cross plattform
    • view, tab and drawer navigation build-in
    • HON (Higher Order Navigation) => you can use react navigation and it's API while using another solution like native navigation in the core
  • react router
    • also very easy to setup
    • also cross plattform (e.g. with in-memory routing you can basically route anything...)
    • redirects out of the box

CONS

  • native navigation
    • installation (you have to use cocoapods)
    • it's beta!
    • not very flexible when it comes to visual config options
  • react navigation
    • screen transitions can lag (it's a JS solution after all)
    • also not very nice when it comes to navigation options
  • react router
    • you have to roll your own transitions, they don't come for free (which means you have the flexibility to have your own custom transitions)
    • no out-of-the-box Android back button support (but fairly simple to add manually)

Conclusion
They are all good, and there are even more good solutions (e.g. react native navigation), so do invest the time and compare them for your needs.

Some good reads

IMO
Some very interesting points, still with the same message as everyone: you have to find the solution for your specific use case yourself. But he pointed out some good points and explained their decision process, which was interesting.

React Amsterdam - React (Stream)

TBD

CSSConf EU

Time to First Meaniningful Paint - Performance Optimization

Tools

  • Lighthouse to measure ttfmp
  • Webpagetest for performance testing with real devices and network conditions

Main solutions to optimize performance from CSS perspective:

  • separate critical css
  • prioritize with preload and http2 server push
    • modify server push behaviour, to push within first idle connection time

IMO
Nothing mind blowing, but still good practice to keep in mind when optimizing app performance.

Scaleable CSS (BBC News)

  • Target: all news sites using the same codebase
  • Grandstand as CSS framework
  • Define styles according to patterns not necessarily to components
  • For each of these patterns define a namespaced class and apply these classes in combination to your components 🤔
  • ... a bit more like that ...

IMO
Interesting in 2011, by now imo a collection of bad practices 😐
A little bit more interesting part on localization (using SASS variables, mixins, etc, to ensure correct stylings for all typographies and text directions) ... but again, using patterns that were popular when bootstrap first came out.

Getting Reactive in CSS 🖋 👨‍🏫

  • how to combine CSS variables and reactive JS, and what are the benefits compared to pure JS, SASS, LESS, etc.
    • performance (native browser feature)
    • CSS variables can be directly manipulated via JS during runtime
    • CSS variables can be defined for any class scope if needed
    • allows using Dev Tools for debugging, playing with variable values, etc
  • Further performance optimization via RxJS and observables

IMO
Again not really new, but still interesting. CSS variables are awesome, and browser support actually seems better than I thought it was ... IE and Edge are still completely out tho 😐

CSS in JS (or "please don't throw tomatoes at me before I finished my talk")

What benefits does CSS in JS have

  • Relating styles on component level (which goes along nicely with the current workflows with component driven development)
  • Critical css easily defined/build in
  • A lot of tools that help optimizing
  • Access to npm makes use of packages instead of huge libraries possible (!)
  • Best practice is build-in, not opt-in

IMO
Good talk on the benefits. Did put emphazis on the oportunity for CSS to benefit from the huge JS ecosystem instead of trying building their own.

Styled Components

Why you are going to love styled components as CSS developer

  • to enforce thinking in components
  • we should separate by components not by tech, because it's more use(r) and reality related
    • No user will understand when you present parts of your website by which tech you used ... its much more understandable to divide by components ... the same goes for the development process
  • Styled components let you write css (as string, so 1 to 1 css experience) and define themes
  • Styled components can access props in the styles
  • Usable also in react native/cross-platform

IMO
Really interesting to see styled components pitched from a CSS point of view from Glen Maddern instead of hearing the same old stories from Max Stoiber 😊

The Future of CSS

  • CSS variables
  • Blending and filtering functions
  • Shapes (e.g. for text flows)
  • Colors (util functions)
  • New selectors
  • Feature check with @supports (lets you e.g. overwrite styles if a specific feature is supported by the current browser)

IMO
Some really good features I haven't seen yet as well ... but as usual, the browser support of those is pretty awful

JSConf EU

Performance optimization (Google)

  • Code splitting
  • New coverage tool in dev tools to check unused code
  • Use preload tags for critical resources
  • Use PRPL patterns
  • H/2 push
    • Problem: not very cache aware
    • Solution: service workers as middleware
  • Use bundle analyser and similar tools to identify possible bottlenecks

IMO
The coverage function in the dev tools looks great! Makes it much easier to identify when code splitting would be useful. Also the solution for the HTTP/2 push problem (APP <=> ServiceWorker <=> HTTP Request) seems very elegant.

Immutable data structures

  • Everything rocks

Why we should use them

  • pure functions
  • avoid bugs and uncertainty during development process

How does it work

  • Transforming data to trees / tries (from retrieve)
  • Data can not be changed, for every change we need to copy the original data
    • Problem: very slow and memory inefficient
    • Solution: data sharing (only copy changed parts and reference unchanged parts)
  • Binary leaves vs 32 leaf structures => balance between memory and speed efficiency

IMO
Interesting talk, but basically not much more insight then we got through Pete's talk on immutableJS

Accessability (FT.com)

  • pretty general talk why accessability is so important
  • "for sure you think its not that important for you, you're not in a buisness where it's needed, and we thought the same, but let me tell you something: you are wrong" .... they are a news plattform, for gods sake, I can't really think of any business where it's more important to be accessable 😐😐

Tools

IMO
Pretty basic, there are some node and ci integrations of pa11y I didn't know of and that look pretty neat. Lets you easily integrate it into pre-commit hooks or build scripts.

Jest (Facebook)

  • standard "we made testing great again" talk
  • New feature: multi project runner
  • Side note: Yarn gets a new command "create" to set up projects from boilerplate plugins

IMO
The multi project runner and some other neat features in the new Jest version. Otherwise quiet disappointing talk.

The Future of Modularization (npm)

Why should we modularize code

  • No clear answer in the community => we know its good, but we don't really know why
  • Yes, to make development easier
  • But maybe more importantly to isolate the hard stuff
  • Don't make code easily extendable, make it easily exportable

IMO
Interesting talk about some wide spread misconceptions about modularization with the key message that there is not one true answer/solution to the dilemma

Mobile optimization (LinkedIn)

  • Prepack
    • combining the best of static and dynamic code analysis
  • Glimmer
  • Making initial and re-renders even faster by considering static and dynamic content

IMO
Nothing really interesting/new, except for the prepack part (since fb refused to talk about it 😅). Interesting to hear where the performance benefirts from prepack come from...

NASA

  • NASA recommends using as many eslint plugins as possible to standardize your code 😅

Parallel programming

  • SharedArrayBuffer (es8) to share memory between service workers
  • Leads to conflicting memory access and changes, so we need to do atomic access, which blocks the memory, which hits performance again if used wrong
    • Solution: don't access memory for every iteration, do it in batches
  • TurboScript - also using WebAssamly for better performance

IMO
Interesting approach, but benefits are too small as of now due to the memory access issues.

JSSS

  • JS Style Sheets as alternative standard to CSS in 1995
  • Standard got droped in Netscape 6, however the ideas caught on
  • CSS is not dead, maybe we should shift our thinking and try to find out what we want
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment