Podcasts about indexeddb

Ben Holmes, product engineer at Warp, joins PodRocket to talk about local-first web apps and what it takes to run a database directly in the browser. He breaks down how moving data closer to the user can reduce latency, improve performance, and simplify frontend development. Learn about SQLite in the browser, syncing challenges, handling conflicts, and tools like WebAssembly, IndexedDB, and CRDTs. Plus, Ben shares insights from building his own SimpleSyncEngine and where local-first development is headed! Links https://bholmes.dev https://www.linkedin.com/in/bholmesdev https://www.youtube.com/@bholmesdev https://x.com/bholmesdev https://bsky.app/profile/bholmes.dev https://github.com/bholmesdev We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Ben Holmes.

Scott and Wes dive into the world of local data storage, breaking down the pros and cons of Sqlite, LocalStorage, SessionStorage, Cookies, and IndexedDB. They cover real-world use cases like user settings, offline data, and auth tokens, while sharing their favorite tools and strategies for keeping your data fast and secure. Show Notes 00:00 Welcome to Syntax! 00:30 Brought to you by Sentry.io. 01:43 Why store data locally. 01:55 User preferences and settings. 02:50 Not logged in state (shopping carts, etc). 03:30 Data for faster loading. 03:51 Privacy concerns. 04:25 Large files or drafts. 05:50 Auth tokens. 07:08 Where to store data. 07:11 Cookies. 07:48 Local storage. 09:15 Session storage. 10:35 IndexedDB. 12:15 BYOJS Storage. 13:41 SQlite via WASM. 14:12 Penalties of SQLite in browser via WASM. 15:29 PGLite. 16:23 Dealing with migrations. 16:55 The advantages of the approach. 18:42 Dexie. 19:59 Patch messages. 21:25 A few options. TinyBase Docs. Local First Web. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Scott and Wes serve up state management in JavaScript, breaking down key concepts like reactive state, state updaters, and global vs local state. They also explore various approaches and libraries, mutation-based state, and tools like Zustand and xState, to help you manage state like a pro. Show Notes 00:00 Welcome to Syntax! 01:22 Brought to you by Sentry.io. 03:10 What is state? 03:29 Common state jargon. 03:48 Reactive State. 04:14 Store. 04:46 Immutable vs Mutable State. 05:53 State updaters. 06:15 Signals. Solid.js Signal Docs. 06:49 Observables. 07:07 UI is a function of state. 08:39 State Machine. 10:58 Binding state. 11:36 Global vs local. 11:49 Computed State, derived state, selector state. 12:41 Approaches to state management. 12:52 Reducer based. 16:39 Mutation based state. 21:17 Adam based state. 25:15 Ways to hold state. 25:17 Holding state in an object. 27:38 Holding state in the URL. Syntax Shows. 29:34 Holding state in IndexedDB, local storage, and cookies. 32:16 Holding state with FormData. 33:56 Holding state with Signals. Signals Proposal. 37:27 Holding state with the server database. 38:55 Global State vs Component State. Habit Path. 40:39 Sharing state. 42:58 State libraries. 45:26 Zustand. 50:24 Jotai. 51:50 xState. 54:56 Easy Peasy. 55:24 Pinia. 56:01 TanStack Query. 57:02 Sick Picks + Shameless Plugs. Sick Picks Scott: Cremo Mens Body Wash, Bentgo Adult. Wes: Adult Bento Box. Shameless Plugs Wes: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Scott and Wes dive into the world of browser caching for audio files, exploring the File System API and the Cache API. They discuss size restrictions across different browsers, how tools like Riverside.fm leverage IndexedDB, and walk through code examples for creating, retrieving, and managing cached audio data. Show Notes 00:00 Welcome to Syntax! 02:07 Brought to you by Sentry.io. 02:33 The file system API. 03:08 The Cache API. Mozilla Developer Cache API. Airhorner, a good example. 04:24 Size restrictions per browser. 07:04 How tools like Riverside.fm use IndexedDB. 08:47 Data eviction (too much data). 10:16 What we're using it for and how. 12:17 How do we do this in code? 14:37 Creating the cache. 16:18 Retrieving from cache manually. 19:00 Adding metadata. 19:37 A live debugging. 22:39 Persistent storage. web.dev Persistent Storage. Hackernoon Persistent Storage. 26:10 Media score. Chrome Autoplay Policy. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott:X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Join Wes and Scott as they explore LoFi (local first) web development, delving into CRDT, Websockets, IndexedDB, SQLite, and more. Discover when Local-First shines and when it's better to steer clear in this episode packed with practical insights. Show Notes 00:00 Welcome to Syntax! 03:18 Brought to you by Sentry.io. 04:08 What is LoFi? localfirst.dev 05:02 The Seven Ideals for Local-first. 05:29 1: No Spinners. 06:48 2: Your work is not trapped on one device. 07:56 3: The network is optional. 08:50 4: Seamless collaboration with your colleagues. 09:35 Oops, we for got to read 5: The Long Now. 09:37 6: Security and privacy by default. 09:45 7: You retain ultimate ownership and control. Actual Budget Finance App Ink & Switch 13:01 Sounds great, let's go! Not so fast, this stuff is hard. 14:07 The technology involved. 14:30 CRDT (Conflict-free Replicated Data Types). Wikipedia Definition James Long dotJS 2019 dotconfrences 17:48 How does it prioritize conflict resolutions? 19:36 Websockets. 20:17 IndexedDB + SQLite. 21:23 Service Workers. 22:16 The software involved. 22:24 Replicache. 24:48 YJS. 25:06 Electric SQL. 25:51 The most basic LoFi application. 31:26 Some bigger concepts. 32:34 Answering some common questions. 35:19 Some real-world examples of LoFi. Habit Path by Scott Tolinski 37:18 What about Apple PWA nonsense? 38:20 This seems similar to real-time software and multiplayer. 38:47 Sounds like too much work. Triplit Fullstack Database Electric SQL Evolu 40:46 Some useful links. Local-First Web Development Local-First Lo.fi YouTube Local-First Ink & Switch Local-First Reddit Syntax GitHub Local-First 43:30 Sick Picks + Shameless Plugs. Sick Picks Wes: Dresscode.dev Scott: Monarch Money Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott:X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

In this episode I'm joined by GUN founder Mark Nadal to discuss GUN. GUN, also known as GUNDB, is a real-time, decentralized, offline-first, graph database. In practice, GUN provides a Javascript API that allows webapps to sync data between peers with no centralized server dependency. GUN peers use WebRTC and similar transport protocols to sync data to localStorage and IndexedDB in the client. GUN also provides access controls, which allow developers to store encrypted data on the network. The API can be used in browser tabs, on mobile apps, or run as a relay peer in a NodeJS process on a cloud instance. In this conversation, GUN's founding engineer Mark Nadal and I dive into the technical details to explain what makes GUN different from IPFS, WebRTC, and blockchains, and why so many devs are excited about GUN. I hope you enjoy the show. Topics Discussed · GUN in 100 seconds Youtube Video · Learn Cryptography in seven 1-minute videos · NERFs for photogrammetry · GUN for Metaverses · Comparison to IPFS · WebRTC, Gun Relays · Every Gun peer runs a WebRTC signalling peer · A GUN Instagram competitor by an early Bitcoin dev iris.to · Project built with GUN

Head over to devNursery.com and Datanation.click

In the AppSec News, Safari fixes a privacy leak in IndexedDB, integer arithmetic flaw leads to Linux kernel bug, a look back on Zoom security, SSRF from an URL allow list bypass, a security engineering course and lectures, 25 years of HTTP/1.1   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw181

It is hard, if not impossible, to secure something you don't know exists. While security professionals spend countless hours on complex yet interesting issues that *may* be exploitable in the future, basic attacks are occurring every day against flaws in code that receives little review. For example, a “dated trend” by effective yet lazy hackers is to search for APIs unknown by security teams, coined “Shadow APIs”, then connect to these APIs and extract data. SQL Injection used to be the hack of choice, as a few simple SQL commands would either mean pay dirt or “move on to the next target”. Now the same can be said for Shadow API: Find, Connect, Extract. Himanshu will discuss one of many methods that are used in the wild to target Shadow APIs and export large volumes of data with a few clicks of a button or a few lines of code in Python. In the AppSec News, Safari fixes a privacy leak in IndexedDB, integer arithmetic flaw leads to Linux kernel bug, a look back on Zoom security, SSRF from an URL allow list bypass, a security engineering course and lectures, 25 years of HTTP/1.1   Show Notes: https://securityweekly.com/asw181 Visit https://www.securityweekly.com/asw for all the latest episodes!   Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly

It is hard, if not impossible, to secure something you don't know exists. While security professionals spend countless hours on complex yet interesting issues that *may* be exploitable in the future, basic attacks are occurring every day against flaws in code that receives little review. For example, a “dated trend” by effective yet lazy hackers is to search for APIs unknown by security teams, coined “Shadow APIs”, then connect to these APIs and extract data. SQL Injection used to be the hack of choice, as a few simple SQL commands would either mean pay dirt or “move on to the next target”. Now the same can be said for Shadow API: Find, Connect, Extract. Himanshu will discuss one of many methods that are used in the wild to target Shadow APIs and export large volumes of data with a few clicks of a button or a few lines of code in Python. In the AppSec News, Safari fixes a privacy leak in IndexedDB, integer arithmetic flaw leads to Linux kernel bug, a look back on Zoom security, SSRF from an URL allow list bypass, a security engineering course and lectures, 25 years of HTTP/1.1   Show Notes: https://securityweekly.com/asw181 Visit https://www.securityweekly.com/asw for all the latest episodes!   Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly

In the AppSec News, Safari fixes a privacy leak in IndexedDB, integer arithmetic flaw leads to Linux kernel bug, a look back on Zoom security, SSRF from an URL allow list bypass, a security engineering course and lectures, 25 years of HTTP/1.1   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw181

In this episode, we talk about Walmart's plans to get into NFTs and cryptocurrency, telecom operators starting to block Apple's iCloud Private Relay, and an attack of the Wordle clones. Then we speak with Valentin Vasilyev, co-Founder and CTO at FingerprintJS, whose team spotted a vulnerability in Safari 15's IndexedDB API. Show Notes Scout APM (DevNews) (sponsor) Walmart is quietly preparing to enter the metaverse Apple under fire over iPhone encryption tech The App Store clones are here to profit off Wordle's success Exploiting IndexedDB API information leaks in Safari 15

Voltamos! 🎉Chegou a edição 411 da BrazilJS Weekly, em podcast!Depois de merecidos dias de férias, estamos de volta com a BrazilJS Weekly.Enquanto organizamos as coisas por aqui, a Weekly ficará disponível apenas no formato newsletter e post no site.Nessa semana iniciamos com mais um bug crítico no Safari. O bug em questão é no IndexedDB do Safari 15 e permite que qualquer site possa saber a atividade de navegação recente e atual de um visitante 😳Ryan Florence, criador do framework Remix, fez uma análise comparativa muito legal entre Next.js e Remix. Vale a pena conferir para aprender sobre as duas tecnologias.A Microsoft está adquirindo a Activision Blizzard (Call of Duty, World of Warcraft, Diablo) em um acordo que deve avaliar a Activision em US$ 68,7 bilhões. Get full access to BrazilJS at www.braziljs.org/subscribe

Safari bug, Netherlands App Store ruling, Apple Watch ads Microsoft will buy Activision Blizzard, a bet on games being central to the internet's future. Safari bug can leak some of your Google account info and recent browsing history Netherlands App Store ruling: Apple will allow alternative payment methods, but developers must maintain a separate app binary Possibility of huge changes to App Store as US antitrust bill proceeds to committee Senate Judiciary Committee will consider The American Innovation and Choice Online Act this week; Tim Cook personally lobbying Senate Judiciary Committee against it Apple Watch Series 7 | 911 | Apple Apple Watch "911: Bob" Detectives | Cinematic mode | iPhone 13 Pro | Apple iPhone 14 Pro now rumored to feature 'hole + pill design' instead of notch Likely new iPhone SE and iPad Air models appear in Eurasian database Report: iPad Air 5 with 5G, Center Stage camera, and more coming this spring Report: 'iPhone SE+ 5G' coming this year followed by the larger model in 2023 Locket, an app for sharing photos to friends' home screens, hits the top of the App Store Microsoft Releases Office for Mac Update With Full Apple Silicon Support in Excel Tesla refuses to adopt CarPlay, but this developer has a workaround Aerial app for Mac updated with tvOS 15 screensavers and new features Picks of the Week Rene's Pick: Above Avalon Andy's Pick: Multiselect for YouTube, U.S. free COVID tests Alex's Pick: Live Video in Keynote Hosts: Leo Laporte, Alex Lindsay, Rene Ritchie, and Andy Ihnatko Download or subscribe to this show at https://twit.tv/shows/macbreak-weekly. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: expressvpn.com/macbreak zocdoc.com/macbreak hover.com/twit

Safari bug, Netherlands App Store ruling, Apple Watch ads Microsoft will buy Activision Blizzard, a bet on games being central to the internet's future. Safari bug can leak some of your Google account info and recent browsing history Netherlands App Store ruling: Apple will allow alternative payment methods, but developers must maintain a separate app binary Possibility of huge changes to App Store as US antitrust bill proceeds to committee Senate Judiciary Committee will consider The American Innovation and Choice Online Act this week; Tim Cook personally lobbying Senate Judiciary Committee against it Apple Watch Series 7 | 911 | Apple Apple Watch "911: Bob" Detectives | Cinematic mode | iPhone 13 Pro | Apple iPhone 14 Pro now rumored to feature 'hole + pill design' instead of notch Likely new iPhone SE and iPad Air models appear in Eurasian database Report: iPad Air 5 with 5G, Center Stage camera, and more coming this spring Report: 'iPhone SE+ 5G' coming this year followed by the larger model in 2023 Locket, an app for sharing photos to friends' home screens, hits the top of the App Store Microsoft Releases Office for Mac Update With Full Apple Silicon Support in Excel Tesla refuses to adopt CarPlay, but this developer has a workaround Aerial app for Mac updated with tvOS 15 screensavers and new features Picks of the Week Rene's Pick: Above Avalon Andy's Pick: Multiselect for YouTube, U.S. free COVID tests Alex's Pick: Live Video in Keynote Hosts: Leo Laporte, Alex Lindsay, Rene Ritchie, and Andy Ihnatko Download or subscribe to this show at https://twit.tv/shows/macbreak-weekly. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: expressvpn.com/macbreak zocdoc.com/macbreak hover.com/twit

Safari bug, Netherlands App Store ruling, Apple Watch ads Microsoft will buy Activision Blizzard, a bet on games being central to the internet's future. Safari bug can leak some of your Google account info and recent browsing history Netherlands App Store ruling: Apple will allow alternative payment methods, but developers must maintain a separate app binary Possibility of huge changes to App Store as US antitrust bill proceeds to committee Senate Judiciary Committee will consider The American Innovation and Choice Online Act this week; Tim Cook personally lobbying Senate Judiciary Committee against it Apple Watch Series 7 | 911 | Apple Apple Watch "911: Bob" Detectives | Cinematic mode | iPhone 13 Pro | Apple iPhone 14 Pro now rumored to feature 'hole + pill design' instead of notch Likely new iPhone SE and iPad Air models appear in Eurasian database Report: iPad Air 5 with 5G, Center Stage camera, and more coming this spring Report: 'iPhone SE+ 5G' coming this year followed by the larger model in 2023 Locket, an app for sharing photos to friends' home screens, hits the top of the App Store Microsoft Releases Office for Mac Update With Full Apple Silicon Support in Excel Tesla refuses to adopt CarPlay, but this developer has a workaround Aerial app for Mac updated with tvOS 15 screensavers and new features Picks of the Week Rene's Pick: Above Avalon Andy's Pick: Multiselect for YouTube, U.S. free COVID tests Alex's Pick: Live Video in Keynote Hosts: Leo Laporte, Alex Lindsay, Rene Ritchie, and Andy Ihnatko Download or subscribe to this show at https://twit.tv/shows/macbreak-weekly. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: expressvpn.com/macbreak zocdoc.com/macbreak hover.com/twit

Safari bug, Netherlands App Store ruling, Apple Watch ads Microsoft will buy Activision Blizzard, a bet on games being central to the internet's future. Safari bug can leak some of your Google account info and recent browsing history Netherlands App Store ruling: Apple will allow alternative payment methods, but developers must maintain a separate app binary Possibility of huge changes to App Store as US antitrust bill proceeds to committee Senate Judiciary Committee will consider The American Innovation and Choice Online Act this week; Tim Cook personally lobbying Senate Judiciary Committee against it Apple Watch Series 7 | 911 | Apple Apple Watch "911: Bob" Detectives | Cinematic mode | iPhone 13 Pro | Apple iPhone 14 Pro now rumored to feature 'hole + pill design' instead of notch Likely new iPhone SE and iPad Air models appear in Eurasian database Report: iPad Air 5 with 5G, Center Stage camera, and more coming this spring Report: 'iPhone SE+ 5G' coming this year followed by the larger model in 2023 Locket, an app for sharing photos to friends' home screens, hits the top of the App Store Microsoft Releases Office for Mac Update With Full Apple Silicon Support in Excel Tesla refuses to adopt CarPlay, but this developer has a workaround Aerial app for Mac updated with tvOS 15 screensavers and new features Picks of the Week Rene's Pick: Above Avalon Andy's Pick: Multiselect for YouTube, U.S. free COVID tests Alex's Pick: Live Video in Keynote Hosts: Leo Laporte, Alex Lindsay, Rene Ritchie, and Andy Ihnatko Download or subscribe to this show at https://twit.tv/shows/macbreak-weekly. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: expressvpn.com/macbreak zocdoc.com/macbreak hover.com/twit

Proponen agrandar Nueva York sobre el mar / con_palabras_separadas mejor que ConPalabrasJuntas / REvil detenidos / Fallo de privacidad en Safari / Baby Shark rompe récords / ¿Han roto el cifrado de Signal? Patrocinador: Cuidado con las Macros Ocultas https://www.cuidadoconlasmacrosocultas.com/ es un podcast de divulgación tecnológica para empresas impulsado por Cuatroochenta que responde a preguntas clave de nuestra época en cada episodio: ¿Cómo es un ciberataque desde dentro?, ¿cuál es el impacto medioambiental de la nube?, ¿qué cambiará realmente la IA? — Suscríbete en Spotify https://open.spotify.com/episode/1IyJTLfo2XlrwNwwm0q2gp?si=2gOAVIqdR3yDHLlRU3CX5g, Apple https://podcasts.apple.com/es/podcast/cuidado-con-las-macros-ocultas/id1582767310?i=1000547511042, Ivoox https://www.ivoox.com/m05-automatismos-robots-avatares-el-nuevo-digital-audios-mp3_rf_80668395_1.html, Google https://podcasts.google.com/feed/aHR0cHM6Ly9vbW55LmZtL3Nob3dzL2N1aWRhZG8tY29uLWxhcy1tYWNyb3Mtb2N1bHRhcy9wbGF5bGlzdHMvcG9kY2FzdC5yc3M/episode/ZjgxYjg5MDQtODAyYi00MjI5LTk3Y2ItYWUwODAwOTdhZWVi?ep=14, etc. Proponen agrandar Nueva York sobre el mar / con_palabras_separadas mejor que ConPalabrasJuntas / REvil detenidos / Fallo de privacidad en Safari / Baby Shark rompe récords / ¿Han roto el cifrado de Signal?

Rafael is Joined by James Long to talk about ActualBudget, a "privacy focused" personal finance application with some unique technical characteristics. They talk about some of the benefits of offline-first applications from a product perspective, and some of the interesting and unexpected things about developing an application that diverges from the standard Server-Client SaaS model. They also go deep into the weeds to talk about absurd-sql, a project where sqlite is implemented using indexedDB instead of the filesystem as a persistence layer. James Long on twitter: https://twitter.com/jlongster Actual Budget: https://actualbudget.com/ Patrick McKenzie: https://twitter.com/patio11 The blog post about absurd-sql: https://jlongster.com/future-sql-web LogSeq: https://logseq.com/ Yjs: https://github.com/yjs/yjs

Rafael is Joined by James Long to talk about ActualBudget, a "privacy focused" personal finance application with some unique technical characteristics. They talk about some of the benefits of offline-first applications from a product perspective, and some of the interesting and unexpected things about developing an application that diverges from the standard Server-Client SaaS model. They also go deep into the weeds to talk about absurd-sql, a project where sqlite is implemented using indexedDB instead of the filesystem as a persistence layer. James Long on twitter: https://twitter.com/jlongster Actual Budget: https://actualbudget.com/ Patrick McKenzie: https://twitter.com/patio11 The blog post about absurd-sql: https://jlongster.com/future-sql-web LogSeq: https://logseq.com/ Yjs: https://github.com/yjs/yjs

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby GitHub Processes 2.8 Billion API Requests Per Day… with Ruby (notes) Ruby 3.1 adds Enumerable#compact and Enumerator::Lazy#compact Rails 7 provides context when logging unpermitted parameters AnyCable Goes Pro: Fast WebSockets for Ruby, at scale The Best Ruby Blogs Rhizome - a JIT for Ruby, implemented in pure Ruby ActiveAnalytics - first-party, privacy-focused traffic analytics for Ruby on Rails applications Web Next.js 11 Benchmarking JavaScript Memory Usage Embedding Vue.js Apps in Go The pain and aguish of using IndexedDB: problems, bugs and oddities OpenPGP.js - OpenPGP JavaScript Implementation SwiftLaTeX - a WYSIWYG Browser-based LaTeX Editor Div.js - a framework for the HTML programming language Illustrated guide to Apache Kafka RWpod Cafe 23 (03.07.2021) Сбор и голосование за темы новостей

In episode 05 of the Let's Connect! Podcast, Nikunj Mehta, CEO and Founder of Falkonry, joins us to talk about his Intelligence-first approach to IoT.Nikunj Mehta founded Falkonry after realizing that very valuable operational data produced in industrial infrastructure goes mostly unutilized in the energy, manufacturing & transportation sectors. Nikunj believes hard business problems can be solved by combining machine learning, user-oriented design & partnerships. Prior to Falkonry, Nikunj led software architecture & customer success for C3 IoT. Earlier, he led innovation teams at Oracle focused on database technology & led the creation of the IndexedDB standard for databases embedded inside all modern browsers. He has contributed to standards at both W3C & IETF, & is a member of the ACM.Interested in connecting with Nikunj? Reach out on Linkedin!Falkonry is the innovation leader in Operational AI. Falkonry enables predictive operational excellence for manufacturing and defense organizations by detecting and predicting events before they impact operations. By applying AI on real-time operational data from plants and field systems, Falkonry solutions deliver significant improvement in production uptime, quality and yield without requiring data scientists or data engineers. Falkonry products easily scale across the enterprise either on-premises, in the cloud or at the edge, and are optimized to run on major cloud platforms including Microsoft Azure and AWS. Falkonry's Operational AI based products are built for operations teams to reduce planned and unplanned downtime, discover anomalous conditions, capture expert knowledge, provide root cause analysis, estimate time to critical events like time to failure, remaining useful life and show all this information through an executive dashboard making it easier for all stakeholders to understand and apply this analysis.  Follow Falkonry on Twitter! 

What happens when you have a connection that isn't working, but you have a mission-critical document that you need to collaborate on with others around the world? The problem of peer-to-peer collaboration in an offline environment is becoming an increasingly pressing issue for editorial organizations and enterprises. As we continue to work on documents together on flights, trains, and buses, offline-first shared editing is now a base-level requirement rather than a pipe dream. Yjs, an open-source framework for real-time collaboration, integrates gracefully with IndexedDB, the local offline-first database available in browsers, to help developers easily implement offline shared editing for their organization's needs. Paired in turn with other technologies like WebRTC, a peer-to-peer communication protocol, and Yjs connectors, a graceful architecture is possible that not only enables offline shared editing for a variety of use cases beyond textual content but also makes the developer experience as straightforward as possible. In this technical and topical deep dive into how Yjs and IndexedDB make offline shared editing possible, join Kevin Jahns (creator of Yjs and Real-Time Collaboration Systems Lead at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Michael Meyers (Managing Editor at Tag1), and your host Preston So (Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) for a Tag1 Team Talks episode you don't want to miss about how to enable offline shared editing for web applications and even CMSs like Drupal.

Maximiliano Firtman is a mobile web developer from Buenos Ares, Argentina. He has been a developer for 24 years and his most recent focus has been on progressive web apps, or PWAs. Steve and Max reflect on the technologies they were using when they first got started in web development and talk about their experience with mobile development. One area that Max emphasized was bringing the web into the mobile space. They discuss the progression of web access on mobile and some of the available tools. Max notes that responsible design has a very high cost in web performance for mobile devices, which requires unique approaches. They discuss some of the issues with latency in mobile, even on 4G. The solution to this latency is PWAs. Progressive web apps are a set of best practices to create web apps that are installable. They can work offline at high speeds on several operating systems. Once installed, it looks like any other app on the system. Max delves into more details on how it works. He talks about how the resources for your application are managed. He assures listeners that it’s just a website that’s using a new API, they’re not changing the way the web works, and that when that API is there, the app can be installed. It will also generally use your default browser. Steve and Max discuss how local data is stored with PWAs. To write PWAs, you can use Angular, React, JavaScript, or Vue, and it’s a pretty transparent process. Max talks about some common tools used for local storage and some of the PWAs he’s worked on in the past. The benefit of using PWAs is that they generally run faster than regular web apps. To get started, Max advises listeners to install one and start exploring. Panelists Steve Edwards Guest Maximiliano Firtman Sponsors G2i ____________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Progressive Web Apps Appsco.pe IndexedDB Max's site Picks Steve Edwards: The Club Maximiliano Firtman: Llama Follow Max on Twitter

Maximiliano Firtman is a mobile web developer from Buenos Ares, Argentina. He has been a developer for 24 years and his most recent focus has been on progressive web apps, or PWAs. Steve and Max reflect on the technologies they were using when they first got started in web development and talk about their experience with mobile development. One area that Max emphasized was bringing the web into the mobile space. They discuss the progression of web access on mobile and some of the available tools. Max notes that responsible design has a very high cost in web performance for mobile devices, which requires unique approaches. They discuss some of the issues with latency in mobile, even on 4G. The solution to this latency is PWAs. Progressive web apps are a set of best practices to create web apps that are installable. They can work offline at high speeds on several operating systems. Once installed, it looks like any other app on the system. Max delves into more details on how it works. He talks about how the resources for your application are managed. He assures listeners that it’s just a website that’s using a new API, they’re not changing the way the web works, and that when that API is there, the app can be installed. It will also generally use your default browser. Steve and Max discuss how local data is stored with PWAs. To write PWAs, you can use Angular, React, JavaScript, or Vue, and it’s a pretty transparent process. Max talks about some common tools used for local storage and some of the PWAs he’s worked on in the past. The benefit of using PWAs is that they generally run faster than regular web apps. To get started, Max advises listeners to install one and start exploring. Panelists Steve Edwards Guest Maximiliano Firtman Sponsors G2i ____________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Progressive Web Apps Appsco.pe IndexedDB Max's site Picks Steve Edwards: The Club Maximiliano Firtman: Llama Follow Max on Twitter

Maximiliano Firtman is a mobile web developer from Buenos Ares, Argentina. He has been a developer for 24 years and his most recent focus has been on progressive web apps, or PWAs. Steve and Max reflect on the technologies they were using when they first got started in web development and talk about their experience with mobile development. One area that Max emphasized was bringing the web into the mobile space. They discuss the progression of web access on mobile and some of the available tools. Max notes that responsible design has a very high cost in web performance for mobile devices, which requires unique approaches. They discuss some of the issues with latency in mobile, even on 4G. The solution to this latency is PWAs. Progressive web apps are a set of best practices to create web apps that are installable. They can work offline at high speeds on several operating systems. Once installed, it looks like any other app on the system. Max delves into more details on how it works. He talks about how the resources for your application are managed. He assures listeners that it’s just a website that’s using a new API, they’re not changing the way the web works, and that when that API is there, the app can be installed. It will also generally use your default browser. Steve and Max discuss how local data is stored with PWAs. To write PWAs, you can use Angular, React, JavaScript, or Vue, and it’s a pretty transparent process. Max talks about some common tools used for local storage and some of the PWAs he’s worked on in the past. The benefit of using PWAs is that they generally run faster than regular web apps. To get started, Max advises listeners to install one and start exploring. Panelists Steve Edwards Guest Maximiliano Firtman Sponsors G2i ____________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Progressive Web Apps Appsco.pe IndexedDB Max's site Picks Steve Edwards: The Club Maximiliano Firtman: Llama Follow Max on Twitter

Fredrik talks to Nolan Lawson - web performance expert, Mastodon instance maintainer, creator of a highly accessible Mastodon web client, and more. We discuss, among other things, the joys of distributed social media, where unlike centralized places like Twitter nobody can stop innovation when it comes to clients and interfaces and ways of use. Nolan talks about how and why he built Pinafore - his Mastodon client. We touch on the different experiences people have and want out of social media, digital wellness, and how caring about performance cam be an act of empathy. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Nolan Lawson Salesforce Pouchdb Mastodon Open source maintainer guilt Toot.cafe - the Mastodon server Nolan runs Ruby Brent Simmons Glitch Darius Kazemi Hometown - Darius' fork Eugen Rochko - creator and maintainer of Mastodon Mastodon terminology and ways of working Ruby on rails React Webpack How to write a carousel Van Halen’s M&M rider clause Built-in modules Curl Pinafore Progressive web apps Service workers Cross-origin resource sharing - CORS Gilbert and Sullivan - and their Pinafore Tweetdeck Blurhash - and on Github OCR - optical character recognition Tesseract.js WASM - Webassembly Emscripten Wellness settings in Pinafore Emoji mart - the emoji picker library Svelte Vue Babel JSX Rollup Accurately measuring layout on the web requestAnimationFrame High-performance input handling on the web Browsers, input events, and frame throttling Pointer events Local storage Indexeddb Intersection observer Resize observer Titles I was really excited Falling in and out of it Tweets are toots The goal of a lot of web standards I really mistrust a library I believe in the open web Eugene had already thought about this Mixed degrees of success My preference is single column She’s on weird Mastodon It’s all kind of cacophonous, but it’s beautiful at the same time Every component has a bit of Svelte in it It’s really based on empathy

Comment stocker des données dans le navigateur, quelle solution choisir entre LocalStorage et IndexedDb et comment utiliser ces données en hors-ligne. On parle Progressive Web App et stockage dans le nvaigateur avec Flavien Beninca de Commit42.

Scott and Wes dive into the ins and outs, best practices and tasty tidbits of Progressive Web Apps. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” section. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It’s an exception tracker, a session replayer and a performance monitor. Get 14 days free over at https://logrocket.com/syntax Show Notes 2:00 What’s the deal with the GitHub / Microsoft acquisition? 6:05 What is a Progressive Web App? 8:55 - Progressive Web App Checklist What are the baseline features for a Progressive Web App? 09:25 Site is served over HTTPS Let’s Encrypt 11:05 Pages are responsive on tablets & mobile devices 11:35 All app URLs load while offline Use a Service Worker 16:35 Metadata provided for Add to Home screen 18:40 First load fast even on 3G 20:00 Site works cross-browser 20:15 Page transitions don’t feel like they block on the network 22:20 Each page has a URL What makes an exemplary Progressive Web App? 27:42 All content is indexed by Google 28:38 Schema.org metadata is provided where appropriate Social metadata is provided where appropriate 29:42 Canonical URLs are provided when necessary User experience 31:43 Content doesn’t jump as the page loads Scott’s Pro Gatsby Course 36:52 Pressing back from a detail page retains scroll position on the previous list page 37:34 When tapped, inputs aren’t obscured by the on screen keyboard The Best of the rest 38:22 Content is easily shareable Site is responsive Any app install prompts are not used excessively The Add to Home Screen prompt is intercepted 39:20 Use cache-first networking Device APIs 40:34 Web RTC Get User Media 41:50 Push API 45:12 Accelerometer GPS 45:55 Payment Request API 47:12 Local Storage 48:03 IndexedDB 48:35 StorageManager 51:45 Vibration API 52:58 Use Lighthouse to improve the quality of your web apps ××× SIIIIICK ××× PIIIICKS ××× Scott: myNoise Wes: Ozark Trail Drinkware Shameless Plugs Scott’s Level 2 React Course Wes’ Courses Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

Dan Gebhardt: @dgeb | Cerebris Show Notes: 01:33 - The JSON API Spec and Pain Points it Solves 08:40 - Tradeoffs Between GraphQL and JSON API 19:33 - Orbit.js 26:30 - Orbit and Redux 32:22 - Using Orbit 37:24 - What's coming in Orbit? Resources: orbitjs.com (Guide Site) ember-orbit Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 87. My name is Charles Lowell, a developer here at the Frontside and your podcast host-in-training. Joining me today in hosting the podcast is Elrick Ryan. Hello, Elrick. ELRICK: Hey, what's up, Charles? CHARLES: How are you doing today? ELRICK: I'm doing great. CHARLES: Are you pretty excited? ELRICK: I'm very excited for this podcast because this is a topic that I've heard a lot about but don't know much about and it just seems so awesome that I'm just very stoked to hear all the details today. CHARLES: Yeah, me too, especially because of who's going to be giving us those details, he's one of the kindest, smartest, most humble and wonderful people that I've had the pleasure of meeting, Mr Dan Gebhardt. Hello, Dan. DAN: Hey, Charles. Hey, Elrick. Thanks for having me on. I really enjoyed listening to this podcast. It's nice to be part of one. CHARLES: It's good to have you finally on the show. We talked over chat and we talked over email and we meet every once in a while and conferences and it's great to get to share more widely some of the great conversations that always arise in all of those contexts. For those who don't know you, you are a founder at Cerebris and that is your company, which is involved very heavily in a lot of open source projects that people are probably familiar with. One of them that we're going to be talking about today is JSON API. I bet most people didn't know that you are one of the biggest driving factors behind both the specification and several of the implementations out there. DAN: Yeah, that's been a pretty core focus of my open source work for the last few years. Actually JSON API Spec, which is perhaps a somewhat confusing name for those who aren't familiar with it. It was started by Yehuda Katz in almost three and a half years ago, I think now and it hit 1.0 a couple years ago and has stabilized since then and we've seen a lot of interesting implementations on top of it. There are some exciting stuff that's actually coming soon to this Spec that I'd like to share with you guys today. CHARLES: To give us a little bit of context, why? What pain am I experiencing that JSON API is going to solve or it's going to address or give me tools to deal with? DAN: One of its prime motivators is the elimination of bikeshedding. There's a lot of trivial decisions that are made with every implementation of an API and JSON API makes a lot of those decisions for you about how to structure your document, how to include relationships and lengths and metadata in a resource, how to represents relationships from hasOne/hasMany. Even polymorphic relationships have a type of that data. JSON API has opinions about all these things at the document structure level and it also has opinions about our protocol usage, how to use HTTP together with this media type to make requests and for servers to return responses, how to create a resource, how to add resources to relationships and things like that. CHARLES: Also, it's not just this is a serialization format. It's very much like also delving into the individual interactions and how they should be structured, more about the conversation between client and server. DAN: Yeah, in that way, it is somewhat unusual as a media type that covers both. CHARLES: Can you dig into that a little bit because I'm very curious? Something made my ears prick up was when you said, it tells you how to, for example add relationships to a resource. What would that look like? DAN: A lot of the influences behind JSON API are hypermedia-related. It's influenced by RESTful principles and includes a lot of hypermedia aspects. One aspect is how a resource represents relationships in terms of the data in document, the type and the ID that specify a linkage to that another resource in the same document but it can also include links to discover those relationships. There's a self-link for a relationship and a related link for relationship and the self-link will return the data for that relationship in the type/ID pairs. The related link will return the related resources. The Spec doesn't have strong requirements or any requirements about URL usage but instead, it describes where to find resources through these hypermedia links. If you want to say, add records to a relationship, you'd follow the self-link for that relationship when that was returned with a resource. Then you would send a post to that endpoint and you would include the relationship data in the terms of type and ID pairs. It gets down to that specifications so that removes the ambiguity of how to interact with these resources and mutate them and retrieve them. CHARLES: I see, so is there an idea then that you are going to explicitly model the relationships as individual resources? Or is that the recommendation or the requirement? DAN: The link for a relationship would point to an endpoint, which would then model the relationships that are represented that endpoint, so to say just to speak a little more concretely because certainly, it makes some simple concept sound a lot more esoteric than they really need to be. Let's just talk about an example. Let's say, we're talking about articles and comments and maybe an author. Let's say, you've fetched a collection of articles from an article's endpoint and within the article resource, you would have a relationships number, which would include comments and then comments could have links, which one of the links would be a self-link and a related link. The related link could be followed to then retrieve all the comments for that particular article. You could also, if you wanted to add a comment for that article, post to the self-link for that relationships. You post to that whatever endpoint that is specified. Maybe it's 'articles/1/comments.' It could be anything that you want. Now, the Spec does have some recommendations to make everything fit nicely in terms of the URL design patterns and such but those are not, by any means required but having those recommendations just eliminates more bikeshedding opportunities. We find it that people who are gravitate towards the Spec really appreciate having a lot of these trivial decisions made for them so even if we don't want to come down and be hard line about requiring those particular answers, we can at least provide some guidance for how things can work together nicely. There's a whole recommendation section on the site for things like URL design patterns. CHARLES: Right, so things that aren't prescribed but these are best practices that are recognized. DAN: Yeah, exactly. CHARLES: A question then that comes to mind, it sounds like JSON API solves a lot of these bikesheds or just kind of comes in and takes one side or the other for modeling both the resources and the relationships between those resources so there's the... I don't want to call it a schema but the boundaries around which resource are very clear and where they live and how they connect together. I was hoping we could maybe contrast that with some another approach, which is also become very popular and that's the GraphQL approach where you're essential assembling views at runtime for the client. It's very easy to marshal the data that you need to present to your view because you've got only one endpoint, as opposed to having to coordinate between them. I can understand the appeal of that and I was wondering if you have any insight into what the tradeoffs are between the systems and what are some of the capabilities that one can do that the other can't. CHARLES: Yeah, sure. I'm glad that you brought that up because I feel like GraphQL has become a real juggernaut, at least because of its marketing. It's very effective in being marketed for its use to developers and it's capabilities versus REST, as if a RESTful system can't possibly achieve the same outcome or the same efficiency. I'm glad to compare and contrast the two. To be honest, one of our short term goals is to better tell the story on the JSON API site, which was always a kind of a more technical spec-y site and a marketing site. That hasn't really helped its uptake as much as it could as some of the GraphQL sites are very sleek and polished. Anyway, let's get down to it. GraphQL allows you to basically define the data that you want for a particular view and that can bring together multiple related resources. It defines a way to specify exactly which fields you want in that graph of resources. We'll just stick with the articles, comments and authors example. You can specify that you want a collection of articles and perhaps the comments-related to that and the authors and you could have it all assembled in a single response. JSON API also allows you to do just that. It allows you to make requests for multiple related resources to constrain the fields that are returned for each resource and to include all of these related resources in a single document. The main difference in the representation is that JSON API requires that resources only be represented once in a single document. GraphQL may have repetition of resources throughout the document that's returned. For an instance, your articles that may nest authors and those authors like Charles Lowell, may have written three of those articles and that representation of that author is going to be repeated in that JSON API compound document, which is a term for document, which has a primary dataset combined with related resources. That single author would only be returned once as related resource and the linkage between the primary data and the related resources would be established to type/ID pairs. Instead of having the author represented three times, the same type/ID pairs would just be providing that linkage to the same author and that author resource would only be represented once. This happens to be ideal for client-side applications that number one, basically want to minimize the size of a payload that sent. Number two, don't want to after-handle repetition of data by doing extra processing of pushing the same record multiple times into a memory store that is keeping that data. I think that GraphQL is well-suited to applications that request data and display that data pretty much as returned. There is no intermediate holding onto that data in, say a memory store for later access. Basically, it lines up well with a component library link React, which wants to display that data that's returned from the server. If it wants to display that collection again, it will simply request that collection again and pretty much throw away the data once it has been rendered. CHARLES: I can see that. Dan, you and I might be some of the only folks who remember. I don't know if you ever did any Microsoft Access Program. DAN: Yes, I did, believe it or not. CHARLES: Doesn't it feel a little bit like the Access pattern all over again, where you have your components requesting data from basically, constructing a query and requesting it -- DAN: Yeah. CHARLES: And then throwing it up on the screen. DAN: You're going deep there but I do remember that. Definitely, there is that same paradigm. CHARLES: It's really powerful. DAN: It is and it's pretty accessible too because it's a direct representation of what you've requested and there's no intermediate processing. I guess the question is, whether that intermediate processing provides some value. Actually, holding onto that data provided some value because as far as I'm concerned, GraphQL is great for that rendering of DOM data, where the data has no meaning except outside of the rendering. But if you want to actually have models that have some intelligence about that data, then you want to use a store to keep those models in and you want to be able to reuse those models for other purposes. CHARLES: What might be an example? What's a concrete use case that we can ground this discussion? DAN: I would say that the big one is offline. You simply can't have just DOM data that's useful in any way in an offline application or an optimistic application, where you are doing some things client-side and only say undoing them if a request fails. But if your data is DOM and only structured for a particular view, then all you can do with that is redisplay that view. But if you understand the schema of your data and that data is available in a store, then regardless of whether you have a network connection, you can actually display that data in different ways. If that same article shows up in a collection in a list, you could also display that article on its own in a different format with more fields. If you want to, say allow editing of that data, you could allow for an editor when your app is offline. Allow changes to be made to that data and then redisplay it because you understand the fields that are in that data. CHARLES: Right and then at some point later, then spool those changes back to the server. DAN: That's right. CHARLES: It almost sounds like, ironically if a system like JSON API where you have very concrete boundaries around each of the underlying resources in your data model, it allows you to essentially do rich-querying on the client and not just the server. DAN: Yes, that's absolutely true. CHARLES: Because I feel like what you just described to me it's like, now we have some sort of store over which we can map all kinds of different queries to our own liking and there's no dependency on the server. DAN: Yeah and if you just want more web app to be pretty much a view representation of what's on the server and without additional intelligence, then GraphQL really lines up well with your needs because any extra processing you're doing is just not valuable to you. But I think a lot of the really interesting things being done in client-side applications are where your client application is pretty loaded with a lot of intelligence and you're out there autonomous and able to make sense of data. In that case, then thinking about the data only as it pertains to views is not nearly as powerful. CHARLES: Right, so you could do something like that with GraphQL but then you would have to, essentially structure your queries such that they drew the boundaries around the individual resources anyway, rather than composing them on the server. You'd have to query them discreetly into a store and then run your local operations. Then I guess at that point, it's like what are you doing? DAN: Yeah, you're still doing the extra processing of handling the repetition of any nodes that repeat and such. That's just extra processing you have to do but I agree that you certainly could structure your GraphQL queries to return data that is then loaded, say to a store that really has awareness of the data types but I don't think that is -- CHARLES: But then you're defeating the purpose, right? DAN: Yeah, it's not its selling point and it's not its strong suit. CHARLES: You've done a lot of work on the JSON API Spec. JSON API allows you to fetch discrete resources and their relationships but still, keeping one representation of each resource in the payload so it's optimized for wanting to do client-side processing and have intelligence based on these entities, which are in a store. You actually maintain a fairly mature, at this point, framework called Orbit, which helps you do some of these things. Now, what Orbit does today and I understand that you've got a lot of new features that are really exciting, that are coming down the pike. Before we get into those, what is Orbit and what do you use it for and how does it use JSON API? DAN: Orbit is a data access and synchronization library, which sounds sufficiently vague because it has a lot of low-level primitives for structuring client-side. Also, actually isomorphic can be run on the server and nodes so it's not even only used for client-side purposes but that was its original purpose. The abstraction that it includes are allowed for synchronization of data changes across multiple sources of data. Source of data might be represented by, say a JSON API server, an in-memory store, an IndexedDB database in your browser, a local storage, all of these sources of data can support an Orbit interface, which provides their access to their data and also broadcasts changes to that data. In order to coordinate the changes across multiple sources, say to back up all of your data that's in memory to IndexedDB source, you can observe the changes on one source and then sync those changes up with another. For instance, you want to structure an offline application which you have been in-memory store, which uses client-generated IDs, which then syncs up with a backend JSON API source and every change that gets made to the memory store needs to be backed up, you could configure multiple coordination strategies between the sources to make sure that the data flows so that every change that is made to the store is immediately backed up to IndexedDB. If it can't be backed up, then it fails. You can add some error handling and then when you're online, you can then also sync those changes up with a backend so you're basically pushing those changes that are local to a remote store and you're not slowing down your offline app, which you're communicating with optimistically and then only handling, say synchronization failures when there is a problem. In order to handle those problems, Orbit sources are very deterministic about their tracking of changes and they provide get-like rollback capabilities so you can look at the history of changes to a particular source and reset the history to any point there and basically handle conflicts and merges in a very get-like way. Often I use cases, the primary driver of Orbit's whole architecture, I realized that it needed to be able to give you the tools to handle any conflicts that happen when changes get sync up. Also, give you the different tools to model all the different places of data is kept in order to support the offline mode. That's a kind of a broad overview of Orbit. There's a new guide site, OrbitJS.com for those who want to dig a little deeper into it. The data is structured in the JSON API format internally to the store and the standard operations are very much influenced by the standard JSON API protocols that are allowed in the base Spec over creating records and removing records and all that crud for both records and relationships. That's where JSON API comes into Orbit. CHARLES: Right, I see. The primary use case for Orbit is offline. Is that fair to say? DAN: Yeah, that was the primary driver, although it's just not the primary -- CHARLES: It seems like you could use this in a lot of places where I might use Redux or something like that, like on the server to model... I don't know, a chat app. DAN: Yeah, definitely. CHARLES: I have a bunch of different information streams coming together and how am I going to merge them and make sense of them. DAN: Yeah, in fact, that it's primitive level. Orbit has essentially an async redux-like model for queuing up changes and applying those changes. The change sets are all immutable. There's actually a lot of immutability use here throughout the library. In order to ensure that the changes that are applied are tracked deterministically, we just can't have those changes mutating on us. There is definitely some overlap with Redux concepts in terms of the general tasks or action concepts in Redux but instead of Redux's synchronous approach, everything in Orbit is async. CHARLES: What does that mean? Redux is synchronous in the sense that there's a natural order to all actions. For those of us familiar with Redux, are you saying it would be like a store where actions can be dispatched at any time or is it more like, I've got multiple stores happening and I need to resolve them somehow so each one is synchronous? How can I make sense of that? DAN: In Redux, the actual application of an action is performed synchronously. CHARLES: Right. You can have asynchronous processes but there is a natural order to the actions that those asynchronous processes yield and then those are applied synchronously to the Redux Store. DAN: Yeah. To compare and contrast Orbit and Redux, I guess you'd first have to say there's a primary difference of -- CHARLES: I think there are a lot of people are familiar with Redux. I think it's not so much to compare and contrast it but just to use it is as an analogy of like, "Here's how it's the same here. Here's how it's different," because that's compare and contrast. DAN: There you go. CHARLES: But not in terms of evaluating them but it's like, "Maybe I should be using this instead." DAN: Right, they are sort of on different levels, although there are some primitives in Orbit to it and it's shipped across multiple libraries. There are some primitives, I think that could be useful outside of the main Orbit data application. Anyway, the way that Redux state changes are applied, the function is synchronous is all I was getting at and on Orbit, every state change that applied to a source is asynchronous so the result is never applied immediately. You'll always get a promise back and you'll never have that application happen immediately. That's one clear distinction. Another is that a redux has a big singleton global state for the entire application. Orbit very much has a model of state per source so there can be any number of sources in a particular application and the source might be an in-memory source or might represent a browser storage in XTP or might represented a socket that streaming data in. All of these have state at different, temporarily distinct state that even if they all converge to a common state, the Orbit models separately so that there's a set state per source. I'm just contrasting the global apps state that exists in Redux with the per source state in Orbit. CHARLES: It sounds like there's nothing that would be fundamentally incompatible of using Orbit really in conjunction with Redux, where Redux is kind of a materialized view of all of your different data sources presented as what you're going to render off of, right? DAN: Yeah. You could use it in a similar way to Redux Saga, where Orbit fills the role of Saga, where it's doing the asynchronous actions that results flow back into the Redux state. CHARLES: I'm just imagining having one big global atom, which is your Redux store and now I'm saying, prescribing this is an optimal architecture but I'm saying, one way it could work is it picks and chooses and assembles off of the different sources as new data becomes available. As the states change for those sources, it can be integrated into a snapshot state, which is suitable for rendering or provides one view for rendering. DAN: Yeah. You're basically talking about the in-memory source, perhaps merged with other applications state, which is not so resource-specific and that is possible to model. CHARLES: What I think I might be hear you saying is you could also just use another source which is the merge itself. DAN: Yeah. I'm not sure how much we want to continue this thought exercise because the architecture becomes almost not something I'd recommend. But I would actually like to explore how Orbit and Redux could be used together optimally. I played around a bit with Redux but I have not written a full-fledged application with it, other than a [inaudible] location. I definitely defer to you for Redux best practices and such and how people are using it in real world applications but I'd be really interested to talk that over again soon. CHARLES: Well, I just certainly don't count myself a Redux expert, although we have developed some applications with it. We'll put that on the back burner or something to explore it later. I will say this, I find Redux to be both wonderful and terrible, kind of in the same way the Java is both wonderful and terrible. We'll leave it at that. DAN: Okay. ELRICK: That was going to be my question. This is why I was very excited to hear about today was Orbit because I've heard so much about it. In terms of the implementation of Orbit into an application, what would that look like from a high-level? Has anyone used Orbit in the production app? Have you built any apps using Orbit? DAN: Yeah, definitely. There are people using Orbit with React, with Vue, with Angular and with Ember and there's an integration library called ember-orbit which makes Orbit usage really easy in Ember. In a lot of ways, working with ember-orbit feels a lot like working with Ember Data but it allows a lot more flexibility. I suppose one of its strengths and weaknesses is there's a lot of configuration that's possible because there's a lot of possibilities. The internals are exposed of how data get synchronized so you can define your strategies and sync up different sources. In terms of how it's actually used in an application, you'd start by modeling your data in terms of the resources that are in the application. You'd have a schema that defines your articles, your comments and your authors, just to keep that example going. Then that schema would be shared among all the sources in your application. You would have one source, say that might be the in-memory source and another source that is the representing a browser storage so you could, say swap out either local storage source or an IndexedDB source and use either one to provide that backup roll. You would declare those sources, you connect them to each other with strategies so that, say when memory storage changes, you would then sync that change to the browser storage source. Then you'd have back up and you'd be able to then, refresh your page and view the same data you were looking at before. Now then, if you probably want to wire up a remote source so that you're communicating with the servers so you bring in JSON API source and you would then set up a new strategy for working with that. You have to decide like, "When my memory storage changes, do I want this change to happen optimistically or pessimistically?" By that I mean, "Do I only want it to appear successful if it's been confirmed by the server." Depending upon whether you want to be optimistic or pessimistic, you setup your strategies a little differently. If you handle this change pessimistically, you wanted to block success on the successful completion of pushing of that change to your remote server. You have the set of tragedies that define the behavior of your application and then doing your crud operation is probably pretty much directly with your memory source. Then if you wanted to, say do an edit in a form, you might fork the store, now the store keeps its data in an immutable data structures. That forking that store is very cheap so you don't have a bunch of data that's copied. You're just keeping a pointer to that and getting a new pointer to that same immutable data structures. Every time they get changed, there been new references. There's an immutability under the hood but you're pretty well insulated from the annoyances of working with that immutable data structures. At that form, you make your changes, you then merge your changes back, you'd get a condensed change set of operations that then can flow through your strategies. It flow through to your backup source. It could flow through to the back to the server. I think it would feel pretty familiar for users of Ember Data because there are a lot of the API influences came from that library. But obviously, people are using just plain Orbit with other libraries, with other frameworks and finding it useful there but it definitely involves a little more configuration up front to do all that wiring that might be more implicit in library like Ember Data. CHARLES: I understand that before we go, there is some pretty exciting new things coming in Orbit. Do you feel like you're ready to mention a couple of those things or they've been kind of mixed in with the conversation? DAN: Let's see. I have the guides up, which I mentioned, which is pretty new in the last couple of months. In the last year, we did a rewrite and Orbit is now completely in TypeScript and there are no external dependencies. For a while there, I was using RxJS and observables internally and immutable JS so there's now an internal immutable library. It's lighter-weight with fewer dependencies now. I'm excited about that and finally feel like I can recommend people digging in with the guides that are up. I'm hoping to get up the API docs soon. I will say I'm excited. I just got back from a retreat in Greece. Séb Grosjean who owns the company, BookingSync does this amazing thing with the Ember community, where for the group that's working on Ember Data, he invites them every year to come to his family's place in Greece. He grew up working with his family on his rental properties, which was the inspiration for his company, BookingSync and said, "This is a fantastic opportunity that for us to get together and collaborate in a really nice place," and I had a really productive time this last week. This is the very first time I had gone. It was just fantastic and I worked with the Ember Data team. Igor Terzic and I spiked out some interesting collaboration between Orbit and Ember Data so I'm really looking for it to see where those go and hopefully, we'll see a little bit more Orbit, either directly or just through influence appearing in Ember Data. I'm looking forward in working more closely with the Ember Data team. We'll see what comes of that. CHARLES: Yeah, I, for one am very excited to see it. I'm resolved now. I'm just looking at these guides. These look fantastic and I'm resolved to give Orbit, at least a try here, either in some of our applications or maybe trying to spin up some new ones and have it the basis for some of ideas I've been playing with. DAN: That would be awesome and there's a [inaudible] channel, which I hang out into if you have any questions, if anyone out there does. CHARLES: Before we go, if anyone is interested in JSON API, is interested in Orbit, is interested in Cerebris, we mentioned a lot of things that in one way or another, map back to you. How do we get in touch to find out more about these different entities/projects? DAN: I'm at @DGeb on Twitter. My company site is Cerebris.com. Also check out, OrbitJS.com for the new guides. Reach out to me. I'm on the Ember Core Team so I'm also hanging out in the Ember community Slack, depending upon what you want to talk with me about. I'm in all these different places so I love to hear from you all. CHARLES: All right. Fantastic. We'll make sure that we put those in the show notes and I guess that's about it. Do you have anything else you want to leave folks with, any talks, papers or big news coming around soon? DAN: Something that we didn't really get a chance to talk about today, which I'm really excited about is JSON API operations, which is an extension to the base Spec, which I'll be proposing very soon. There's a future to the JSON API once it hit 1.0 a couple of years ago. It didn't just stop. We're looking at different ways to extend the base Spec and use it for different and interesting purposes. JSON API operations, I think one of the most interesting ones. The idea is basically to allow for multiple requests that are specified in the base Spec to be requested in a batch and perform transactionally on the server so the Spec will define how would each request gets wrapped. Each operation very much confirms with the base Spec concept of a request. For implementations, there's a lot of opportunity to reuse existing code for how to handle each particular operation but to provide a whole new set of capabilities by allowing you to batch them together and process and transactional it because it just unlocks a ton of different things you can do, all based on the same base concepts from JSON API. I'm really excited to have something to announce soon about that. CHARLES: That sounds like it might solve a lot of problems that are always associated with those things. It always comes up. What's our batch API look like? I don't think I've been on a project that didn't have a months-long discussion about that. I ended up like kicking it down the road and I'm just flumping something in place. DAN: Yeah, all those messy edge cases where people figure out how do we create multiple related records altogether in a single request and people do it ad hoc and do it with embedding and such and want to standardize that in the same way, that we've standardized the base operations. CHARLES: Well, that is really exciting, Dan. I wish you the best of luck and we'll be looking for it. DAN: Thanks a lot. Thanks for having me on, guys. CHARLES: It was our pleasure. Thanks. With that, we will say goodbye to everybody. Goodbye, Elrick. Goodbye, Dan. Goodbye everybody listening along at home. As always, you can get in touch with us. We're at @TheFrontside on Twitter or you can see our website at Frontside.io or just drop us a line at Contact@Frontside.io. Always love to hear from you with new podcast topics, anything that you might be interested in so look forward to hearing from you all and see you next week.

For most of the web, poor network connectivity destroys the user experience. We can do better. In this session we'll take an online-only site and turn it into a fully network-resilient, offline-first installable progressive web app, and this won't involve rebuilding from scratch; it'll be done in small iterations, with each step improving the user experience whether they're offline, online, or anything in between. This session will cover ServiceWorker, web manifests, add-to-homescreen banners, IndexedDB and BackgroundSync APIs. Video at: https://www.youtube.com/watch?v=cmGr0RszHc8

Mike North: @michaellnorth | mike.works Show Notes: 00:51 - Transitioning from CTO to Independent Trainer 03:37 - Customizing Content and Developing Curriculum 06:37 - Bringing a Developer Into the JavaScript Ecosystem 12:47 - Training Developers with Non-Traditional Backgrounds 16:56 - Keeping Up with “Fifth Gear” 19:27 - Developing Frontend Masters Courses 22:40 - “Progressive Web Apps” 34:37 - Web Security Resources: LinkedIn's REACH Program IndexedDB Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 79. My name is Charles Lowell, a developer at the Frontside and your podcast host-in-training. With me today is Elrick, also at the Frontside. Hello, Elrick. ELRICK: Hey, what's going on? CHARLES: Today, we are going to be talking with Mike North, who is doing all kinds of interesting stuff as per the usual so we'll jump right in. Hey, Mike. MIKE: How is it going? I'm glad to be here. CHARLES: Last time that I saw you, I think it was about a year ago at the Wicked Good Ember Conf and we were standing on the beach, drinking scotch and talking about Fastboot but you were doing something completely and totally different then than you are now so I was wondering, we were talking the conversation before we started rolling, that your role nowadays is independent consultant and personal dev trainer. I was wondering if you talk a little bit about that move from the CTO role that you're playing at your old company to kind of moving into that independent trainer, like why and how. MIKE: Yeah, I do remember talking about Fastboot at Wicked Good Ember. It feels like things have moved quite a bit since then. I have always loved teaching developers. When I've been a team lead, it's the favorite part of my job just because I get profound satisfaction out of helping people get over these hurdles that most of the time took me a much longer time with blog posts and podcasts and incomplete examples and libraries that were out of date and Stack Overflow with half answers. I've decided to dedicate myself to trying to make it easier for people in an increasingly complex web development world to wrap their head around everything. While I was a tech lead or a CTO, I always had to split my focus between helping developers grow and something else. Oftentimes, that something else was where the deadlines were and the time pressure was. It felt a little bit like I was driving a car that only had first and fifth gear where you're like on the bleeding edge of open source and what was the latest commit to master and [inaudible]. Then like, "Oh, let's be extremely patient with this person. They've never seen promises before because they came from another programming language. Let's help them digest this at their own pace." It's this slow and patient process of building up from the fundamentals and then the bleeding edge is like, "Let's use Babel Stage 0." It was very hard for those two aspects to exist at the same time in myself so I decided I'm just going for the training side. That's really all I do these days. CHARLES: It was so, but now would you qualify that as the first gear or the fifth gear? MIKE: That's the first gear. It gets you off the ground. It takes you from stop and gets you moving and then you have to develop your own expertise beyond that. But I like to think I'm developing a really, really excellent first gear. Today for example, I'm converting a bunch of Python developers at LinkedIn who are basically the ops team. I'm teaching them Ember and JavaScript at the same time through a series of about 20 exercises over three days. That process is many weeks long without assistance so this is like, "Let's get rolling much more efficiently and quickly," than via DIY approach. CHARLES: Now, do you find you have to custom-tailor for the environment or the developers moving from like someone coming from, say C# would have a different experience than someone coming from Python? MIKE: Absolutely. When I have my material, I have sections that I can drop. If you are a C# developer, I do not have to explain conceptually what 'async' and 'await' mean. You've been working with that for a while. I probably throw up a little example in C# and then the equivalent in JavaScript to sort of create a bridge from your existing expertise into the JavaScript world. Another one -- this is very true -- is teaching Ruby developers how to use Elixir. You don't have to say, "This is a router. We have controllers. There are actions and controllers." There are so many parallels that really it's more useful to help, rather than teach things from scratch to create connections back to the expertise they already have so they're not starting from zero and they can say like, "In the Ruby world, I would think of doing XYZ." Now, I have a map in between that and this new thing. CHARLES: Obviously, there's a lot, a lot, a lot of languages and environments that you could transition to, probably more than matches your own personal experience, in doing that frontline development. What kind of research do you have to do to develop a curriculum for, say someone coming from Clojure or someone coming from Scala or something like that? Maybe that never happens. MIKE: I have a pretty, pretty broad background. My entry into programming was a subset of C and then I graduated to C++ and Java and Ruby and I used to do ASP stuff. I've written iOS apps. I feel like I have enough of a foothold into various areas like I know one JVM language. That is usually enough. If you're running a lot of Clojure, I can at least speak Java to you because odds are, you're working with that and you're seeing that and you know it. Oftentimes, I have what I need. There are situations where I can borrow something in a very cursory level. Not to rip on Scala but I have not found it valuable to make connections to that particular language for clarity and [inaudible] but I have used Haskell before and I'm not a Haskell developer but it is a pure functional language. When trying to help people understand how is this different, then the JavaScript got them running where the Ruby ends up running. It's useful to use something like that. It's a very small language, very simple and you can wrap your head around the basics. ELRICK: What are some of the particular challenges that you face when bringing in a developer outside of the JavaScript ecosystem into JavaScript since JavaScript is kind of the Wild West that you can do everything in JavaScript? What are some of the challenges you face in bringing in a new developer from Python or C or whatever that may be? MIKE: You put it very well. It is definitely the Wild West. You can do anything if you have enough [inaudible] yourself and enough power to get serious stuff done. Really, it's like the explosion in number of choices and tools, the explosion of complexity. I learned JavaScript when it was something that you sprinkle on top of your Rails app for a little interactivity, a little animation on a screen or something like that. I was lucky to learn it at that point in time when that was the norm because I've been able to gradually accumulate for more than ten years now. The tooling like using Grunt, using Golf, using Brunch and then stepping up to other more sophisticated build tools. I learned those one by one in the context of real projects. Now, it's like the mountain is so high, people don't know where to start so that's a big challenge for developers. To throw them into a meaningful project like if you asked a mean JavaScript developer, not angry but the average JavaScript developer, they're like maybe -- CHARLES: I should dare to say that the average JavaScript developer is mean. MIKE: A little bit and probably maybe [inaudible] with me as well, depending on [inaudible]. But they're going to spin up some project with webpack and Babel and all of these tools. If that's your first exposure to the language and to working with the language, you're operating in an environment that you don't understand. Research shows that is the less effective option there to slowly building things up over time. I spend a lot of time going back to the basics and making sure we're not working with promises until we've explicitly focused on them, chained a couple together, managed errors and then now, we can work with Fetch. We're not going to jump into that and throw ourselves into this deep end of the pool. We want to incrementally build up skills. It takes a little bit longer but when you have that understanding as you're learning, you get a lot more out of it because anything that you can't get a grip on to as you learn it, it sort of just evaporates into thin air and don't retain that, even if you kind of fill in those holes later. CHARLES: Yeah, it could be so hard too. Actually, this has been an experience that I've been having, I would say almost for the past two years, as the tools advance, not only you are starting from a place of not understanding but the tools themselves do not teach you. I've had two moments where I got really mad. One actually was on an Ember project and one was a project using webpack but it was the same fundamental problem where in one I was actually working with someone who was very new to JavaScript and an error happens and the stack trace was some just big bundled garbage that gave no insight at all. MIKE: In vendor.js. CHARLES: Yes, in vendor.js or in bundle JS. It was like, "How is anyone supposed to learn?" The most fundamental thing about working with Ruby or working with Node or working with anything is you get a stack trace. MIKE: Debugging is really hard. I think it just takes a little time reaching out to people who are experiencing the Stockholm Syndrome like most of the time, JavaScript developer. We all are working with Ember CLI and webpack. I'm not ripping on these tools but we're used to that complexity in our lives. When we see that stack trace, we're like, "Oh, well. I probably need a source map. I'll make sure that that's there. It's natural that I'm debugging a file that the browser is not really seeing like it mapped back to my source code debugging." This is natural to us. But if you put that in front of a developer who hasn't been living under those circumstances, the number of times they raised their hand is like, "What the hell is this?" It is just amazing and it really helps. I've reset my expectations to what a normal programming experience should be and JavaScript does not provide that today. That is really challenging to keep someone in the midst of all that. CHARLES: I feel like it's hard and do you think we'll ever achieve that? Or is it just going to be a constant hamster wheel of progress versus the tooling to educate what progress has been made or to communicate what progress has been made? MIKE: I think the tooling is fine but it's just that we have a gap in terms of learning experience. We just need really -- I'm not voluntary here because I've got a ridiculous backlog -- a couple long tail horses working with vanilla JavaScript, rendering some stuff on the screen, maybe a course of React but no JSX yet, just create component. A couple of things to fill in a gap between where maybe code school leaves off and where you are expected to be by the time you start interviewing for a spot as frontend developer on a team but there's a huge chasm right now. There's the intro guides and then there's professional life and trying to bridge the gap between those is ridiculously a challenge right now due to the huge ramp up of complexity from like, "Let's do some stuff in the console," to, "Running transpile JSX code with async [inaudible]. We've got regenerator in there to polyfill generator functions." There's so much in your average JavaScript at these days. CHARLES: Your work that you're doing at LinkedIn, part of it is trying to bring and train developers who come from more nontraditional backgrounds, including a lot of things like boot camps. What is your experience of their experience coming in? Are boot camps doing the right thing? Are they teaching the right things? Are they trying to kind of parachute them on top of that mountain? Or do you find that they're just at the base camp, so to speak? Because it sounds like your approach is like you've got to really start from fundamentals so that you can understand the layers of complexity if you're going to, someday stand on them. MIKE: I think a lot of the boot camps are doing an excellent job. These days, the employees we have at LinkedIn who come from boot camps, I would bet on them against your average MIT grad every time, just because their education is so practical. It's amazing that in the world of computer science, the stuff that you're taught in school is a little bit farther removed than one would expect, compared to the stuff that we do every day in our jobs -- building real apps. I do not need to know in my day-to-day work at LinkedIn how an operating system works or how to build a device driver. This is a little bit too fundamental. It's the wrong abstraction for practical everyday work for most people. Where in these boot camps, they focus completely on the practical. In fact, I've been fortunate enough to get involved with the REACH program here at LinkedIn, where we hire explicitly people from nontraditional backgrounds like boot camps. They're not all from boot camps but many of them are. We just hired 30 of them in March. The pilot program, I think we've hired two or three in our New York office and it just went really well. It started like, "Let's double down and double down again and double that again." This time, we're doing 30 and I expect there will be a new round next year where we poll even more. The idea is we take these REACH candidates and pair them with a mentor engineer for six months. At the end of that six months, we had to make a decision as to like this person at the level we expect of an entry level software engineering hire. From what I've seen, we're doing really well at preparing these folks and they're unbelievably valuable to the teams that they've been placed in. ELRICK: That's amazing. That's very interesting. Is there a standardized curriculum thing that each mentor will follow to get this person after they entered his REACH program and then ramp them up or is it like each person just goes and looks at what the person knows and then ramps them up accordingly. MIKE: I'd say, it's a mix of both. We have a set of technical trainings for them or we'll have a testing expert from within the company and teach a little testing seminar to them. There's that standardized curriculum there. But the nature of being taught by boot camp or teaching yourself is that you're going to have holes in your knowledge and it's not often predictable where those holes will be. That's why we make sure we do this mentorship very explicitly and over a long period of time so that if it turns out that you never learned about how to work with tree-data structures. That was not part of the go-no/go decision that brought you on but we should probably, at least get you there. At least to the point where if you're traversing a down tree and you're like parent and child, what is this, what do you mean by leaf-level node. This is stuff that is actually meaningful for web developer in some cases. CHARLES: In the context of the work that you're doing with the REACH program but also touching on something that we talked about at the beginning about the first gear and the fifth gear, part of generating a curriculum is still being in contact with what's up in the fifth gear right because ultimately, what you're trying to do is you're working with people who are in first gear or looking to get a smooth transition in the first gear but at the same time, you want to set them up and you want to be in contact for what's in fifth gear now is going to be first gear in five years. How do you feed that in? MIKE: I'm fortunate to have a great team that I work with here. This group that I roll up to in LinkedIn, they're experts and you probably know of like Chris Epstein and Tom Dale and Steph Petter. A 15-minute coffee break with one of these people is enough to keep [inaudible]. Sometimes, it's a little bit like drinking from a fire hose because it's like I spend an hour with a student trying to help them understand like, "This is why a Promise is useful. Here is the callback equivalent," and then now, "Let's dive in to Glimmer. Why this track annotation is the right way to go for automatic updating." It sends me for little bit of a loop sometimes but it is definitely keeping me up to date. The other factor, of course is when you've been doing this for a while. History sort of repeats itself so a lot of the patterns that we're seeing today, I've seen somewhere else. I was working with code splitting when I was writing Dojo JavaScript code years and years ago. I was defining my module layers in a very explicit way. I had to do that. I didn't have done a webpack that would figure out, put these splits are. But I have that experience to look back to and for that reason, it is not often that an entirely new concept comes along. Oftentimes, they're like amazing refinements on things that how to smell like stuff that we've used before in the software engineering world. CHARLES: Yeah or here's something that has never been used, is very prevalent in these other context which we're going to apply here. MIKE: Exactly. CHARLES: And like, "Oh, my goodness. It's a perfect solution." In addition to the work that you're doing with LinkedIn and developing those training curricula and stuff, you're also doing some work for Frontend Masters in an area that's very exciting, I think to me. I'm sure it's exciting to you because you decided to throw a whole lot of time into developing a course for it. That's in the development of progressive web apps, which for me has been like this thing that I'm so curious about but I'm like a kitten playing with a little yarn ball. I want to dive in but I'm just going to tap it with my paws right now. MIKE: Yeah, it's a really interesting area and I think that even if you're not using progressive web technologies today, it's one of these things that sort of reinvigorates your energy for JavaScript's future and what may be possible soon. Steve and I have put together this amazing progressive web app course, which has I think like 18 short examples of iteratively building up a grocery shopping app. If you've used InstaCard or something like that, we start out with app already built and it's like a single-page app as doing everything that you would expect. After a few of the exercises, it works offline. After a few more, you can add stuff to the card and background sync, push it to the API when you come back online. We get deep, deep, deep into service workers. That's one of the areas that my work at LinkedIn and my teaching with Frontend Masters overlaps really well because I've been heavily involved in creating our service worker for LinkedIn.com. I may be able to take some of what we've learned here and disseminate it a little bit so that, hopefully fewer people have to learn the hard way. It's best to keep things simple at first and add on functionality. I'm about to cross like the [inaudible]. This is my favorite just because the example turned out to fit so well and in particular, on Frontend Masters, I think Steve and I have had contrasting teaching styles but they complement each other so well because I'm like the 'melt people's brains' instructor. I love to throw people exercises that are like 120% of what they can do and it's going to hurt, just like when you're lifting weights at the gym, like you're going to beg for mercy but we're going to make you strong. Then Steve, just listening to him, even with I am in the classroom and he is teaching me Electron. He's so energizing and he's really funny too but not in an overtly cracking jokes kind of way. He's just so fun when he teaches. I think it is a really good combination just because things lined up just by luck and through hard work and just the right way out of a couple of important areas. CHARLES: Now, just for people who might not be familiar with the term progressive web apps, what does it encompass? Do people actually call them PWAs? MIKE: No. I'm going to start, though. I like that. That carries very well over a video chat or something. Nobody knows how to spell that: P-U-A? P-W-U-A? It is a rejection of the old idea that in order to take advantage of some web technology, it has to be supported in all of the browsers that we need to support. The idea here is to hold as a core tenet of our design practices, the idea of progressive enhancement, meaning we serve up a basic experience and where we can take on these superhero features, like the ability to work offline, the ability to receive push notifications, we go ahead and do so. If your browser doesn't support this, that's unfortunate. No big deal. You still get a good experience. But if you're using a very recent version of Chrome or Safari or you have a new Android device, these browsers can take advantage of sophisticated metadata or sped up a background process that can serve up data to your app and your app doesn't even know that there's something between it and the API. That is the idea of progressive web apps -- apps that become superheroes where possible and they still work and provide a great basic experience for antiquated browsers like IE8 and Safari. CHARLES: The idea theoretically, you could work without any JavaScript or whatsoever. What's the ground floor there? MIKE: That is ideal. I think server-side rendering, which is what you're talking about there, even if JavaScript is not working, just HTML and CSS will provide a basic experience. That's great but that's not a modern browser technology thing. If you have JavaScript turned off in today's Chrome, like Chrome 60, versus IE9, both of them working with them without JavaScript. What we're really talking about here is app-like characteristics, where we are pushing web technology to the point where you will swear that this came from an App Store. It's on your home screen. It's running in the full screen. You're getting push notifications. It works offline and you can store a large amount of structured data locally on the device. All of the stuff sounds like the list of reasons to reach for native mobile technology because the mobile web is not good enough. But in fact, it has a feature set of this family of progressive web technologies. It's really like a web app that is so good and so modern that it feels and looks just like a native mobile app. CHARLES: That sounds so hard to do right. MIKE: Well, it is now, just because what we have to work with can be thought of it like a basket of ingredients, rather than a solution that we drop in. But over time, as more people start working with these ingredients, I think we're going to see a lot of consensus around the best patterns to use and boilerplate code will fall away as we can identify that the set is in fact commonly needed and not a beautiful and unique snowflake. CHARLES: Because it seems like the thing that I always struggle with is not wanting to put the critical eggs in the basket of a superhero feature or have you being able to provide an alternative if the superhero feature doesn't exist. Some features, if you just don't have it, that's fine. You can turn it on if the capabilities available but certain features are very critical to the functioning of your application. I'm casting about for an example and I'm not finding one immediately but -- MIKE: Offline is a great one. That fits pretty neatly. If you're using an older browser or if you're using Safari, which by the way, I should stop ripping on Safari. For the listeners out there, we saw a commit lend in webkit, where service for APIs are beginning to be stubbed out. No longer do we have to look at length. Service worker, enthusiasm and Safari has got it in the five-year plan. There was motion last week. We haven't seen motion in ages so thank you Safari Team. Thank you. Keep up the good work. CHARLES: Is there a discipline of Safari-ologists who monitor the movement of Safari to bring this news? MIKE: Of course, we monitor it because right now, Chrome and Firefox, they are pretty much hopeful in terms of supporting this modern stuff. Opera supports this modern stuff. Samsung's fork of Chromes support this modern stuff. Especially when we think about the mobile web, you got to worry about Android and you got to worry about iOS Safari and right now, like we've talked about these progressive web apps, you don't get that superhero experience on an iPhone or an iPad. Once we crossed that threshold, this is going to have a breakaway level of adoption because there are no more excuses. Essentially, for a mobile web experience, you can send push notifications to the user. That is huge. That is probably at the top of the list for why some people use native apps, instead of mobile web. The more we can do that, the more we can make it so that a great LinkedIn experience can be delivered to your phone without having to install a binary. I just have to update Facebook the other day and it was over 100 megabytes. Why do we need to do that? You should be able to make it work with less. I'm sure that there's some great stuff in there. Apparently, Snapchat filters are popular but I don't need this. Can we code split that away or something because I don't want to have to download that? I can't even download it on the cell network because it's over 100 megabytes. It's really exciting to see the web start to compete with this heavy mobile experience because now I think is ready. CHARLES: Now, when you talk about push notifications, you're talking about being able to send things to my lock screen. MIKE: To your lock screen while the browser is not on the foreground, while the app is not open. Essentially, you're installing a lightweight process that runs in the background. It receives events that originate from your server and the user can tap on them and then your little lightweight worker process in the background decides what to do when that tap happens, like open up the app, take them to this URL or something like that. That is a game changer. That's huge. Or background sync like the user added some items to their cart and then they lock their phone and now, their plane has landed. That's why they were offline and they get back on the internet and without them having to touch their phone, now we can push that data to the server and everything's in sync, rather than like, "Please revisit your app. We need to run some JavaScript code to flush IndexedDB or API." It still feels like a hack at that point. This is a fluid experience. ELRICK: Wow. This is exciting for me as I don't have any more space on my cellphone, thanks to all the apps that I have to install to do various things on the web. MIKE: You're not alone. CHARLES: Yeah, it's crazy and just the amount of code sharing that you can have, I guess that doesn't happen much these days on the web where you've got these popular libraries out on CDNs so that the chances are that you've got jQuery 1.2.1 on your cache, you've got 16 versions of jQuery so most of your web applications don't have to do that. I guess we kind of do the equivalent of statically linking everything. MIKE: There is a benefit near that where we have imperative code managing our cache, instead of just relying on the HTTP cache or app cache, if you have a vendor.js file that is not changing over six months, there is no reason you should be re-downloading that every time you deploy your app or letting the browser evict that, just because memory pressure is high from Google image search results or something like that. We really don't have much control over it. But with a service worker, we can say, "Hold on to this," or maybe like prefetch the next version of the app so that we're going to show you the old version now but the next time you refresh, here's the new version available instantly. It's downloaded in the background and it's like click to update your version, like it's already here waiting for you. That's huge. That's amazing. CHARLES: That is amazing. Although the complexity skeptic in me is thinking, "Oh, my goodness. Now, we've got all this state that we're storing on the server. We have to have data migrations." We need some sort of migration mechanism for our clients-side state and perhaps some transaction and rollback in case you're not able to successfully migrate your data. It sounds like a lot of fun but I'm just imagining we really are getting started here. Has there been any work on that aspect? MIKE: If you've ever worked with IndexedDB, it does have a concept of migrations. Basically, the data you store on a device has a version and when you read in what's called a file but it's a database, when you read that in, the first thing you do is you basically bring it up to date incrementally. You'll bring it in, you're looking for version nine like your code wants version nine. What you see is version two because your user hasn't been at your site for six months and you're going to take it from two to three to four to five to six. Each of those, essentially constitutes a migration. We just have to apply the same principles of forward-compatible changes. The escape hatch here is remember it's progressive enhancement so if we had to destroy everything, fall back to a basic experience and start from scratch, like discard all of our data, it's really being held there as an optimization. Some people use this immutable caching strategy or basically, like rolling out a new service worker version constitutes for the most part. Any data that wasn't created by a user you're going to discard that and you're going to fetch it new. You don't have to worry about like, "Crap. This six month-old thing is still plaguing half our users and we can't get rid of it," like you can have [inaudible]. But you should really check out this course. It is simpler than you think and what we demonstrate is not a trivial like hello service worker. It is taking in a classic single page app, making it completely offline, having it exist on the home screen and I think the service worker ends up being no more than 100 lines of code. It's not too bad. ELRICK: I'm definitely going to check that out because my progressive web app journey is still on just service workers. MIKE: That's very [inaudible], though. ELRICK: Yeah. I'm definitely checking it out. Sounds like a really fantastic course. MIKE: I've been focusing a lot on this area and another one is security. The reason I picked these two is because developers are not really going to learn about these on the critical path to [inaudible] plus they learn about them the wrong way. As the JavaScript world is becoming radically more complex with each passing year, I've tried to target some of my efforts towards areas where they are not getting as much attention as I'd like to see, just because we have to focus somewhere. Obviously, getting the app out and figuring out how to make the build tools work for us. Without that, we can't do anything at all. One of the courses that's coming in September for Frontend Masters is a one-day web security workshop or we'll do with like cross-site scripting, how to work with certificates because if you start playing with HTTP/2 -- the next generation of HTTP -- you will need to generate some certificates for development at least today you need to. I've seen some amazingly smart developers get this dangerously wrong to the point where they compromise their own machine and anything that's on that machine, just by trying to set up dev environment. Typically, I'm an optimist but when it comes to this PWA stuff and security, I am paranoid. I feel like, we as a community need to get together and have the discipline to brush up in these areas so that as we introduce all of this new stuff, we don't end up opening a bunch of holes. Nowhere near the same rigor as put into frontend compared to backend and now, the line is blurred. Right now, we're server-side rendering so our code is running on the backend somewhere so injecting something can really mess things up in a bigger way. ELRICK: Yeah, I think that's a fundamental characteristic of someone does going to be involved in security paranoia. You have to be paranoid about everything. MIKE: Yep. I don't trust anything. CHARLES: It's important to make those things easy because I'm definitely fall more into the hippie camp like, "Everything is going to be fine. Let's trust everybody," which is I know is totally unrealistic. But then you get into these secure technologies and you learned enough of it just to get the task that you're going to do and then you forget. SSL is a great example. Over the course of my career, I've learned how SSL certs have worked probably, at least 10 times. ELRICK: Right, [inaudible] you had to set it up in production. CHARLES: Yes, exactly and then I promptly forget about it, never worry about it again and then the next time I'm like, "How did that work? What's this trust chain? What?" ELRICK: Exactly. I read a study from Carnegie Mellon a couple of years ago that showed developers observe security best practices dramatically less than the general public and the general public is not good. Do you know what I'm talking about when I say a certificate warning and a browser, there's big scary red screen saying like something is wrong here? Before the Chrome team put some effort into improving that, 70% of people would click through those and proceed anyway. After their improvements, over a third of people still clicked through and that number when you just look at Canary versions of browsers, that number is actually considerably higher close to 50% of our developers. We're trained by every broken certificate system that exists on the internet like the legitimate ones or maybe some things just expired. They're training people to just click straight through these things and as a result, it is terrifyingly easy to mess with people. We have to remember as developers, our machines, those have the private deploy keys and those have the SSH keys to commit code to GitHub, we have to treat that like it's a private data. It's really, really important that we make it easy and that we make sure that that easy path is also very safe. CHARLES: Absolutely. All right. Well, thank you so much Mike for coming by and talking with us. We touched on a lot of subjects but I feel like I certainly learned a lot. MIKE: Yeah, thanks. It's been so much fun talking with you this morning. CHARLES: Anybody who wants to go and check out those courses, they're on Frontend Masters. Now correct me if I'm wrong, you've obviously got the one on progressive web apps or PWAs. If it doesn't work offline, it's faux-PWA. MIKE: Yes, I like that. That's going to become a t-shirt sometime soon. CHARLES: The fundamentals of progressive web app development, which is now released if I understand correctly. MIKE: Members have access to everything, you can watch the raw video now. The edited course will be available later this year. CHARLES: Okay, and that's with Steve Kenny. I am very much looking forward to looking at that and learning more about it. Then you've also got ones coming up in September on TypeScript web security in Visual Studio Code. MIKE: Yep and members can watch that as a live-streamed event. Frontend Masters even ask people to watch the comment stream so you'll have a proxy question asker or hand raiser in the room. It's really a great experience to be part of a live thing. CHARLES: Oh, man. That sounds awesome. Then if you are obviously doing your independent consulting and if people want to get in contact, how would they do that? MIKE: You can find me on Twitter, @MichaelLNorth or you can visit my website, Mike.Works and I have all of the courses I teach and outlines and I can just open up a little chat bubble on the lower right, ask me any questions that you have. I am really passionate about teaching people. If you like that's useful for your team, please reach out and I'd love to talk. CHARLES: Fantastic. Thanks, Mike and thanks everybody for listening to us. If you want to get in touch with us, you can always do that. We're on Twitter at @TheFrontside and email, Contact@Frontside.io. Thanks, Mike. Thanks, Elrick and I will see you all later. MIKE: Thank you so much. ELRICK: Bye.

Nolan Lawson a PM at Microsoft Edge joins us today to talk about PouchDB a popular open source project he's a maintainer of. PouchDB is an open-source JavaScript database inspired by Apache CouchDB that is designed to run well within the browser. In this episode we get into what PouchDB is good at and what type of projects would benefit from using PouchDB for their persistence layer (turns out, many!). PouchDB is framework agnostic but plays very well with many popular frameworks and libraries. Nolan gets into the performance of PouchDB and also what storage mechanisms it supports which include IndexedDB, WebSQL, LevelDB and many more. The episode takes a very unexpected turn leaving Justin, Danny and Leon wrapping up with some of their own PouchDB experiences. Resources https://pouchdb.com nolan lawson blog The cost of small modules IndexedDB, WebSQL, LocalStorage – what blocks the DOM? PouchDB custom builds PouchDB: a better build system with Rollup PouchDB map/reduce pouchdb-find PouchDB replication Around the Web in Two Minutes Friday 10th March - Password Rules are BS Co-founder of Stack Overflow Jeff Atwood publishes an article raging about how stupid password rules are. Very insightful article TLDR; Just use a long password, it's totally fine to use memorable words as long as it's long enough https://blog.codinghorror.com/password-rules-are-bullshit/ Wednesday 15th March - Chrome 57 throttles background tabs to increase battery life http://www.theverge.com/2017/3/15/14932718/google-chrome-browser-battery-life-tab-throttling Tuesday 21st March - Mozilla Proposes “Obsidian” Web Graphics API Obsidian is a low-level API intended to provide a maximum feature set of the GPU to web applications. Similar to Vulkan, it's designed for WebAssembly, modern GPUs, and a multi-threaded environment. https://www.gamedev.net/news/index.html/_/programming/mozilla-proposes-obsidian-web-graphics-api-r62 Tuesday 21st March - Android O Announced Multi-process mode for WebView is enabled by default and API to let your app handle errors and crashes https://android-developers.googleblog.com/2017/03/first-preview-of-android-o.html The “Option to mark an event listener to fire only once” feature is now under development in Microsoft Edge https://developer.microsoft.com/en-us/microsoft-edge/platform/status/eventlisteneronceoption/?q=event%20listener Guests Nolan Lawson (@nolanlawson) Panel Danny Blue (@dee_bloo) Leon Revill (@RevillWeb) Justin Ribeiro (@justinribeiro)    

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby String#concat, Array#concat and String#prepend take multiple arguments in Ruby 2.4, Do I really need to patch my Rails apps? (Understanding CVE-2016-6316) и Is Your Site Leaking Password Reset Links? Monitoring Sidekiq Using AWS Lambda and Slack, A Photo Gallery that Automatically Tags Your Images и Validation outside ActiveModel HexaPDF Code and First Version Released, Helpy is 1.0!, TZOffset - simple abstraction of a timezone offset и Screencast: Debugging With Byebug JavaScript Node v7.0.0, What's new in IndexedDB 2.0?, Vue.js is easier to learn than jQuery и Rising Trends in In JavaScript: A Comprehensive Guide to Libraries & Frameworks Redux without React — State Management in Vanilla JavaScript, Redux is Overhyped и OverReact - React for Dart Next.js – small framework for server-rendered universal JavaScript apps, MathJax - beautiful math in all browsers, Swip - a library to create multi device experiments, Shave - a javascript plugin that truncates multi-line text to fit within an html element based on a set max-height и JS Ipsum - generate your own JS gibberish

Offline access for applications is becoming more and more necessary for web development today due to increasing client usability demands. The HTML AppCache are a partial solution but is very sticky, often provides stale data and is not dynamic or adaptable. Developers can easily find themselves doing hacks with the deprecated Web SQL API, IndexedDB, & localStorage or a framework like Hood.ie to achieve a fully supported offline application.   Jake Archibald (@jaffathecake), Google software engineer, wrote an infamous article on A List Apart about the inadequacies of AppCache. This turned into the beginnings of ServiceWorker, an API for offline access that provides “scriptable primitives that make it possible for application developers to build URL-friendly, always-available applications in a sane and layered way.” ServiceWorkers allow developers to to make sites work faster and/or offline and also use network intercepting as a basis for other 'background' features such as push messaging and background sync Jake, along with Google Engineer, Alex Russell (@slightlylate) & Mozilla engineers Anne Van Kesteren (@annevk) & Ben Kelly (@wanderview) talk about ServiceWorker's current state and how we will use it in our applications. Resources The spec - https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html How to build with ServiceWorkers - https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md The Offline Cookbook - http://jakearchibald.com/2014/offline-cookbook/ ServiceWorker Cache Polyfill - https://github.com/coonsta/cache-polyfill ServiceWorker Github - https://github.com/slightlyoff/ServiceWorker The article that started it all - http://alistapart.com/article/application-cache-is-a-douchebag Offline First Organization - http://offlinefirst.org/ Potential Resource Implications -  https://hacks.mozilla.org/2014/12/mozilla-and-web-components/   Understanding ServiceWorker Cache in Firefox - http://blog.wanderview.com/blog/2014/12/08/implementing-the-serviceworker-cache-api-in-gecko/ Intro to Service Worker - http://www.html5rocks.com/en/tutorials/service-worker/introduction/ Using Service Workers - https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers Web Spec Framework - https://github.com/slightlyoff/web-spec-framework Brendan Eich Quote - https://annevankesteren.nl/2014/09/tc39-api-design The early state of ServiceWorker - http://devchat.tv/js-jabber/069-jsj-the-application-cache-with-jake-archibald Support in browsers - https://jakearchibald.github.io/isserviceworkerready/

n this session, you learn more about the new standard features available in Internet Explorer 10, including grid layout, IndexedDB, and AppCache. We'll use simple code examples to see these features in action in real-world websites and apps!

Zu Gast war diese Woche Anselm Hannemann, den wir mit seinem Fachwissen gerne wieder eingeladen haben. Außerdem waren der Schepp und Hans mit von der Partie. Schaunotizen [00:00:00] Quota Management API Wenn man mit client-seitigem Speicher experimentiert (localStorage, IndexedDB, File API) ist es schwierig abzuschätzen, wann der Speicher eines Geräts erschöpft ist. Dafür gibt es […]

Ubuntu device drivers, XP installation disk image, VoIP (Vonage, Ooma, Skype), Profiles in IT (Garrett Camp, co-founder and CEO StumbleUpon), Android developer out to kill iPhone, IndexedDB will be local storage cloud computing standard, looking back at 1995 Internet pridictions (misguided and humorous), Google to leave China rather than comply with government demands, and technology to help blind soldier see (signal sent to imager for the tongue, initial trials promising). This show originally aired on Saturday, March 20, 2010, at 9:00 AM EST on WFED (1500 AM).

Ubuntu device drivers, XP installation disk image, VoIP (Vonage, Ooma, Skype), Profiles in IT (Garrett Camp, co-founder and CEO StumbleUpon), Android developer out to kill iPhone, IndexedDB will be local storage cloud computing standard, looking back at 1995 Internet pridictions (misguided and humorous), Google to leave China rather than comply with government demands, and technology to help blind soldier see (signal sent to imager for the tongue, initial trials promising). This show originally aired on Saturday, March 20, 2010, at 9:00 AM EST on WFED (1500 AM).