Podcasts about preact

JavaScript is missing a built-in way to make variables reactive—but Signals might change that. Scott and Wes break down what Signals are, how they compare to React state, and how different frameworks like Preact, Solid, Vue, and Qwik are already using them. Show Notes 00:00 Welcome to Syntax! 01:49 Brought to you by Sentry.io. 02:28 Why JavaScript needs reactive variables. 03:16 What exactly are signals? Signals Proposal. 04:02 Understanding computed state. 04:59 How signals differ from React state. 06:12 How different frameworks handle reactivity. 07:09 DOM Parts. Pull Request. 07:26 HTML Template Instantiation. Template Instantiation. 09:10 Comparing signals across frameworks: Preact, Solid.js, Vue, and more. PreactJS Signals. 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

Anthony Alaribe, co-founder of API Toolkit, discusses the power of the browser for building data-heavy applications. He talks about myths around single-page apps versus multi-page apps, leveraging tools like HTMX and Workbox, and the significance of browser-native features for interactive web development. Links https://htmx.org https://tonyalaribe.medium.com https://x.com/tonialaribe https://github.com/tonyalaribe https://www.linkedin.com/in/anthony-alaribe-293a41bb 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: Anthony Alaribe.

This is the second part of our discussion with Dr. Anna Kavoura on how gender informs meaning in sport. In the first part, we explored Anna's work on intersecting identities in women's martial arts, as well as her current research project titled "Transforming Gender Boundaries in Sport: An Ethnographic and Participatory Action Research Study in Trans-Inclusive Sport Contexts”. This episode continues our discussion exploring the dominant gender discourses in sports context and what can be done to challenge them. We also discuss the dilemma of women-only training groups in martial arts. While these groups can be useful for attracting more women to male-dominated martial arts gyms, there are some possible problems with them such as reinforcing the gender binary and hierarchical understandings of gender. What are the ways we can use this strategy well?    Dr. Anna Kavoura has completed several interesting research projects on gender in sports. She completed her PhD in Sport Sciences at the Univerity of Jyväskylä in Finland, which focused on understanding women's identity negotiations in competitive judo cultures in Greece and Finland. After defending her PhD, she continued working as a postdoctoral researcher at the University of Jyväskylä in the PREACT project which focuses on tackling discrimination against gender and sexual minorities in sport and physical education contexts (PI: Dr Marja Kokkonen). She then moved to the School of Sport and Service Management at the University of Brighton and works as a postdoctoral researcher in the "Transforming Gender Boundaries in Sport" project which is funded by the Finnish Cultural Foundation.

Knappe News in dieser Woche:Googles Chat-API Bard hat ein Update bekommen und kann nun besser rechnen.Million.js macht React-Anwendungen schneller.OpenAI bringt Updates zur API und GPT-Modellen.Google möchte, dass seine Mitarbeiter:innen wieder 3 von 5 Tagen vor Ort sind. Sonst kriegen sie eine schlechte Bewertung.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTube

LiDARs are an important piece of the autonomous driving and ADAS puzzle. While they boast impressive resolution and frame rates, they have also built a reputation for being big, bulky and expensive. Can there be another way?Paul Drysch, CEO of PreAct Technologies certainly thinks so. PreAct has been working behind the scenes for a number of years to develop their short-range LiDAR which aims to deliver all the functionality of a LiDAR at short distances while addressing the biggest drawback of the technology - its cost. Their software-definable LiDAR is to the world of LiDARs what the software-defined vehicle is to traditional cars.Join Paul and me on this episode of the AI in Automotive Podcast as Paul gives us a crash course on LiDARs, their types and flavours. We also talk about what the sensor suite in future cars might look like, and where PreAct's low-cost, short-range LiDAR fits in. Paul believes LiDARs' time in automotive is yet to come. I am so excited about how technologies like PreAct's can expand LiDARS' use cases, and accelerate their mainstream adoption.https://www.ai-in-automotive.com/aiia/302/pauldryschAI in Automotive Podcast

A “Meet The Team” FFP interview with Stellate Staff Software Engineer Jovi De Croock. Jovi is a software engineer who's very passionate about open-source, performance and developer-experience. He is part of the Preact and urql core teams. In his spare time he enjoys spending time with friends and running. Hear Jovi's perspective on: Origins Software Love Joining Stellate Consultancy Years Formidable Labs Ownership Open Source DNA Company Building Default To Open Favourite Job Supportive Culture Joining Startups Avoiding Red Flags Values Checking Culture Addition Decompressing Self Advice Context Is Key Open Source Funding Collaboration vs Focus Belgium Working Hard Getting Into Open Source Studying Psychology Books GraphQL Ecosystem Communication Skills Junior Dev Tips Problem Solving GraphQL's Future Personal Routine Website: https://www.jovidecroock.com/ GitHub: https://github.com/JoviDeCroock Twitter: https://twitter.com/JoviDeC LinkedIn: https://www.linkedin.com/in/jovidecroock?originalSubdomain=be We are currently hiring at Stellate. If you got interested in potentially working with us, please take a look at our hiring page.

What are signals? What is find-grained reactivity? Why is everyone talking about them on the frontend these days? And what, if anything, can we apply from our newfound knowledge of signals to backend programming? Is it possible to use signals in Ruby? (Yes!) Learn all about signals, the Preact Signals library, and the new Signalize gem right here in the latest episode of Fullstack Ruby.Links:Episode 4: Design Patterns on the Frontend, History of MVVM, Web Components, and Youpreactjs/signals: Manage state with style in every frameworkwhitefusionhq/signalize: A Ruby port of Signals, providing reactive variables, derived computed state, side effect callbacks, and batched updates.Become a part of the Fullstack Ruby community and learn how to put your Ruby skills to work on the backend AND the frontend. Know somebody who's a JavaScript developer but is interested in learning more about Ruby? Share the site, podcast, or newsletter with them!Theme music courtesy of Epidemic Sound.

This week we read Introducing Signals from the folks at Preact. We discuss whether or not the world needs another state management library when it already has a million libraries such as recoil, zustand, and zingaling. We learn a bit about Panda Planners and Supabase and take you on the Good News Cruise as always! Here are the Signals docs: https://preactjs.com/guide/v10/signals/ Here's the Hacker News discussion: https://news.ycombinator.com/item?id=32743078 If you're interested in seeing where they update React.createElement, here's the source for that! Music by Hina and Kevin MacLeod

The beauty of tech is that it keeps evolving. As a developer, it's important to keep evolving too. Whether that's trying new frameworks, starting side projects, or adopting emerging tech. JavaScript, for example, has taken on a whole new purpose since it was developed in the 90s to support a web browser. The language keeps developers like Robbie intrigued with features that seem underpromoted and underused by the community. At ShipShape, Chuck and Robbie are always experimenting. They're embracing Astro with plans to transition their website from Nuxt, developing a scheduling app, and most importantly they just launched the Whiskey Web and Whatnot NFT. In this episode, Chuck and Robbie talk about underrated JavaScript features, where to find the Whiskey Web and Whatnot NFT, and why Robbie can't decide on a new car. Key Takeaways [01:22] - Chuck and Robbie introduce their NFT. [04:11] - A whiskey review - Starlight Distillery Single Barrel Hubbard's Original Rick House of Indiana Straight Rye Whiskey. [09:35] - The difference between Maps and Sets in JavaScript. [22:52] - Chuck and Robbie discuss a scheduling app they're developing. [36:10] - Chuck and Robbie critique Solid, Astro, and React. [44:02] - Robbie whatnots about Ciroc Vodka. [45:13] - Chuck and Robbie discuss streaming services, TV shows, and Ryan Reynolds. [52:45] - What Robbie thinks about different trucks. Quotes [22:58] - “Internally, we're known for some technologies, but we're always experimenting with different things coming up as much as we can.” ~ Chuck Carpenter [39:42] - “So the cool thing about Astro is they have support for a lot of different types of frameworks like Vue, Preact, React, and Svelte. If it's a hot thing that someone has mentioned recently, they've got it.” ~ Robbie Wagner [41:44] - “I think for people that like React and want something that's not React just because React is super old, you could try Solid out.” ~ Robbie Wagner Links Bitski.com/Shipshapecode Huber's Starlight Distillery Old Rickhouse Indiana Straight Rye Whiskey Seelbach Sagamore Rye JavaScript Oracle Gerber Hoover Mad Men Ember The Doors React Vue 3 Nuxt Expo iOS Jest Cypress Playwright Ember Hacktoberfest Dependabot Digital Ocean Chris Coyier CSS-Tricks CodePen Astro Solid Twitter Lit JSX Preact Svelte Absolute Vodka Ciroc Diddy Stoli Ryan Renolds Welcome to Wrexham FX Hulu Disney Plus Roku iPad HBO Max Netflix Tik Tok Aviation Gin Mint Moblie Ashton Kutcher Verizon Deadpool Rob Macklehaney It's Always Sunny  Green Lantern Detective Pikachu Free Guy The Old Man Jeff Bridges Jeep Broncos Hummer Silverado Chevy F150 Lightning Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io.

Paul Drysch, CEO Of PreAct Technologies joins me on the show this week to discuss ADAS technologies on vehicles today and in the future. We chat about the sensors involved, limitations to autonomous vehicles, and the software-definable vehicle. Website- https://autodiagpodcast.comFacebook Group- https://www.facebook.com/groups/223994012068320Email- http://STmobilediag@gmail.com

Learn what the Astra Framework is and how to run Astro and create your first Astro blog website. # What is Astro and How to use it Your assignment, build a Blog website, ok , let me do a `npx create-react-app my-blog` and do a total overkill of your assignment. Or just use Astro, with is similar to a static site generator and make you life much easear. ## What is Astro? Astro is an all-in-one web framework for building fast, content-focused websites. For example Blogs, Landing pages ,Portfolio, Showcase, etc... ## Key Features: Some of the Key Features of the Astro framework are : - **Component Islands**: A new web architecture for building faster websites, that considers your website as the ocean and the components as islands. - **Server-first API design**: opposite to next.js, expensive hydration is removed of your users' devices increasing site speed. - **Zero JS, by default**: No JavaScript runtime overhead to slow you down. JavaScript is loaded only when required. - **Edge-ready**: can run on global edge runtime like Deno or Cloudflare. - **Customizable**: Tailwind, MDX, and 100+ other integrations to choose from. - **UI-agnostic**: Supports React, Preact, Svelte, Vue, Solid, Lit and more as integrable components. There main selling point is that you ship les JavaScript!

Astro ist der neue Stern am Web-Framework-Himmel. Gerade erst in Version 1.0 erschienen und wir haben direkt einen der Contributer, Chris Swithinbank, an Bord. Chris spricht in Bezug auf Astro von einem Meta-Framework, da es mit vielen bestehenden Frameworks wie React oder Vue umgehen kann und diese intergriert – optional. Mit Astro lassen sich statisch generierte Webseiten bauen, die mit minimalem JavaScript auskommen und dadurch schneller bei den User:innen ankommen. Astro nutzt Vite als Module Bundler und bringt einige Besonderheiten mit, wie beispielweise die Möglichkeit, mit Markdown komplette Seiteninhalte zu definieren.Kommt mit uns auf die Reise ins All und erfahrt von Chris, welche weiteren Besonderheiten es gibt und warum Astro für viele Webseiten-Projekte die richtige Wahl auf der Suche nach der Technologie-Lösung sein kann.Das Podcast-Cover dieser Folge stammt von der künstlichen Intelligenz DALL-E. Unser Input lautete: "A software developer wearing a spacesuit riding a rocket ship programming a game, planet earth in the background, photorealistic".Picks of the Day: Fabi: Spotify: A Product Story – Im Spotify Original Podcast geht es um Spotify selbst und was für interessante Ansätze genutzt wurden, um Spotify zum Audio-Streaming-Portal Nummer 1 zu machen. Dennis: Astro Getting Started Page – Mit diesem Link kann man in Sekunden ein laufendes Astro-Projekt im Web auf die Beine stellen und es als Playground nutzen. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. TwitterInstagramFacebookMeetupYouTubeMusik: Hanimo

In part 1 of our talk with Tag1 Consulting's VP of Software Engineering Fabian Franz, he and Managing Director Michael Meyers discussed the increasing complexity of software and website development. In this second part, Fabian demonstrates how to reduce some of that complexity using Preact and HTM. Using a standard Drupal 9 Umami installation, Fabian shows how these packages can make it faster and easier for developers to make changes, without using JavaScript. He'll explain why he chooses Preact and HTM, along with Tailwind, and how they're faster for his purposes than other systems.

Greater Than Code Episode #170: The Case for Vanilla JavaScript with Chris Ferdinandi (https://www.greaterthancode.com/the-case-for-vanilla-javascript) 02:50 - Project Gemini (https://gemini.circumlunar.space/) and Text Protocols * Always Bet on JavaScript 07:05 - Overusing Analytics & Tracking Scripts * Be An Advocate For Your Users / Ethical Obligations 12:18 - Innovations: Making Accessibility The Default 14:48 - Ad-Tech and Tooling * Partytown (https://partytown.builder.io/) * Fathom (https://usefathom.com/pjrvs) * Preact (https://preactjs.com/) * Alpine.js (https://github.com/alpinejs/alpine) * petite-vue (https://github.com/vuejs/petite-vue) * Svelte (https://svelte.dev/) * SvelteKit (https://kit.svelte.dev/) * Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes (https://www.youtube.com/watch?v=860d8usGC0o) * Astro (https://astro.build/) 32:08 - HTMX (https://htmx.org/) 46:30 - Frontend Development is Hard * SPA's and Transitional Apps * Federated Multipage Apps * Micro Frontends * Phoenix LiveView (https://github.com/phoenixframework/phoenix_live_view) * Joint Activity * Joint Cognitive Systems: Foundations of Cognitive Systems Engineering (https://www.amazon.com/Joint-Cognitive-Systems-Foundations-Engineering/dp/0849328217) Reflections: Rein: Vanilla JavaScript + Privacy. Jacob: The web piqued at LiveJournal. Also, encouraging devs to think about what tool would be best for different jobs. Chris: Maintaining privacy on the web. Sign up for Chris's newsletter at gomakethings.com (https://gomakethings.com/)! This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Coming ASAP! Special Guest: Chris Ferdinandi.

[קישור לקובץ mp3] שלום וברוכים הבאים לפודקאסט מספר 420 של רברס עם פלטפורמה - זהו באמפרס מספר 76. התאריך היום הוא ה-14 בספטמבר 2021, ואנחנו מקליטים באולפן הוירטואלי שלנו - רן, אלון ודותן - שלום!אז באמפרס זו סדרה של קצרצרים שבה אנחנו מספרים על מה שמצאנו ומעניין בשבוע או בחודש האחרון - לפעמים בחודשים האחרונים אם התעכבנו - ברחבי האינטרנט: Repos מעניינים ב-GitHub, בלוגים מעניינים, פרוייקטים, Utilities ודברים אחרים. אז אני אתחיל, כמיטב המסורת . . .רן - אז האייטם הראשון שלי נתרם למעשה בעבר הרחוק ע”י מיקי טבקה - תודה מיקי! - וזה איכשהו נעלם בארכיון, אז הנה אני מציף את זה שוב: זה איזשהו בלוג-פוסט מעניין שנקרא No Meetings, No Deadlines, No Full-Time Employeesזה בעצם בלוג-פוסט שמספר על איזושהי חברה, סטארטאפ, שהתחיל כמו כל סטארטאפ אחר . . . התחיל בגיוס של כסף וגיוס עובדים . . .לסטארטאפ קוראים Gumroad - זו איזושהי פלטפורמה ל-Creatives, לייצר תוכן . . . אני בטוח שזו לא הפלטפורמה הראשונה בתחום.בכל אופן - התחילו, ייצרו את הפלטפורמה - ולאט לאט נגמר להם הכסף . . . באיזשהו שלב כולם פוטרו, אבל הסטארטאפ המשיך לגדול . . .הסטארטאפ בשיאו הגיע למשהו כמו 25 עובדים, אבל הוא פיטר את כולם והוא [המייסד] נשאר העובד היחיד - ומאז הוא למעשה שכר את כולם אחד-אחד - כ-Freelancers, “עובדים שעתיים” - פחות או יותר את אותם העובדים שהיו לו מקודם.פה בבלוג-פוסט הזה הוא מספר את סיפור חייו של הסטארטאפ, ואני חושב שזה מעניין - מעיין אנטי-תזה לתרבות העבודה שקיימת היום - עם כל ה-Disclaimer-ים שיש:זה לא בהכרח יעבוד לכם - הוא בא ואומר “זה הצליח לנו - אבל בטעות, לא כי תכננו”.אבל זה מצליח - הסטארטאפ היום גדל, אני חושב שיש לו מחזור של משהו כמו 11 מיליון דולר, שזה מכובד בשביל צוות של משהו כמו עשרים-ומשהו אישעוברים דרכו משהו כמו 170 מיליון דולר של המשתמשים שלווהמאפיינים של תרבות העבודה הם כמו שאמרנו מההתחלה - אין שם פגישות, אין דד-ליינים ל-Features, כל התקשורת היא א-סינכרונית - הדבר הראשון שהעובדים עושים זה לכבות Notifications . . . לא להתקין שום דבר על המובייל, לכבות Notifications בכל מקום, לעיתים רחוקות מאוד להשתמש ב-Slack כשצריך - ורוב התקשורת היא דרך GitHub ואני חושב ש-Notion או איזושהי פלטפורמה אחרת.אבל הכל א-סנכרוני וב-Latency של 24 שעות או יותר - וטוב להם, והם מצליחים.אז זהו - אני חושב שזה סיפור מעניין, סיפור יזמי מעניין - בטח לא הסיפור הטיפוסיאולי קצת בא להעלות את הנושא של עבודה מרחוק והאיזון של Work-Life-Balanceזהו סיפור מעניין - מזמין אתכם לקרוא, הקישור ב-Show notes [כאן, הכוונה].(אלון) “הפינה הזו הייתה בחסות רן תבורי, תומך נלהב בעבודה מהבית . . .”שמע, כן - זה עובד, כמו שאמרת - זה כנראה עובד במקרה, זה עובד בסוג מאוד ספציפי של חברותוגם, בוא - אני לא מזלזל, אבל זה לא Billion-Dollar-Company כמו שכל אחד מדמיין בראש . . .(רן) ממש לא, והוא לא מנסה ככה לקפוץ גבוה מדי - הוא אומר: “תשמעו, אנחנו לא הולכים להיות Billion-Dollar-Company, אנחנו לא מכוונים לשם ואנחנו לא רוצים את זה - אבל אנחנו כן מחפשים את האיזון שמתאים לנו, וכל אחד עובד מתי שמתאים לו ולא עובד מתי שלא מתאים לו - ובהתאם לזה הוא גם מקבל את הכסף”.דרך אגב, גם המשכורות שלהם מפורסמות - הם יודעים כמה כל אחד מהם מרוויח לשעה, החל מ-$50 עד $250 לשעה, בהתאם לתפקיד - אז יש פה גם את האלמנט של השקיפות, שהוא יחסית חריג.אולי את זוכרים את Buffer, שפעם פרסמו את טבלת המשכורות שלהםאבל זהו, סיפור מעניין, לגמרי לא הסיפור הטיפוסי, ואני לגמרי לא בא ואומר “באחריות זה הולך לעבוד לכם” - כי זה לא, והוא בעצמו אומר ש”זה עבד לנו במקרה”.ועדיין אני חושב שזה סיפור מעניין ללמוד ממנו.(דותן) מה שאני חושב שמיוחד ב-Gumroad, אם אני זוכר, זה שהם התחברו לאיזושהי נישה, ואני לא יודע איפה זה היום, אבל נישה של קהילת האינדי בכלל ובאופן ספציפי כל ה-Indi-Gaming ו-Game Developers שרוצים למכור את המשחק שלהם ולא בא להם ללכת ל-Publishersאו שהם לא יכולים או שאין להם את התשתית לזהאז אני זוכר שזה מאוד פשוט - אתה בא ל-Gumroad, יוצר לעצמך חשבון ויכול להתחיל למכור עם לינק של Gumroad - וזהו.(רן) כן - אז הם סוג-של-נותנים-דוגמא: אנחנו לא רק מוכרים לקהילה כזאת, שהיא אינדי - אנחנו גם Independent בעצמנו.אז אני לא יודע אם זה הגיע מתוך האג'נדה הזאת או לא, אבל הם סוג-של חיים את ה-Spell שלהם.זהו - בלוג-פוסט יפה, לא ארוך - מזמין אתכם לקרוא, ושוב תודה למיקי.ולאייטם הבא - זה איזשהו Review קצר של ה-Stack overflow survey שהתפרסם לפני כחודש או חודשייםאנחנו עושים את זה קצת באיחור כי הרבה זמן לא הקלטנו [באמפרס]אז אני אוציא כמה כמה דברים קטנים - ויש שם די הרבה, יש המון אינפורמציה, והוא גם מוצג בצורה גרפית מאוד מאוד נחמדה [כמו בפעמים הקודמות] - אז כמה דברים שלי תפסו את העין, כי כל אחד אולי מתעניין בדברים אחרים . . .אז האייטם הראשון זה שהם באים שאומרים שהם הסתכלו על אוכלוסיית הבני 18 ומטה - הממש צעירים, המפתחים הממש צעירים - על איך הם לומדים לפתח, באילו Resource-ים הם משתמשים.והם אומרים שבניגוד אולי למה שהיה פעם, הם כמעט ולא קוראים ספרים או עושים קורסים כתובים - הכל זה Vidoes או איזה שהם Tutorials קצרים או דברים בסגנון הזה.עד כמה שזה אולי נשמע לנו אינטואיטיבי - לבוא ולראות את זה במספרים זה מאוד נחמד, אני חושב, ואולי קצת מאיר את העניים - עכשיו אני יכול לבוא ולהגיד “איך הצעירים לומדים” . . .אבל אני חייב להגיד שכל אחד מאיתנו גם באיזשהו מקום קצת צעיר וגם קצת לומד ככה, וזה כנראה מחלחל לכל הכיוונים.אבל אני חושב שזה מראה באופן מאוד מאוד מובהק את אופי הלימוד שמשתנה עם הזמן, וזה פאן תרבותי מעניין אחד שנחשף שם.עוד משהו מעניין זה Frontend Framework שנקרא Svelte, שלמעשה הגיע בכמה שנים האחרונות - אני לא זוכר בדיוק כמה זמן זה באוויר, או שנתיים-שלוש, אולי קצת יותר - למעשה זה ניהיה ה-Framework האהוב ביותר ע”י מפתחי Frontend, לפי הסקר הזה.אני חייב להעיר, “בפריזמה היסטורית”, שכמעט תמיד ה-New kid on the Block הוא זה שתמיד הכי אוהבים, ואז אחרי כמה זמן מתחילים לשנוא אותו, ככה שבואו אולי לא נפתח יותר מדי תקוות לפני הזמן . . . אבל כן, יש פה New Kids on the block . . .(אלון) רגע, בוא נשים את זה ממש בפרופורציות - ה-Framework הזה, לפי הסקר שלהם - יש לו רק 2.75% שימוש . . . אז ה-2.75% האלה אוהבים אותו, באחוז גבוה . . .(רן) כן . . . נכון . . . אני זוכר, דרך אגב, שגם React היה בנקודה הזאת, אולי אחוזי השימוש היו יותר גבוהים אבל הוא היה ה-Framework האהוב ביותר, וככה זה.אבל בכל אופן - הוא [Svelte] תופס תאוצה, אז אני מניח שמי שבעולם ה-Frontend כבר מכיר את זה.(אלון) אגב, אני חושב שהדבר הכי מעניין בעולם ה-Frontend זה שלראשונה עקפו את jQuery . . . ש-React.js עקף את jQuery, וסוף סוף העפנו את הדבר הזה . . .אז אני רוצה להגיד פה תודה אישית לכל מפתחי ה-Frontend אי-שם שלא בחרו ב-jQuery - באמת, תודה, תקבלו תקליט וגלויה [וכובע גרב].(רן) כמו שאלון אמר - לראשונה אי פעם בהיסטוריה - ואתם שומעים את זה פה, בפעם הראשונה! - ה-Framework של React.js עקף את jQuery בפופלאריות שלו, מבחינת כמות התוכן וכמות השאלות ב-Stack Overflow, וכו' . . .אז כן, הגיע הזמן, חבר'ה . . . אם מישהו ממאזיננו עדיין משתמש ב-jQuery, אתם מוזמנים להפסיק . . . או להאזין, או להשתמש - אבל מוזמנים להפסיק.אני חייב להגיד שאני התחלתי עוד לפני jQuery - למי שזוכר, היה Prototype.js . . . עוד לפני, אפילו יותר נוראי.בזמנו זה היה אולי Life-Saver, אבל כן - עם מה שיש לנו היום זה כבר באמת נראה משהו פרה-היסטורי.זהו, עד כאן . . . יש לי הרבה פריטים קלילים ומצחיקים, נשמור אותם לאחר כך - אז אליך, אלון.אלון - זה הגיע מהר מהצפוי . . . בסדר . . .אז קודם כל - אני רוצה להגיד שוב תודה לכל עובדי GitHub שמאזינים לנו ושמעו את האייטם האגדי שלי - עורך! אם אפשר לשים פה את הקטע שוב מהאייטם? נעשה הפסקה . . . [הקהל מתבקש לדמיין את הפתיח של מנהרת הזמן ולחזור ל - 410 Bumpers 73]“ . . . וזה האייטם האחרון שלי בהחלט, כי אחריו אי אפשר לעלות יותר גבוה: אני עושה פהDrop-Mic וזהו - זה הפרק האחרון, לא תראו אותי יותר, זה פרק אחרון - GitHub to VS Code:כל מה שצריך לעשות, זה מטורף - קחו Repoתוסיפו, בסוף הקוד של ה-GitHub, תוסיפו “1s” -שמתי פה לינק לאייטם של דותן - ותלחצו וזה פשוט פסיכי . . . פשוט עובדים על הקוד ב-VS Code וזה מאוד נוח לדפדף, לכתוב קוד, כל מה שאתם רוצים - זה VS Code online לכל Repo, אם Private או Public, של GitHub . . .“וחזרנו [לקו הזמן הנוכחי, בערך]. . . .אז האייטם האגדי, על זה שאם ב-Repo מוסיפים “1s” בסוף אז מגיעים ל-vscode on-the-fly - אז GitHub, לאור ההתלהבות שיצרתי בעולם עם זה, החליטו להוסיף את זה - ועכשיו אפשר פשוט בכל Repo על dot [“.”] ומקבלים את ה-vscode built-in ואפשר לעבוד על זה אז אני מרגיש ממש חלק מה-Feature הזה, אני חייב להגיד לכם . . .אבל זה Feature מדהים, חסכו לנו לשנות את ה-URL, וזה גם עובד עם Private Repos . . . (רן) נתנו לך קרדיט ב-Release notes או לא?(אלון) אני מעדיף לא להיכנס פה ל . . . העו”ד אמר לא להגיב כרגע לשאלות כאלה[הוא עדיין עסוק בלנקות מאז הפרק 1 באפריל עם זהר והבאמפרס שאחרי?](רן) אתה וזביידי באותה סירה? (אלון) רגע, תן קונטקסט, מה סתם? . . .[גם בשביל זה יש את טל פרידמן]ובוא נמשיך הלאה - אז בהמשך ל-vscode, אז לאור ההצלחה, GitHub הוציאו Cloud IDE [בשם codespaces]שזה כמו vscode - הרעיון הוא שלא צריך כלום, רק לשים על VM כמו . . . איך זה נקרא של AWS, ה-Editor שלהם? ברח לי השם . . .(רן) nine, משהו עם Nine . . .(אלון) A9 אני חושב . . .(דותן) לא, Cloud9 או משהו כזה . . . (אלון) Cloud9, נכון!זה גם חדשות . . . Brackets של Adobe נדמה לי שבוטל, בגלל שהם החליטו ללכת על vscode(אלון) בקיצור, אז עכשיו יש לנו New Kid in the Block, וזה בעצם -vscode in the Cloud, אז אפשר בלי מכונה . . . מה שמגניב זה שאפשר לקחת מחשב ממש חלש - ולקבל שם מחשב-מפלצת, עם איזה 32 ליבות, גזיליון Gb . . . להתקין שם מלא דברים ולהריץ סביבה, אז האמת שזה מעניין . . .(רן) אני רואה שיש שם אופציה או לעבוד על Desktop או ב-Browser . . . ב-Desktop הכוונה היא לחבר את ה-vscode שלך ל-Remote Container?(אלון) אתה אמור לעשות שם את ה-Run . . . לא ניסיתי את זה . . . כמו כל Cloud, אתה משלם פר-שימוש, אז כן - אתה אמור להריץ שם, אבל אתה יכול גם “בלי כלום”, לפתוח Chrome ולכתוב שם הכל עם כל ה-Plug-ins, שזה גם מעניין.(רן) מגניב לאללה(אלון) כן - אז אפשר לקנות עכשיו iPad-ים ולהתחיל לפתח מעל מערכות מורכבות . . . ונמשיך - זה היה על גבול המצחיקולים, אבל שמתי אותו פה: מישהו עשה, בתוך ה-Web, כי היינו עד עכשיו גם בתוך ה-Web - פשוט עשה MacOS בתוך ה-Web . . .זה נראה ממש MacOS, עם כל האפליקציות, ואפשר לפתוח שם, כביכול, vscode בפנים וזה מצחיק, כי זה פותח את ה vscode Web בתוך אפליקציית Web, ואנחנו קצת חיים בלופ עם עצמנו[אחרת מה היינו עושים כל הרפרנסים ל-Inception?]עכשיו - זה פרוייקט ממש חמוד, אז כל מי שאוהב את הפרויקטים שמנסים לעשות מערכת אחרת - אז זה ממש נראה כמו Mac, עשוי ממש טוב, וזה “חי בתוך ה-Web”.(דותן) קודם כל - זה עובד ממש מדהים . . . אנימציות סופר-טבעיות, ויש פה מלא Attention to Details, מלא . . . מדהים.(אלון) אני עדיין בשוק מזה שאני אשכרה משם פותח vscode, ואני אשכרה יכול להריץ . . . זה די הזוי.(רן) כן, אז חלק מהאפליקציות כבר פועלות וחלק עדיין לא, חלק הן Coming Soon - אבל מה שבאמת פועל זה באמת ממש יפה.(אלון) כן, אז זה פרויקט שעשו - מי שרוצה Calculator יכול להיכנס לזה, ללחוץ על Calculator ויש לו Calculator שם, על Mac . . . או כל מיני דברים אחרים.(רן) אז אתה יכול להתחבר מה-vscode של זה ל-Spaces ממקודם, ולפתח?(אלון) זה יכול להיות ניסיון מעניין . . . “ונפתח את זה!”, תוך כדי שאתה עובד בתוך זה . . .(רן) ולעשות Deploy . . . זה כמו לעשות Reboot ל-Server שאתה עושה אליו SSH . . . (דותן) אה, כל פעם שפותחים את זה, את ה-vscode, אז ה-ReadMe הוא של הפרויקט הזה . . . מה שכתוב פה זה שה-Framework זה Svelte, וכתוב earlier Preact, אז זה מסביר למה Svelte כזה פופלארי - כי זה React, בעצם . . . (רן) האקדח מהמערכה הראשונה . . .(דותן) כן, פיספסתי את השינוי הזה . . .סך הכל שינוי שם . . . (אלון) Preact בא אחרי React? או . . . .(דותן) לא - React . . . זה בא כדי לייצר React יותר Light-weight כזה . . . (אלון) כן - אבל הוא Pre-React . . . לא משנה . . .(רן) אם אומרים לך בפגישה “אלון, אתה צריך להיות יותר פרי-אקטיבי” . . . . מה זה אומר?(אלון) שאני עובר ל - Svelte . . . מה זאת אומרת?! אמרתי “אוקיי, קיבלתי את הפידבק, עוברים ל-Svelte . . . “(דותן) אבל לא - זה לא שינה שם . . . אוי, איזה מבלבל זה . . . (אלון) הפרויקט פעם היה . . .(דותן) קודם היה Preact, ואז הוא אומר שהחליפו ל-S . . .(רן) Svelte!(דותן) מוזר . . . .(רן) אז זוהו שני האחוזים ב-GitHub, בסקר ממקודם . . . (דותן) יכול להיות . . . (אלון) הוא - וכל הקהילה שסביבו שם . . . זה ה-2% . . . והוא אוהב את זה, הוא הצביע שהוא אוהב את זה, אנחנו כבר יודעים.נמשיך - פשוט חזרתי מדי פעם למשרדים, קצת, ויש אנשים שהטרמינל שלהם עדיין מצפצף מסתבר, ה-Bell . . . אז אמרתי שאולי יש אנשים שעדיין לא יודעים שאפשר לעשות לזה Mute . . . אז שמתי את זה - איך לעשות Mute ל-Bell ב-Terminal - למי שמכיר, לפעמים עושים את זה עם חץ למעלה או חץ למטה, אני כבר לא זוכר מתי הוא מצפצף(דותן) אני חושב שאנשים שיכולים לחיות עם ה-Bell הזה, יש להם מעלות . . . הם יכולים לסבול הכל.מי שלא שם לב לזה ופשוט חי עם זה, יכול לסבול הכל, לדעתי.(אלון) אני חושב שזה אותם אנשים שה-Slack שלהם עדיין עושה טיק-טיק . . . כאילו, הרי הדבר הראשון שאתה עושה ב-Slack זה Mute, נכון? . . .(דותן) אני מתחרפן מזה . . .(אלון) . . . נראה לי שיש חפיפה מלאה בין האנשים האלה . . .(רן) זה כמו התנייה פבלובלית - ברגע שאתה שומע את הפעמון אז אתה יודע שאתה הולך לקבל עונש . . . (אלון) כן . . . אז זה על Mac - מי שעדיין הפעמון שלו שם, אז בשקט בשקט, אל תגלו לאף אחד, ותעשו Mute לפעמוןלא שנגלה שהוא דלק לכם, ונמשיך הלאה בחיינו . . . הדבר הבא - מצאתי אוצר! יש את הספרים של Google על Site Reliability Engineering - המפורסם שבהם זה The Site Reliability Workbook - ויש גם ספר של O'reilly על Building Secure & Reliable Systemsאה, הראשון זה של O'reilly, אבל יש גם את השניים האחרים שהם מוכריםאז יש אותם Online - מלאים . . . אז מי שרוצה מוזמן לקרוא - אלו אחלה ספרים, מומלצים בחום, חינמיים, On-line-י, מלאים(רן) אני, דרך אגב, קראתי - או נראה לי ששמעתי אותם, בעצם - אמנם אין גרסא מוקלטת שלהם, אבל לקחתי תוכנה שממירה את ה-PDF . . .(אלון) יש Audible! . . .(רן) אה, יש כבר? אוקיי, אז כשאני האזנתי עוד לא היה [Audible? הם קיימים כבר לא מעט זמן, אחלה דבר . . . ][תכל'ס, ה-Release date על זה הוא מאי 2021, אז זה כנראה די חדש…]זה נשמע קצת מוזר, בעיקר כשיש כל מיני נוסחאות - מדי פעם יש להם נוסחאות ל-Latency או דברים כאלה, אז זה נשמע קצת מוזר כשה-Reader מנסה להקריא את הנוסחאות, אבל חוץ מזה זה סבבה.[אז מתי Google מוציאים כזה עם Wil Wheaton? מה, רק לחטיבה של Waze מותר שטויות?](אלון) אני זכיתי איתך באיזה כנס של Google פעם בספר, ומאז הוא אצלי על השולחן שוכב, מעלה אבק . . . סתם, לא קראתי אותו מאז - ושמעתי את ה[גרסת] Audible, בגלל זה אני יודע שיש Audible.אחלה ספרים - מומלץ בחום.האייטם הבא זה פרויקט שנקרא Airbyte - הוא נראה ממש חמוד, מאוד מתוחזק ויחסית צעיר, עושה רושם שהוא Data integration made simple, secure and extensibleזה Open Source שנותן לעשות Dashboard שרואים לפחות מה קורה עם האפליקציות - מתי הן עשו Sync, ו-API ו-Data Warehouse, דברים כאלהזה נראה כזה Aggregator של מלא דברים, עם UI ממש חמוד . . .לא הבנתי לגמרי עדיין את מה הוא בא להחליף . . . אבל הוא נראה נוח, מבחינת הויזיביליות (Visibility) שלו.מבחינת שימוש וזה - לא ניסיתי . . .(דותן) ממה שאני קורא, זה נראה כמו Redash עם יכולות טרנספורמציה לדאטה . . .(אלון) זה יותר מזה, כי אתה מקבל סטטוסים של הדאטה שלך . . . זה קצת מזכיר את ה-Airflow, את המערכת וזיאליזציה שלהם . . .(דותן) אה . . . אוקיי, זה מסביר את השם אולי? Airbyte . . .(אלון) יכול להיות . . . אני חושב שזה . . . (דותן) אתה יכול להעביר Byte אחד, כאילו?(אלון) כן . . . אחד - זה לא סקלאבילי (Saleable). . . זה Byte-Byte, למה אתה ממהר?(דותן) כשאתה עושה New Project, אתה בעצם מקבל Byte אחד - ואת ה-Byte הזה אתה מעביר? אינטרגרציה של Byte . . . (אלון) Old-School, כן, Byte-Byte נעבוד . . . (דותן) כתוב כמה Bit-ים זה, ה-Byte הזה? . . . (אלון) אה . . . הם לא מפרסמים . . . (רן) גם לא אומרים אם זה אינדיאני גדול או קטן [Endianness] . . . אבל זה נראה כמו משהו שהוא, לפחות לפי הדוגמא שלהם, משהו שמפוקס על עולם הפרסום,זאת אומרת - אפשר לעשות סנכרון, נגיד בדוגמא שלהם, ל-Facebook Ad, ל-Salesforce או Hubspot ו-Linked Ads וכו' - אז זה נשמע כאילו הוא מביא דאטה, שם את הכל באותו המקום - ואתה בעצם יכול לשלוט . . . יכול לעשות פה Monitoring ל-Workflow שלו.מה זה בא להחליף? האמת שאני לא מכיר שום כלי אחר שזה בא להחליף . . . כנראה איזושהי “סקריפטולוגיה” פנימית, לא ראיתי לפני כן כלי שעושה משהו כזה.(אלון) בקיצור - נראה לי חביב: נסו, ספרו איך היה. נהניתם? ספרו לחבריכם . . . (דותן) נראה לי שצריך לעשות פה איזושהי הסברה . . . רן, אמרת “אינדאני גדול או קטן” - אז סתם, כדי לא לפגוע באוכלוסיות מסויימות [שלא קראו את הטקסט וראו את ההפנייה . . . ] - זה Endianness, זאת אומרת “סופתי” . . . (רן) כן, זו הייתה הלצה . . . “סופתי”, כן . . . Endian(אלון) תודה, על ההבהרה, דותן - אני בטוח שאף אחד לא הבין, פשוט, וזה היה ממש חשוב.[והעו”ד כבר די עסוק, אמרנו . . . ] טוב, אז הדבר הבא זה פרויקט שנקרא ה-Joker Language- זה בעצם interpreted dialect של Clojure שנכתב ב-Go . . . .אפשר להריץ פה ClojureScript בתוכו . . .אז לחובבי ז'אנר ה-Clojure - כן, כל אותם . . . מי זה? AppsFlyer? אז כל אותם אלה ב-AppsFlyer שמאזינים - נראה לי שזה בשבילכם . . .(רן) גם Nanit, בישראל, דרך אגב, יש עוד כמה . . .[הם אפילו כתבו על זה לא מזמן](אלון) יש עוד כמה? . . . (רן) כן - NET@ [?] מכירים? יש לנו בטח כמה מאזינים שם . . . . ויש בטח עוד כמה בפינלנד ובעוד כמה מקומות בעולם . . . אבל כן - אם תמיד חלמתם לכתוב Clojure ולתת ל-interpreter ב-Go להריץ את זה - אז זו ההזדמנות שלכם . . . לכו ל-Joker.[לא זה](אלון) כן, זה מגניב.ולנושא שהחלטתי להוסיף פה לפני . . . בקרדיטים, Undocumented מה שנקרא - יש משהו שנקרא Reflect.app, לכל מי שאוהב Nodes או עדיין תקוע עם איזה Evernote או איזשהו משהו ארכאי כזה.אז אפשר לנסות לעבוד עם Reflect.app - זה עושה גם mile-map ל-Note-ים, למי שאוהב לשמור Note-ים - אתם יכולים לנסות.(רן) בוא, אני אתן קצת רקע - לפני שהתחלנו את ההקלטה, כל אחד שאל “רגע, אז איך כל אחד שומר את ה-Notes לקראת הפרק הזה?”זאת אומרת - אנחנו אוספים את זה במשך משהו כמו חודש, לפעמים קצת יותר - אז איפה כל אחד שומר?אז דותן ב-Evernote, אני שם את זה ב-Paper ואלון, במה אתה?(אלון) ב-Keep . . .(רן) ב-Keep . . . ואז התחלנו להעלות כל מיני אופציות אחרות, ו-Reflect.app הייתה אחת מהאופציות באמת, שעלו.אז זה הקונטקסט של כל זה . . . .אז תודה אלון - ואליך דותן . . .(אלון) דותן בפינתנו “Rust-Rust וירקות אחרים” . . . .(דותן) לגמרי . . .דותן - אז היום רק Rust - החלטתי לעשות לכם לגמרי כיפה אדומה, אז נתחיל:האייטם הראשון נקרא rust-tui-template - כש-TUI זה Textual UIמה שנקרא - אי אפשר להוציא את ה-BBS-ים ממני . . . זה UI שנמצא בתוך ה-Terminal, בדרך כלל הוא עם מסגרות כאלה נחמדות ולא טקסטואלי לגמרי, אבל מכיל כל מיני אלמנטים של ASCII ו-ANSI, מה שנקרא “של פעם”.והפרויקט הזה - לכל מי שרוצה לבנות App כזה מגניב, אז הוא פשוט איזשהו Boilerplate מדהים, שסוגר את כל הפינות.זאת אומרת שכשמתחילים פרויקט עם זה, מקבלים . . . בעצם כל קובץ והמטרה שלולמשל - קובץ שאחראי על ה-Widget-ים של ה-UI, קובץ שאחראי על ה-Data וה-Handler של ה-Keyboardבעצם, כשבונים אפליקציה כזאת - אפליקציה ל-Terminal - יש הרבה “צנרת” שצריכה לקרות . . . יותר מה-Browser ויותר מכל דבר אחר, וה-Template הזה די סוגר את זה.אז למי שרוצה ללמוד Rust - לדעתי זו הדרך הכי טובה: לחשוב על איזשהו רעיון, איזושהי אפליקציה של Productivity, לסגור איזושהי פינהנגיד “לקחת Notes” ,שדיברנו על זה מקודםוזה ממש נחיתה רכה לתוך זה.האייטם הבא, למי שרוצה לראות לאן אפשר להגיע - יש פה מישהו שבנה פרויקט שנקרא gobangזה לא כתוב ב-Go . . . זה כתוב ב-Rust(אלון) כמעט הפלת אותי . . . (דותן) זה בעצם Database Management Browser כזה . . . כמו כל כלי שמתמשים בו כדי לעשות Queries לתוך Database-ים כדי לראות מה קורה ולצפות בתוצאות.והכל מבוסס Text-UI - לא Command Line אלא Text-UI - נפתח חלון, כמו VIM כזה, ומנווטים בו בתוך העולם הזה . . .נראה ממש טוב, עובד כמובן מאוד מהר, תומך ב-MySQL וב-PostgreSQL . . . בעצם אפשר להסתכל ולחפור פנימה ולראות איך זה בנוי - תוך כדי שאתם בונים את מה שאתם רוצים.(אלון) עצה שלי - שים לזה רק Read-Only Connection, כי זה ב-Alpha . . .(דותן) כן, זה Read-Only . . .(אלון) . . . לך תדע אם ה-Delete פה . . . אם יש איך להריץ דברים ,שלא יהרוג אותו.(דותן) נכון - כמובן שבכל הדברים האלה צריך . . . לא להתחבר ל-Production עם הדבר הזה . . .(אלון) ... אלא אם כן זה Mongo, ואז זה לא משנה(דותן) כן, Read, Write, זה לא באמת חשוב . . . .(אלון) לא עקרוני . . .(דותן) אז האייטם הבא הוא גם בקו הזה של UI - אז יש פרויקט שנקרא Druid - לא ה-druid של ה-Data אלא UI[וכמובן שמתבקש]ב-Title, זה Data-first Rust-native UI toolkit - או במילים אחרות: סוג של מימוש React-י, עם תחושה של React, בתוך Rustכשמדברים על UI, אז זה על אפליקציות Desktop, בעצם.(אלון) במקור - אתה צריך לספר את ההיסטוריה - זה נולד כמכשיר עינויים . . .(דותן) למה?(אלון) מי רוצה לכתוב ב-Rust את ה-UI?(דותן) קודם כל - אם אתה רוצה לכתוב אפליקציית UI שהיא Cross-Platform, מה אתה עושה היום?(אלון) Web . . .(דותן) ואם אתה לא רוצה Web, אתה רוצה Native - מה אתה עושה? אולי Electron או משהו כזה . . . (אלון) כן, Electron. . . למה? זה נראה לי סיוט . . . (דותן) תלוי בדרישות . . . למשל - יש הפצת Linux שאני מאוד אוהב שנקראית elementary, וזה נראה ממש, נקרא לזה “כמו-Mac” - אבל זה מדהים, לדעתי זה Linux כמו ש-Linux היה צריך להיראות.ושם בונים Native-UI Apps - וכמובן שכשאתה בונה הפצה של מערכת הפעלה, אתה לא יכול באמת לארוז הכל ב-Electron - אפליקציה של מחשבון שתיקח לך 150Mb ותגמור לך את ה-CPU והזיכרון.[ב- Microsoft Teams זה לגיטימי . . . .]אז שם הם עושים את זה עם Vala - ו-Vala זה איזשהו “שיקוץ” כזה, זה #C מעל GTK, וזה כזה משהו שתמיד הרגיש כאילו נעשה בשביל ”לסגור פינה” - אבל כל מערכת ההפעלה בנויה בזה, והיא עובדת מדהים.אז נגיד לדבר כזה זה מאוד שימושי . . . אז זהו - זה Druid, והיום ה-Reference Implementation של UI Apps, מסתבר, זה לממש Spotify Client . . .אז בעצם הוספתי לינק למישהו שעבד עם Druid ופיתח פרויקט שנקרא psst - כמו שעושים למישהו “פססט” כזה, לחתולים . . . וזה בעצם Spotify client ממומש Native-לי, בלי Electron, רק עם Rustבעצם מקבלים, אני משער - האמת שאפשר גם לא לשער . . . לא, אין Releases - אז אני משער שזו תיהיה אפליקציה ששוקלת 4-5Mb, משהו כזה.זהו, אז בעצם . . .(אלון) עם “UI בשקל”, בסדר . . .(דותן) למה? ה-UI נראה טוב . . . כאילו, אתה יכול להסתכל על ה-Screenshot-ים, הוא נראה סבבה . . . (אלון) כן, נו - אבל אחרי זה . . . לא יודע, אני חושב שאלא אם כן אתה באמת חייב את זה, לברוח . . .(דותן) אין ספק שהקריטריון הוא שאתה חייב את זה . . . יש המון אופציות לא לבנות Native - אבל אם אתה חייב את זה, אז בעצם מה האפשרויות? האפשרויות הן - אם אתה רוצה Cross-Platform . . .נגיד, Linux יתפוס לך הרבה מאוד נפח, אז זה GTK, ו-GTK זה חתיכת סיוט . . . אז כן, אם אתה חייב, במקרים שאתה חייב - אני חושב שאין הרבה פתרונות טובים ל-Cross-Platform וזה יכול להיות פתרון טוב.הקטיגוריה הבאה של Rust שאני מתעניין בה זה משחקים - אז יש Platformers ויש כל מיני Indi-Frameworks לפיתוח משחקים, כש-Unity היום, במיוחד בתחרויות פיתוח משחקים, הוא השולט, ותמיד אני מחפש את ה . . . אני יודע של-Rust יש Sweet-spot של Performance ו-Productivity ותמיד אני מחפש לראות איך עולם ה-Indi-Games או חבר'ה שבאים ו . . . שהם לא סטודיו מטורף, ומשתמשים ב-Rust כדי לנצל את המעלות שלו כדי לפתח משחקים - וזה מתחיל לקרות.אז יש כזה משחק שנקרא Fish Fight, שבעצם עשו לו Open-Source - הוא לא היה בתקופה מסויימת, והפך להיות Open-Source.זה איזשהו Tactical 2D shooter מצחיק כזה, עם דגים שנלחמים אחד בשני - ממש מגניב, לא עלוב בכלל אלא להיפך, זה כזה . . . יש לזה “פקטור מגניבות” כזה.וזה משתמש ב-Framework ב-Rust שנקרא Macroquad - שעברתי עליו ובדקתי אותו ונראה ממש ממש טוב, לפיתוח משחקים Indiבנוסף, יש המון Learning Materials בתוך המשחק הזה, כולל Tutorial של איך לבנות משחק וכולל איזושהו Mini-Setup ל-Platformer.אז ככה, לתקופת החגים הקרובה - למי שיש לו זמן ורוצה לצלול ולפתח משחק - שזה לדעתי אחד הדברים הכי כיפיים לעשות - אז זו אחלה נקודה להתחיל בה. זהו . . .האייטם הבא נקרא Rustacean Principles . . . עכשיו, לכל קהילה יש איזושהי נקודה - אני זוכר את זה במיוחד מאיך שקהילת ה-Ruby התפתחה - יש נקודה שמתחילים לזהות “אופי של קהילה”, וכמובן שהאופי הזה נובע… אם הקהילה היא סביב שפה אז הוא נובע מאיך שהשפה בנויה ומה שהיא דורשת מהמשתתפים בקהילה.אז יש את Niko Matsakis - אחד הכוכבים בקהילה הזו [הפנייה ל-ציטוטים מומצאים של הגשש?]והוא החליט להסתכל ולעשות איזושהי אובסרבציה (Observation) ולהביא כמה עקרונות שמלווים אנשים שבונים ב-Rust, וגם את הקהילה עצמה.אני אתן כמה דוגמאות - לא יודע אם כולם ממש תואמים, אבל נגיד:למשל - ”Reliable: “if it compiles, it works - וזה נכוןאו “Performant: “idiomatic code runs efficiently - זה גם נכון . . .קהילה שהיא Supportive - שזה נכון בצורה . . . לא כמו קהילת ה-Ruby, אבל זה די נכוןוגם Productive ו- Transparent ו- Versatileאז כל הדברים האלה - אני יכול להעיד לפחות שהם נכונים.בעצם זה מוביל אותי לאייטם, שאני דווקא אתן דוגמא . . . הוא גם משמש כדוגמא לדברים האלה.אז יש חבילה בשם polars - וזה נראה לי שרן יאהב - וזה בעצם Blazingly fast DataFrames in Rust & Pythonאז בעצם לקחו DataFrames, מימשו חלק מהפעולות - או “חתיכה מהעולם” - ב-Rust - ועשו Binding ל-Pythonובעצם, אם נסתכל על ה-Benchmark-ים, שזה החלק החשוב בדבר הזה - המימוש ב-Rust הגיע, כמעט תמיד, למקום השני בכל ה-Benchmark-ים, מקום שני-שלישי.אם מסתכלים בקוד - ואני עברתי על הקוד - אין שום דבר שנכתב ב-Rust שנראה Specialized . . . אין Hack-ים, אין טריקים - כל האימפלמנטציה (Implementation) “נאיבית”.יש שם Generics, יש שם איטרציות (Iterations) מעל Collection-ים מאוד מאוד High-level . . . יש Temporary variables והמון אבסטרקציות (Abstractions)וכל הדבר הזה לא משפיע בכלום על ה-Performance . . .(רן) אני חושב שהסתכלתי על זה בעבר - זה נחמד, כאילו, הזריזות של זה זה נחמדחסרה הפונקציונאליות הגדולה שיש ב-pandas . . .(דותן) כן, זה לא מחליף את pandas, זה לא מחליף . . . זה נותן חתיכה מהסיפור . . . (רן) כן - אבל אם זה יגדל, זה יכול להיות תחליף טוב ל-pandas, אני מסכים.(דותן) כן, אז כאילו מה שאני מנסה להעביר זה שכשראיתי את הפרויקט הזה, הדבר הראשון שעשיתי זה לצלול ולהבין האם יש Hack-יםכל מיני Hack-ים של Performance, כל מיני טריקים כדי לממש דברים בצורה יותר חכמה ויותר מהירה - ואין . . .כלומר - הכל קוד “Vanilla” של Rust שאפשר לקרוא בצורה “הומאנית”, וזה אחד הדברים המעניינים.(רן) כן, ונגיד שגם דברים שקיימים ב-pandas - כשהם רצים מהר, אז זה רץ ב-++C . . . זה אומרת או שזה Alpine מתחת, או שזה מימושי ++C ספציפייםאבל שום דבר לא רץ מהר ככה ב-Python . . . אז פה בעצם אולי הם הצליחו לייצר משהו שהוא ב-Rust ויותר מהיר מ- ++C, אבל זה לא משהו שהוא אינרנטי (Inherent) . . .אולי זה מימוש יותר אלגנטי, אולי זה מימוש של איזשהו Subset של פונקציונאליות . . .(דותן) כן, צריך לזכור שמה שמקבלים בחינם, בניגוד ל-++C, זה Safety ו-Memory leaks - שאין - ובאגים טיפוסיים שמן מהסתם שייכים לעולם הזה של C ו-++Cוקוד שהוא קריא-בטירוף, הייתי קורא לזה . . . מדהים.(רן) קראת ל-++C “לא קריא” ברגע זה?!(דותן) כן.לא קריא - וגם הופך אותך ללא-שפוי לאורך זמן . . . (רן) “לא שפוי” זה עניין יחסי . . . בסדר. אין בעיה, לא נפתח פה חזית . . . הלאה.(דותן) הוספתי אייטם ל-Fast Rust Builds, כי ידעתי שאלון יקפוץ מיד עם ה-Build-ים האיטיים ב-Rust, כדי לסגור את הפינה ומראש להנחית מהלומה . . .(אלון) להרגיע לפני שזה גדל, אתה אומר . . .(דותן) לגמרי.(רן) מכיר את הבדיחה על הקומקום?(דותן) לא . . .(רן) ילד ואבא יושבים, ופתאום הקומקום על הכיריים - פעם היו קומקומים על הכיריים, שהיו שורקים ברגע שהם היו רותחים, כי היה להם מעיין פקק כזה, לפני הקומקומים החשמליים . . . - אז ברגע שהקומקום שורק, האבא רץ ונותן לו מכה ככה, עם מחבט.אז הילד שואל אותו “מה קרה? למה אתה ככה נותן מכה לקומקום?”שכחתי לציין לפני כן שהאבא נפגע בתאונת רכבת . . . ננסה שוב . . .(אלון) האמא בתאונת רכבת . . . (רן) אז האבא אומר “צריך להרוג אותם כשהם עוד קטנים”.(דותן) הרסת את הבדיחה, באמת . . .(אלון) הרכבת הייתה עושה “טו-טו” ו . . .(דותן) האמת . . . העורך יכול לתקן את זה? אחלה אתגר . . .[אה . . . ](רן) אני רק אציין שאני העורך ברגעים אלו . . . (דותן) בסדר, עדיין אפשר לקרוא לך “העורך” . . .(רן) כן, “בכובע העורך”(אלון) וואו . . . קודם כל, זה טוב לדעת שאתה עורך . . . תראה, אם אתה רק הופך את הסדר של הבדיחה שתיהיה בסדר בעריכה, אז היא תיהיה בינונית . . .(רן) אני חושב שיעריכו אותנטיות פה . . . נשאיר את זה As-is . . .אבל כמה יותר מהר? בוא נחזור רגע - “Build-ים יותר מהירים” - כמה? מה?(דותן) אז הוא מסכם את המאמר עם משהו שאני מסכים איתו - Build של Rust עם בערך 200,000 שורות קוד, עם אופטימיזציות אגרסיביות . . . ב-Rust יש סרגל שלם של אופטימיזציות שאפשר להפעילצריך לקחת בסביבות העשר דקות.שזה נשמע הרבה, אבל אתה . . .(רן) ולפני זה כמה היה?(דותן) אז הוא לא לקח . . . הוא לא עשה Use Case של “לפני ואחרי”, זה לא ממש מאמר שאתה מסתכל עליו ואומר “אוקיי, הנה הבעיה ו . . .”הוא פשוט נותן כמה טריקים ידועים לקהילההרוב זה Caching ו-Caching חכם - ולמה Caching ו-Caching חכם? כי Rust בעצם מאוד קרוב ל- C ו-++C במובן הזה, ספריות שנבנות הן ספריות שהופכות להיות סוג של Binary Libraries.ואם . . מה זה “אם?” הספריות האלה לא משתנות . . . אז בעצם אתה רוצה לעשות Caching של האוביקטים האלה כבינאריים, ואז אתה בעצם מקבל את זה “חינם” . . . אז יש עולם שלם של Build Cache, שהוא זהה כמעט לגמרי אם אתה בא מ-++C וכאלה - אז זה אחדושתיים - כל הקומפילציה (Compiling) של מפתחים, אנחנו עושים . . . .אני חושב שנגיד גם ב-Java זה קיים, וב-Kotlin - יש Incremental Builds: אתה בעצם עושה Build רק של מה שהשתנהוב-CI זה לא רלוונטי, אז אתה עושה Disable לכל המנגנון הזה ואז זה מאיץ לך את ה-Build בסוף . . . כל מיני טריקים כאלה הוא נותן שם כמה מספרים . . . אני יכול להגיד לך שאני הייתי על Build-ים של חצי שעה, ואז הקטנתי אותם לסדר גודל כזה של עשר דקות.(אלון) העיקר צחקת עלי, שאני אמרתי “מה? לא יכולת להגיד “חצי שעה זה סבבה! אתה יודע כמה קפה אני יכול לשתות בחצי שעה?””(דותן) תלוי ,יש תקופות שאתה רוצה שה-Build יקח חצי שעה, אבל כן . . . אז בקיצור - אייטם הבא: אז לקחתי פה איזשהו סיפור בהמשכים של חברה בשם CROWDSTRIKEזו חברת סייבר די גדולה, פומבית (Public), נאסד”ק וכאלה . . . די מפורסמת גם.והם מספרים סיפור שככה יצא לי לחוות אותו אחד-לאחד - והוא איך בעצם לוקחים את עולם ה-Machine Learning של Python ומחברים אותו עם Rust, כאשר ה-Python עושה את ה-Training ו-Rust עושה את הפרדיקציה (Prediction),כדי לקבל את הפרדיקציה - וזה גם מה שאני חוויתי - לקבל פרדיקציה יותר מהירה.אז הם עשו את זה בשני חלקים, והם מראים פה בעצם נתונים מדהימים - מתחילים בעצם ב-Background ו”למה?” - איזשהו Assessment כזה של שני פרויקטים שלהם -אחד נקרא “Dark Knight” - יש להם שמות מגניבים לפרויקטים - והשני נקרא “Airen”אחד בעצם מבוסס TensorFlow ו-Python ו- ++C וכל מיני שטויותוהשני בעצם מבוסס Rust ו-Pythonומראים תוצאות מדהימות, זה המאמר הראשון - אז נתחיל עם התוצאה, מראים כאן מספריםלדוגמא 2.98 לעומת 0.16 ב-Rust . . . לדעתי זה ב-milliSeconds, כן זה milliSecondsאז זה Mind-boggling, ההבדלים האלה - וכשזה חשוב לך לקבל את הפרדיקציה במהירות, אז זה מאוד מאוד משמעותימה שהם מדברים על Use-Case-ים, אז יש להם טכנולוגיה אחת לזהות URL-ים “חשודים”, ועוד אחת לזהות שינויי קבציםושתי הטכנולוגיות האלה מבוססות על Machine Learning ו-TensorFlow - וחשוב להם מאוד ה-Real-time-יות של זה . . . ולכן הם התחילו לבחון פתרונות אחרים.אז בחלק השני הם בעצם פורטים את “המכניקה” של מה שהם עשו, שזה דבר יחסית-סטנדרטי -הם בעצם לקחו חלקים מ-Python והיו חייבים לשכתב אותם ב-Rust, את כל העניין של הפרדיקציהוהם מסבירים למה זה היה שווה להםאני יכול להגיד שעברתי בדיוק את אותו תהליך אצלנו, לפני משהו כמו שנה, וזה פשוט . . הפירות של זה הם ממש עד היום.זהו - זה למי שמתעניין על איך להאיץ את ה . . . או שצריך פרדיקציה מהירה.(רן) אבל הם גם עושים את זה ע”י tf.function? זאת אומרת, בגדול, כשאתה עושה את זה דרך TensorFlow, אתה יכול לכתוב קוד Python-י ולשים איזשהו Decorator של tf.function - ואז זה מייצר Predictor מהירהשאלה אם הויזיבליות הזאת גם קיימת פה, או שהם צריכים לכתוב . . .(דותן) הם כתבו חלק מהדברים האלה מחדש . . .(רן) כן . . . אז פה, כאילו, “זה לא חוכמה”, באיזשהו מובן - כי הם כתבו משהו שהוא ממש Dedicated ל-Use Case שלהם, לא משהו שהוא גנרי זאת אומרת שאם הם אח”כ ירצו לשנות את המבנה, אני מניח, או לשנות משהו אחר - אז הם יצטרכו לכתוב משהו שהוא Dedicated שוב ב-Rustאז זה קצת כאילו להשוות תפוחים לתפוזים, באיזשהו מובןאז כן - אם אתה כותב משהו שהוא מאוד Dedicated, אז תוכל להשיג משהו יותר מהיר . . . דרך אגב, יכול להיות שאם היו כותבים בדיוק את אותו הדבר ב-++C ישירות מה-TensorFlow, הם גם היו מקבלים ביצועים כאלה . . . (דותן) אני חושב שפשוט . . . קודם כל, כשנכנסים לפרטים, אז יש פה המרה של מודלאני הלכתי דרך כמה . . . “ביקרתי בכמה תחנות”, וכשהבנתי שאת הפרדיקציה בחרתי לעשות עם XGBoostוהסיפור האישי שלי הוא שמימשתי - למרות שה-XGBoost כתוב ++C - מימשתי את זה מאפס ב-Rust, את החלק של הפרדיקציה.וקיבלתי פרדיקציה יותר מדוייקת - וגם יותר מהירה.אז כאילו באופן מסויים הנתיב הזה הוא . . . אתה חושב שאתה כאילו לוקח קוד, כשאתה מתחיל - אתה חושב שאתה לוקח קוד שאנשים עבדו עליו ועשו אופטימיזציות משוגעות וכו'אתה כותב אותו פשוט ב-Rust על הניסיון הראשון - ובריצה הראשונה אתה פשוט מקבל משהו שעובד יותר מהר . . . וזו החווייה.(רן) לא התכוונתי, דרך אגב, שעשו אופטימיזציות ב-++C - אני מתכוון שיש יותר יוזביליות (Usability)אתה יכול . . . יש יותר ורסטיליות (Versatility), שאתה יכול לעשות יותר דברים.פה אולי הם תפרו ל-Use Case ספציפי שלהם וזה עושה בדיוק את מה שהם צריכים ועושה את זה יותר מהראבל היתרון בגרסא המקורית זה שאתה יכול לעשות, אתה יודע - אתה יכול לכתוב איזו פונקציה גנרית, איזושהי רשת גנרית ב-Python, לקמפל אותה ל-++C עם tf.function - ויש לך משהו חדש.בזמן ש . . .זאת אומרת, אתה לא צריך לכתוב את זה מחדש ב-Rustאבל ברור לי לגמרי שאם יש להם משהו שהוא כבר Stable, הם כבר יודעים מה הם רוצים . . .(דותן) נכון, לגמרי, זה תמיד . . הניסיון השני והשלישי זה תמיד יותר טוב . . . .(אלון) זה כמו Framework גנרי לפתור בעיה ספציפית . . . בשביל לפתור בעיה ספציפית אתה תעשה את האופטימיזציה הנכונהאבל הקונספט מעניין, אני חושב - ברמת ה”לקחת את זה למאקרו” זה בעייתי להגיד “בוא נזרוק TensorFlow ונעבוד עם Rustאבל אני חושב . . .(דותן) הם לא זורקים . . . (אלון) לא . . .(דותן) הם פשוט מימשו את החלק של הפרדיקציה בצורה, נקרא לזה “פרטנית”, או “Custom להם”(אלון) שוב, יכול להיות שאתה יודע . . . טוב, בקיצור, כרגיל, כל מקרה לגופו . . . . אם שווה לך להשקיע בזה או לא.(דותן) הייתי שמח אם הם פותחים את הקוד של זה, אבל לא נראה שזה קרה . . . אבל לך תדע.אני, בכל אופן, אמשיך לעקוב אחרי זה.(אלון) שמע, זה חברת סייבר- חכה שמישהו יפרוץ להם ויוציא את הקוד . . . (דותן) טוב . . . נמשיך לכמה אייטמים אחרונים . . .(רן) יש ל משהו על Rust להיום?(דותן) כן, אז אני אשנה נושא . . . האייטמים האחרונים יהיו על Rust.אז הוספתי עוד לינק בשביל אלון - זה נקרא Cheap tricks for high-performance Rustאז הדף הוא ריק - כי לא צריך טריקים כאלה . . . סתם, יש שם כמה דברים.(אלון) למה רשום בשורה הראשונה “Write in Go”?(דותן) בקיצור, יש שם דברים מאוד מועטים ומאוד שטחיים - כי לא באמת צריך . . . סתם כמה פרמטרים, אין יותר מדי.את האמת, לא בצחוק: אין פה שום דבר שאומר לך איך לכתוב קוד - אני רק שם לב לזה עכשיו - איך לכתוב את הקוד שלך ב-Rust אחרת כדי שיהיה יותר [מוטה-] Performance.כל מה שיש פה זה Build flags למיניהם . . . שזה מעניין.(אלון) כי הם עדיין לא הצליחו להריץ את בקוד, אז הם מקמפלים (Compiling)?(דותן) יכול להיות . . . סבבה.אייטם אחרון - ונקנח דווקא עם Rust: זה נקרא Miriזה פרויקט שעבדו עליו הרבה זמן, התחיל כפרויקט אקספירמנטלי (Experimental) לגמרי בעולם של שפות תכנותהניסיון היה לקחת . . . הרי Rust מתקמפל (Compile) לאיזשהו “ייצוג ביניים” - Intermediate interpretation, איזשהו IR - ואז את הייצוג ביניים הזה, שאפשר לחשוב על זה כעל “Assembler-מתוחכם-High-Level” - הדבר הזה מתקמפל ל-Machine-Code ע”י מנגנון אחר.אז בעצם הרעיון שהיה ב-Rust, שהוא רעיון יוצא דופן - לקחת רק את הקוד IR הזה ולהריץ אותו ב-Run-Time, כמו Interpreter - כשהמטרה בסוף היא שיהיה פרויקט - במקרה הזה Miri - שיודע “לקרוא החוצה את החתיכות לוגיקה” האלה ולמצוא בהן כל מיני בעיות לוגיות.למצוא אופטימיזציות, למצוא באגים למיניהם - כל מיני דברים כאלה.אז הדבר הזה כבר “עלה כיתה” - הוא כבר רץ על כל מיני ספריות ב-Rust ומצא באגים אמיתייםזאת אומרת - יש טסטים, יש הכל, זה ספריות Open-Source גם . . . אבל באגים שבסוף, אין מה לעשות - זה טעויות של מפתחים, ובסופו של דבר יש באגים . . . אז זה מצא לא מעט באגים בצורה אוטומטית בספריות מאוד פופולאריות - וגם בספריות Core של השפה.אז אני חושב שאולי Valgrind וכל המשפחות האלה של ה-Tool-ים - בגישה זה זהה.בטכניקה זה שונה.(רן) אוקיי - ועד כאן החלק על Rust, נראה לי . . . עד כאן בעצם החלק הרציני של הערב.אז יש לנו סדרה של קטעים קצת יותר הומוריסטים - המצחיקולים שלנו [יש מצב שכבר שווה פתיח נפרד : - ) . . . ]אז נתחיל:הלינק הראשון נתרם ע”י מאזיננו ערן - תודה ערן!הלינק הראשון נקרא How-I-experience-Web-Today.com - וכשאתם לוחצים עליו אתם בעצם מקבלים איזושהי חוויה שכנראה ראיתם אותה בעבר, שבה אתם למעשה, נניח, עושים איזשהו חיפוש ב-Google ומקבלים איזשהו לינק לאתר, לוחצים על האתר - והדבר הראשון שאתם רואים למטה זה Cookie Privacy Statement, שאתם צריכים לעשות Accept, נגיד . . .אז נניח שעשיתם Accept - קופץ לכם Pop-up מלמעלה: של “האם אפשר לשלוח נוטיפיקציות (Notifications)?” . . . . נגיד “לא” . . . אתם אומרים No Thanks, תודה . . . ואז קופצת עוד Pop-up: “אני רוצה להראות לך נוטיפיקציות!” - ושוב אתה אומר “לא!”ואז קופץ עוד Pop-up - “תעשה לי בבקשה Subscribe ל-Newsletter!”אתם לוחצים “No Thanks” - ואז אתם מגלים ש-”!Ad-block detected”, ואתם עושים “OK” . . . בקיצור - שורה של Pop-Ups על Pop-Ups על Pop-Ups . . . . ככה פחות או יותר נראים הרבה מאוד אתרים היום באינטרנט, למרבה העצב.וגם כשאתם רוצים לעזוב - אז קופץ לכם Pop-up “האם אתם באמת רוצים לעזוב את האתר הזה?!” . . . שזה טריק ידוע וישן שמשוחזר פה.אז כן - קצת רטרוספקטיבה על איך נראה האינטרנט נכון להיום, רטרוספקטיבה אולי קצת עצובה אבל אני חושב שמשקפת נאמנה הרבה מהאתרים של היום . . . האייטם הבא שבחרתי להציג - האמת היא שהוא לא חדש, אבל הרבה זמן לא עשינו Bumpers וזה לא הוצג פה [היה לינק באחד הרפרנסים למיטבי לכת …] - זה סרטון נחמד שצילמו אצלי בחברה ב-AppsFlyer, שנקרא “אז שכרנו הד האנטר. פחות הצליח” . . . https://www.youtube.com/watch?v=FTak4_SDxUA&סרטון הומוריסטי - אני מזמין אתכם לבוא ולראות אותו.כנראה שכבר ראיתם - אבל אם לא אז לכו תראו: חמש דקות של כיף, של צחוק על קהילת ההיי-טק, קהילת פיתוח התוכנה בישראל.על איך נראה הד-האנטר של פעם בעולם של היום.לכו תראו - נחמד, ב-YouTube, ב-Facebook, בכל מקום שתרצו - אני אשים כמובן את הקישור.(דותן) זה נראה לי שזה ה-Head Hunter של העתיד . . . (רן) של העתיד?(דותן) נראה לי שזה יגיע לשם בסוף . . . (רן) כן . . . בקיצור - משעשע, גם למי שלא ב . . (אלון) יש חברות שכבר שם . . . (רן) גם מי שדרך אגב . . . . גם אשתי ראתה וגם הילדות שלי ראו - ואת כולם זה הצחיק, זאת אומרת שיש פה הומור שמדבר לכל גיל ולכל מקצוע.עשוי היטב, הפקה יפה - לכו תראו.אייטם הבא - טוויט נחמד, או ציטוט נחמד שמצאתי ב-Twitter, אני אקריא לכם:"Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why." – Unknownאז משעשע . . . זה נמצא ב-Twitter של CodeWisdom@, זה שם החשבון, CodeWisdom@ [זה ה-Handler, השם הוא Programming Wisdom], אז יש שם עוד כמה כאלה משעשעים . . . ונעבור לאייטם הבא ב-Twitter - גם הוא דרך איזשהו חשבון וירטואלי משעשע של מפתחים שנקרא I am Programmer, I have no life - והציטוט הבא מגיע [גם] משם:“When someone ask you what programming language they should learn, don't simply answer the one you prefer. First - ask them what area they plan to focus on. For example:webfrontend: JavaScriptbackend: JavaScriptmobile apps: JavaScriptgames: JavaScriptai: JavaScript”[ובעברית]זהו, אז זה סוף ה-Quote הזה . . . (אלון) אני לא יודע אם זה מצחיק או עצוב . . . (רן) כן, אני מניח שאצל דותן תעשה Find-Replace ל-Rust, בסדר . . . ואלון - אתה רשאי לבחור ב-Go . . . ונעבור לאייטם הבא . . .אז אחד מה-Release notes - אתם יודעים, כל פעם שמשחררים אפליקציה ל-App-store, צריך לכתוב ככה Release Notes - אז Slack, באחד מה-Release Notes האחרונים שלהם, כתבו ככה: What's New - מה חדש ב-release האחרון של Slack ל-AppStore - אז ככה הם כותבים:“How's everybody doing out there? Are you getting enough sleep? Drinking enough water? Eating some vegetables here and there? . . . “וכו' וכו' -בקיצור: “לא היה לנו מה לכתוב, אז שיהיה לכם יום טוב - באהבה, ביי . . . .”אז כן - אז Release Notes משעשעים, לא תמיד צריך לכתוב את מספר הבאגים שתוקנו, אם אין לכם שום דבר מעניין . . . (דותן) אה - זה אמיתי! . . . (רן) זה אמיתי . . . לגמרי אמיתי, מלפני כמה שבועות [זה Slack 21.07.20] . . . נחמדחברה שהיא Corporate כבר לא קטן, באים וככה מכניסים איזשהו Easter egg כזה חמודטוב - האייטם הבא, לדעתי נתרם ע”י אלון, נכון? שלחת לנו את זה פה ב-WhatsApp . . . (אלון) זה היה ע”י זהר [זהר!] - (רן) אה, אז תודה זהר!למעשה, אני לא יודע אם זו בדיחה או משהו אמיתי, אבל זה איזשהו מועמד לתפקיד, ששלח איזשהו תיאור של היכולות שלו, והוא כותב:לנציגי ה-HR בחברה, הוא כותב להם “הנה - זה מה שאני מציע בתור עובד”: עלות חודשית - כך-וכך $; שעות בשבוע - 40 שעות בשבוע; Emails per week - 400; קפה, או הפסקות קפה או תה - 3; Overtime - . . . “בקיצור - הוא נותן איזשהו Spec של של עצמו, והכותרת של זה היא EaaS, כלומר: Employee as a Service . . . אז זה מה שהוא מציע ב-Spec שלו . . .עכשיו, לא בטוח . . . אני לא לגמרי הבנתי עד כמה זה רציני או “בדיחתי” . . . כי יש פה איזשהו נופך של 1 באפריל, שזה יכול להיות גם וגם . . . בכל אופן - זה יותר משעשע, של Employee as a Service ואיזשהו Spec שלו, כמו Spec של instance ב-EC2 . . . (דותן) זו, דרך התשובה, להד-האנטרים של העתיד . . . (רן) לגמרי . . . הנה, סגרנו פה מעגל, טוב . . . והאייטם הבא, גם הוא הגיע אלינו מאיפשהו ב-Twitter, התפרסם בימים האחרונים ב-Twitter של מי-אם-לא דובר צה”ל . . . .אז למעשה דובר צה”ל, או IDF@, אולי אפילו לא הדובר [זה ה-Official IDF Twitter…], מפרסמים חתיכת קוד, שנראית ככה כמו ב-#C לדעתי, של קוד שאומר ככה:“if (Hamas.IsAttacking){if (Hammas.Attacks.Contains(“rockets”) && Hammas.Attacks.Contains(“arson balloons”) && Hammas.Attacks.Contains (“violent riots”)){Terroism = true;RegionStability = false;Israel.Defend();“https://twitter.com/idf/status/1437433437439369217עכשיו נפרש . . . איך נפרש את הדבר הזה? . . . (דותן) קודם כל, הם היו צריכים לדאוג לזה, לפקטור “המפתח הציני” - שזה לא מתקמפל, ושזו השורה הראשונה בקובץ, וזה שאין פה בכלל פונקציה מעל זה, ושמות משתנים שמתחילים באות גדולה ומלא מלא בלגן קורה פה בקוד . . . (רן) אז בוא נסתכל על שני הצדדים - על החצי המלא והחצי הריק של הכוס:(1) - נחמד שניסו לתקשר לעולם בצורה של קוד, בצורה שהיא קצת גיקיתאבל (2) - אם אתם רוצים להיות רציניים, בואו נעשה באמת - כמו שדותן אמר - משהו שבאמת נקרא, שגיקים מצליחים לקרוא, לקמפל להם בראש - ולא לקבל התקף חרדה של “אם אלה האנשים שכותבים ב-IDF, אז ככה נראה המצב . . . .”[מה שבר-זיק אמר . . . ](דותן) אה, אתה אומר שזה משליך . . . לא חשבתי על זה . . . (רן) כן, אז Twitter היה מלא בתגובות של “חבר'ה, רבותיי - בואו, אולי כדי שלא נראה איך נראה הקוד שלנו, כדי שלא לעודד את החמאס או אחרים . . . “אז זה נחמד, ניסיון יפה - אבל מצד שני, מישהו היה צריך לעשות לזה Code Review לפני שזה פורסם ב-Twitter.(אלון) “שבר את הרשת”, כמו שאומרים . . . (רן) “שבר את הרשת” . . . בהחלט . . .ואלון - יש לך גם כמה אייטמים קטנים - בבקשה: כן - אז נמשיך עם Twitter: מישהו העלה תמונות, באמצעות נייר טואלט, כדי להסביר מה זה Non-Zero Value, 0, NULL ו-Undefined ב-JavaScripthttps://twitter.com/jaypeedevlin/status/1425513599515168772אז Non-Zero Value זה כשיש לך נייר טואלט, ואפס זה כשהגליל ריק - ו-NULL זה כשאין גליל . . .ו-Undefined זה כשאין גם מתקן לגליל . . . .זו ההגדרה - וזו תמונה חמודה ומשעשעת, זהועוד משהו - יש את ה-Extension ל-Terminal שדיברנו עליו פעם, בשם .FIG(רן) התקנתי אותו, דרך אגב . . . (אלון) הוא מדהים . . . הוא מדהים(רן) קצת מעצבן אותי . . . קצת מעצבן - הוא נחמד ויפה והכל, אבל קצת מעצבן . . . כל הזמן קופץ, קצת מעיק לדעתי . . .(אלון) אמרתי שהוא מגניב - למה אתה הורס לי? כאילו, אני לא מבין - בנאדם בא ואומר “מגניב” ו . . . (רן) אבל אני עדיין משתמש, הוא יפה . . . (אלון) או - תודה! אני מבקש רן - תוריד את זה בעריכה, באמת [לא קרה . . . ](רן) הוא מגניב, אמרתי כבר שהוא מגניב?(אלון) כן, אמרנו שהוא מגניב, יופי . . . אני לא מאמין, אתה סותר אותי מול הילדים

Un épisode de rentrée en format "news". Nous revenons sur les annonces qui ont eu lieu durant l'été 2021. GitHub Copilot Du pair coding avec une AI ! Principalement disponible sur VSCode, GitHub Copilot est une assistance formée sur des milliards de lignes de code public. Elle complète votre code au fur et à mesure que vous écrivez. Elle apprend en analysant votre code et vous suggère la complétion de votre code. Vous êtes libre d'accepter ou non la suggestion. Encore en version technical preview, vous pouvez l'essayer en allant sur cette page : https://copilot.github.com/ GitHub Dev Passer en mode “édition” grâce avec la touche "." ! Quand vous êtes dans un repository sur github.com, il vous suffit d'appuyer sur la touche "." de votre clavier pour passer sur github.dev et éditer le projet sur un VSCode en ligne. Vous pouvez importer vos settings et travailler comme si vous étiez dans votre VSCode installé sur votre ordinateur. Les notes de cet épisode sont créées directement sur github.dev Alpine JS 3 La version de la maturité ! Fin mai, c'est déroulé l'alpine day. https://alpineday.com/watch.Nous vous recommandons de visionner les différentes présentations. Suite à ça, la version 3 d'AlpineJS est sortie. Dans la foulée, un nouveau site et une nouvelle documentation. Petite Vue WTF Evan ! Quand Evan You fait un side project, ça donne petite-vue. Directement inspiré d'AlpineJS, petite vue (avec l'accent) est une petite librairie qui pèse seulement 6Kb. Une grosse majorité des méthodes provenant de VueJS sont disponibles. Elle permet de créer des éléments interactifs dans une page web sans devoir installer une plus grosse librairie. Vue 3 La bêta que l'on utilise tous en prod ! La version 3.2 vient de sortir avec des nouveautés et des grosses améliorations de performance. Lire ici le post de la version 3.2 : https://blog.vuejs.org/posts/vue-3.2.html Nuxt 3 Plus c'est long, plus c'est bon ! La version 3.2 vient de sortir avec des nouveautés et L'attente est longue, mais le travail est immense pour l'équipe de Nuxt Lab. La conf Nuxt Nation vient de passer avec une présentation et la timeline du travail pour sortir la version 3 de Nuxt. La première version bêta publique est annoncée pour le 12 octobre 2021. Le travail est immense pour l'équipe, car en plus de réécrire totalement la version 3 en TypeScript, il faut maintenir la version 2 et sortir des nouveaux modules. À l'image de Nuxt Image sorite courant juin 2021 ! En quelques lignes, la version 3 de Nuxt, c'est : Compatible Vue 3 Très compatible avec TypeScript (comme Vue 3) Un nouveau moteur Nitro, très performant et capable de faire de l'incrémentale. Un bundle de prod hyper performant et cross plateforme. Strapi 4 On reprend tout depuis le début ! La version 4 de Strapi est en développement. Une grosse majorité de fonctionnalités est repensée. Voici les principales évolutions : Nouvelle interface d'admin Nouveau système de plugin Nouveau Database Layer Nouvelle API REST et GraphQL Système de migration Système de hook pour étendre Strapi Au-delà de la version 4, Strapi a annoncé un changement de pricing : https://strapi.io/blog/introducing-user-based-pricing-for-strapi-enterprise-edition Astro JS Faire l'inverse des autres ! Astro est un générateur de site statique qui par défaut, ne met aucun JavaScript dans le navigateur. Vous pouvez développer vos templates avec le langage ".astro" mais aussi avec vos frameworks JS préférés : lit, Vue, React, Preact, Svelte ou Solid. Astro compile sans problème avec plusieurs frameworks. En cas d'utilisation d'un component créé avec Vue par exemple, il est rendu par défaut sans interaction, juste en HTML. Ensuite, vous pouvez choisir différents modes d'hydratation pour le rendre interactif : load, visible, idle, only. Il gère également tous les assets (css, etc.). Encore en version bêta, il semble très prometteur. Outil recommandé Fig Podcast présenté par : Alexandre Duval @xlanex6 Patrick Faramaz @PatrickFaramaz

Today’s automotive safety systems are designed to either avoid or respond to collisions. PreAct Technologies, a startup in cohort 4 of the Luminate accelerator, is focused on detecting car crashes […]

  Today’s automotive safety systems are designed to either avoid or respond to collisions. PreAct Technologies, a startup in cohort 4 of the Luminate accelerator, is focused on detecting car crashes before they happen, enabling various safety measures to engage in a matter of milliseconds. Founder and CEO Paul Drysch shares how PreAct’s technology can […]

Vanessa und Peter hatten zwei Open-Source-Schwergewichte zu Gast, mit denen sie über das (Über)-Leben als OSS-Entwickler plauderten. Martin Donath (Twitter, Github) war zuletzt in Revision 484 zu CSS und stylezen zu Gast und entwickelt Material for MkDocs. Marvin Hagemeister (Webseite, Twitter, Github) ist für seine Arbeit an Preact bekannt und war genau zu diesem Thema […]

Sam Carow is the co-founder and CTO of DwellWell. She's spent the majority of her career in startups, from Preact (acquired by Spotify in 2016) to Reddit, and is now using her engineering prowess and leadership to bring the homebuying process into the 21st century with DwellWell. Sam is passionate about diversifying the tech ecosystem through inclusive hiring and training, and has successfully developed internal training programs to elevate underrepresented groups, achieving the goal of increasing visibility and salaries of program participants. She is a leader in the women in tech space, and has spoken at the Grace Hopper Celebration and Women in Tech Summit. She strives to build an equitable, empathetic, and results-driven engineering culture. Blog post mentioned in podcast: https://elpha.com/posts/euvqpy7t/from-waitress-to-cto-in-9-years?v1=r03 (https://elpha.com/posts/euvqpy7t/from-waitress-to-cto-in-9-years?v1=r03) DwellWell Socials LinkedIn (personal) - https://www.linkedin.com/in/samanthacarow/ (https://www.linkedin.com/in/samanthacarow/) Twitter (personal) - https://twitter.com/samcarow (https://twitter.com/samcarow) IG (company) - https://www.instagram.com/dwellwell_/ (https://www.instagram.com/dwellwell_/) Company Info Website: https://dwellwell.com/ (https://dwellwell.com) (in beta) DwellWell is on a mission to create a better homebuying experience for first-time buyers. Basically, buying a house sucks — you're dragged through an opaque process, uneducated and confused, by an agent you don't even know if you can trust. DwellWell aims to solve this problem by building a platform that educates homebuyers on what they need to know before connecting them with an agent. Based on your needs we can connect you to the best agents in your area and you can meet with them as an equal. Agents on the DwellWell platform can now speed up their lead-to-close ratio by working with high-intent buyers, and reduce the burden of being the sole educator in the process. With DwellWell, agents can get back to the work of actually closing deals. Hiring DwellWell is hiring: - Frontend Engineer https://www.linkedin.com/jobs/view/2579854365 (https://www.linkedin.com/jobs/view/2579854365) - Business Development Rep (SDR) https://www.linkedin.com/jobs/view/2581880114 (https://www.linkedin.com/jobs/view/2581880114) -- CONNECT WITH THE WILD FEATHER -- Website: https://www.thewildfeatherpodcast.com Instagram: https://www.instagram.com/thewildfeatherpodcast Twitter: https://twitter.com/thewildfeather_ Facebook: https://www.facebook.com/thewildfeatherpodcast LinkedIn: https://www.linkedin.com/company/thewildfeatherpodcast

Ben interviews Cristian Bote, creator of goober (a less than 1KB CSS-in-JS solution). Cristian is also a member of the Preact core team. Unsurprisingly, they talk about Preact, goober, and WMR (a tiny all-in-one development tool for modern web apps). Links https://twitter.com/cristianbote_ (https://twitter.com/cristianbote_) https://cristianbote.com (https://cristianbote.com) https://github.com/cristianbote/goober (https://github.com/cristianbote/goober) https://goober.js.org (https://goober.js.org) https://goober.rocks (https://goober.rocks) https://styled-components.com (https://styled-components.com) https://emotion.sh/docs/introduction (https://emotion.sh/docs/introduction) https://github.com/preactjs/preact (https://github.com/preactjs/preact) https://preactjs.com (https://preactjs.com) https://twitter.com/preactjs (https://twitter.com/preactjs) https://github.com/preactjs/wmr (https://github.com/preactjs/wmr) Contact us https://podrocket.logrocket.com/contact-us @LogRocket (https://twitter.com/LogRocket) brian@logrocket.com What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr). Special Guest: Cristian Bote.

Hey folks, so today I want to tell you about ES. Build so if you haven't heard of ES. Build it's been making a lot of noise recently. I think it's I I didn't check but I think it's been around for at least a year. I think is the first time I heard of it. But basically, it is kind of you you can think of it as a bundler like webpack but written and go and apparently go as much better suited for bundler tasks because it is wicked fast. Like I've tried it myself and you think that it's broken.Because it's so fast like you think it just didn't run and because you execute ES build and it's instantly done. It's it's outrageously cool. And so it's starting to take over I've noticed in lots of different areas like the new meta frameworks that I'm seeing are using ES build bite the the view meta framework tool. I think it's like gonna be the new view CLI or something eventually but it's powered by ES build Remix, they're currently working on moving over to ES build. I I'm using ES Build in MDX Bundler and a couple of the like newer smaller things like from Jason Miller the creator of Preact he's using ES build for his thing WMR or something. I think is what is called um, but yeah, it's just like oh and there's a new testing firmware called UVU that is using ES. Build under the hood to just be just outrageously fast. For compiling typescript and everything. The only downside to using ES build currently that I can see is there's,No support for custom babble plugins which is a shame but these days I don't really use custom babble plugins for anything other than like code transformations like like code gen or prevalent and these are macros and I'm thinking we may be able to make a macros sort of plug-in thing that works with ES build. So that's that's something I still need to investigate but and I think some people have tried some experiments to make Babel work with the US build but when you start doing that stuff, you kind of negate all of the benefits.The performance benefits of ease build because then you have to do AST compilation in node again and yeah that can be slow. So anyway, if you haven't looked into ES build yet. I'm not telling you that you need to take your work application and and migrate everything from webpack over to ES build, but it is pretty powerful and it's something to keep an eye out for and there are other things. I think there was one like SWC or something like that, that's written in rest. But yeah, it's exciting times and I thought I'd just share that with you. Hope you have an awesome day. We'll,Talk to you later.

Jørgen og Ole Petter møter utviklerne Jarle Grivi Brenna og Mads Erik Forberg, for å snakke om hvordan de leverer raske forsider med PHP, artikler med React, koronatall i Preact - og hvorfor de er så ivrige på at du skal logge inn. ★ Support this podcast on Patreon ★See omnystudio.com/listener for privacy information.

In this episode of the top-10-most-popular-JavaScript podcast, Jake and Surma chat about:   Using our blogs to experiment with build systems. Jake's → http://goo.gle/3pi4sL5 Surma's → http://goo.gle/39dg8sK 11ty → https://www.11ty.dev/ Jake's static build → http://goo.gle/2Mi7254 Hydrated components in Jake's posts → http://goo.gle/3a0DOjt And where those are processed → http://goo.gle/36c8qgB Surma's dithering post → http://goo.gle/3c8c8f2   Cats and laser pens Dogs and teeth Improving the safety of Jedi training   The old _blank behaviour → http://goo.gle/3ojucoS The spec change → http://goo.gle/2YednBo The browsing context → http://goo.gle/2M5R0vf Cross-origin-opener-policy → http://goo.gle/2Mi7kZI window.open → http://goo.gle/3cfBPup Back/forward cache → https://web.dev/bfcache/   Old blocks proposal → http://goo.gle/2M4SeqL New blocks proposal → http://goo.gle/2Yd7iVK   Lockdown dreams Lottery fail → https://goo.gle/2M1EgpA

#024 - On this episode, we continue uncovering the steps every high school junior should take to succeed in the college admission process. We go over one of the most important components of the college application, scores from the standardized test. This is one of the 3 kings of the college admission process, the other two being the courses students take in high school and the grades they receive in those courses. We highlight the different elements that make up the SAT and the ACT, the two standardized tests generally accepted by universities and colleges. We also talk about the differences between the two tests, and the advantages students can gain from those differences. One of the biggest differences is in the math section, with one exam having half the number of questions, whose level of complexity does not exceed math problems found in an Algebra II high school course. We also talk about whether standardized exams will be permanently eliminated from the college admission process, and the one thing every student in high school should be afraid of when getting ready to take the SAT or the ACT. Here is a hint. It has nothing to do with the exams themselves. You can find the show notes for this episode at https://collegemetropolis.com/24. You can also help us a lot by writing a positive review for our show and leaving us a 5-star rating. In doing so, you will make it easier for other parents to find our show. Thank you!

Preact creator Jason Miller joins Jerod and Nick to discuss WMR– the tiny all-in-one development tool for modern web apps. We ask Jason what “modern web app” means, how WMR fits in to the JS tooling landscape, why the Preact team created it in the first place, and dig into all it has to offer. Where’s My Roomba?

Preact creator Jason Miller joins Jerod and Nick to discuss WMR– the tiny all-in-one development tool for modern web apps. We ask Jason what “modern web app” means, how WMR fits in to the JS tooling landscape, why the Preact team created it in the first place, and dig into all it has to offer. Where’s My Roomba?

https://codingcat.dev/podcasts/1-5-mdx-with-chris-biscardi/ Chris Biscardi Links https://twitter.com/chrisbiscardi http://www.christopherbiscardi.com/ https://www.linkedin.com/in/christopherbiscardi/ github.com/ChristopherBiscardi http://stackoverflow.com/users/740600/chris-biscardi Who is Chris Biscardi? Chris teaches people how to write Rust, work with Serverlesss, and take advantage of the Jamstack. He is an independent consultant with two major products (Toast and Sector) whose talks can be viewed at a variety of conferences such as qcon, gophercon, and more. Chris runs the Party Corgi Network, a community of practice and is an MDX maintainer. I consult in two main areas: * Building teams around specific initiatives (such as building a Design System team). * Applying modern and emerging technologies (GraphQL, CSS-in-JS, K8s/Containerization, JAMStack/GatsbyJS, React) using mainly Golang and JavaScript. What is MDX? https://mdxjs.com/ Markdown for the component era MDX is an authorable format that lets you seamlessly write JSX in your Markdown documents. You can import components, such as interactive charts or alerts, and embed them within your content. This makes writing long-form content with components a blast

In this podcast Tracy Lee (@ladyleet), Hunter Miller (@hmillerdev), and Ben Lesh (@benlesh) interview Jason Miller (@_developit), creator and core team member of Preact about Preact - its conception, where it's at today, who's using it, and what's coming up for the library. We also ask Jason about how being on the Google Chrome team has impacted the direction of Preact, and about his current project at Google, ModernJS.   Guests: Jason Miller (@_developit) - Creator & Core Team Member, Preact | DevRel, Google    Hosts: Tracy Lee (@ladyleet) - CEO, This Dot Labs Ben Lesh (@benlesh) - Software Engineer at Citadel & Author of RxJS Hunter Miller (@hmillerdev) - Software Engineer, This Dot Labs   This episode is sponsored by This Dot Labs. 

This is the second part of our discussion with Dr Anna Kavoura on how gender informs meaning in sport. In the first part, we explored Anna’s work on intersecting identities in women’s martial arts, as well as her current research project titled "Transforming Gender Boundaries in Sport: An Ethnographic and Participatory Action Research Study in Trans-Inclusive Sport Contexts”.This episode continues our discussion exploring the dominant gender discourses in sport context and what can be done to challenge them. We also discuss the dilemma of women-only training groups in martial arts. While these groups can be useful for attracting more women to male-dominated martial arts gyms, there are some possible problems with them such as reinforcing the gender binary and hierarchical understandings of gender. What are the ways we can use this strategy well?   Dr Anna Kavoura has completed several interesting research projects on gender in sport. She completed her PhD in Sport Sciences at the Univerity of Jyväskylä in Finland, which focused on understanding women’s identity negotiations in competitive judo cultures in Greece and Finland. After defending her PhD, she continued working as a postdoctoral researcher at University of Jyväskylä in the PREACT project which focuses on tackling discrimination against gender and sexual minorities in sport and physical education contexts (PI: Dr Marja Kokkonen). She then moved to the School of Sport and Service Management at the University of Brighton and works as a postdoctoral researcher in the "Transforming Gender Boundaries in Sport" project which is funded by the Finnish Cultural Foundation.

In today's episode, I talk about vanilla JS performance, and working with code at scale. Links Zach Leatherman about HTML vs. JS performance: https://twitter.com/zachleat/status/1169998370041208832 Jeremy Wagner’s research on React vs. Preact vs. Vanilla JS performance: https://css-tricks.com/radeventlistener-a-tale-of-client-side-framework-performance/

This is Bacchis. And this is her sister Bacchis. Confused yet? To join the discussion, visit the blog at Triumvir Clio's School of Classical Civilization. If there's no hyperlink showing up here, you can go to triumvirclio.school.blog to find a feed of recent episodes as well as discussion pages for every episode. References Parker, Douglass, translator. “Appendix 1: A Note on the PreAct of The Wild, Wild Women.” Five Comedies, Hackett Publishing Company, Inc., 1999, pp. 406-7. Parker, Douglass, translator. “Appendix 2: A Supplementary Prologue to The Wild, Wild Women.” Five Comedies, Hackett Publishing Company, Inc., 1999, pp. 408-11. Parker, Douglass, translator. “The Wild, Wild Women [Plautus's Bacchides].” Five Comedies, Hackett Publishing Company, Inc., 1999, pp. 185-294. --- Send in a voice message: https://anchor.fm/bethany-banner/message Support this podcast: https://anchor.fm/bethany-banner/support

Don't overreact to Week 1. Don't wait to react to Week 2. PREact with Next Week Tonight. --- Support this podcast: https://anchor.fm/fusionffb/support

Fredrik chats with Sara Vieira about The Opinionated Guide to React - the guide to making all the choices React doesn’t make for you (plus hooks). We talk about the magic train ride from Prague which led to the creation of the book, what the writing and publication process was like, and of course about the surprising and horrific code Sara uses to create the final book files. We also discuss MC:ing conferences, what happens when world events explode all over your writing, finding your voice, and making the most of your Grammarly plan. 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 Sara Sara on Github Entertaining talk about making good buttons (and more) The Opinionated Guide to React - Sara’s book Codesandbox Codepen Glitch Hooks in React Class components React state management Overmind Christian Alfoni - creator of Overmind Vue Styled components Emotion Reach router React router Preact Ryan Florence Blender Photo of girl giving a police officer flowers and being arrested The Carnation Revolution - the end of the Portugese dictatorship This is fine - the meme and plushie Grammarly Full stack fest Markdown Gatsby Puppeteer - for scraping web pages, and more Pdflib Epub Calibre Mobi files Paddle Gatsby-starter-book Prism VS code theme to Prism theme converter VAT Stripe GDPR Cheerio Product hunt Cypress useMemo Sitges Rust React Amsterdam Titles It’s like sad Spanish I make buttons Goth Glitch I finished something The stress doesn’t end On a train from Prague Also kind of European Apparently I started this on Christmas It depends Why it depends I don’t think that’s an answer Thank you for not calling it “React Best Practises” March never ended I can only write like I speak I’m not school-smart yarn generate book A very dirty Javascript function A different type of terrifying All of a sudden, nothing’s scary anymore “I think this thing has a computer” It was the worst visa

(September 4, 2019) Developing for the global web is so much more than just translating content into multiple languages. In this episode of the State of the Web, Rick Viscomi (Developer Programs Engineer at Google) sits down with Andrey Sitnik (Lead Frontend Engineer at Evil Martians) to talk about considerations for globalization and the tools available to web developers. For more info about everything discussed in this video, check out the original video→ https://goo.gle/2Z5dYq6

Sponsored By: Show Notes [00:01:08] Evan tells us what’s the deal with Vite. [00:08:01] Evan explains Hot Module Replacement from a practical standpoint. He tells us there are a few different ways to handle it. [00:10:08] Tessa mentions reading a piece Evan wrote in Increment Magazine about the way Vue 3 re-renders things. She was wondering if working through those problems is what inspired Vite and Vite Press or if he just makes new projects like those every couple of years. [00:15:47] Evan tells us how he made the decision to go with Rollup putting together Vite, and what that was like versus Webpack. Also, Ben wants to know if there would be a path forward where developers could use Vite in their development experience? [00:21:43] React and Preact are discussed here by Evan. [00:25:10] Tessa wants to know if there are any features that Evan wishes Vite had right now but doesn’t yet, and he explains a few. [00:27:06] Tessa asks Evan, thinking about the first user experience, when people go to Vue docs and they have you import the script file and you make your first component in line JavaScript, do you think that might be replaced by spinning up the Vite app in the future? [00:31:05] Ben asks Evan since he currently uses VuePress and loves it, does he have any ideas, roadmap wise, whether you see it as the replacement as a VuePress 2.0 or would they live side by side? [00:40:43] Evan talks more about the process of idea generation and how he creates new things. Tessa has an amazing metaphor at the end, according to Ari ☺ Sponsor: Linode (https://promo.linode.com/vue/) Picks of the week: [00:45:35] Ari has two music picks: “The Lord is Out of Control” by Mogwai and “Atlas” by Battles. [00:46:02] Ben has three picks: He converted to Miro, second pick is Remo.co, and third pick is Nuxt Content module. [00:47:49] Evan’s pick is Increment Magazine. He has an article in it called, “Making Vue 3.” [00:48:53] Tessa has three picks: An article called, “Pink Collar” by Jennifer Pan (Emotional and Passion Work), second pick is a book called, How to Take Smart Notes by Sönke Ahrens, and third pick is an instrument called a Melodica/Pianica. Resources mentioned: Evan You Twitter (https://twitter.com/youyuxi) Evan You GitHub (https://github.com/yyx990803) Evan You Blog (https://evanyou.me/) Vite GitHub Repo (https://github.com/vitejs/vite) VitePress GitHub Repo (https://github.com/vitejs/vitepress) “The Lord is Out of Control” by Mogwai (https://www.youtube.com/watch?v=KbwIFzxD1-w) “Atlas” by Battles (https://www.youtube.com/watch?v=lBlVeieFqKc) Miro (https://miro.com/) Remo.co (https://remo.co/) Nuxt Content (https://content.nuxtjs.org/) Increment Magazine (https://increment.com/) “Making Vue 3” by Evan You (https://increment.com/frontend/making-vue-3/) “Pink Collar” by Jennifer Pan (https://jacobinmag.com/2014/06/pink-collar) How to Take Smart Notes by Sönke Ahrens (https://bookshop.org/books/how-to-take-smart-notes-one-simple-technique-to-boost-writing-learning-and-thinking-for-students-academics-and-nonfiction-book-writers/9781542866507) Melodica (https://en.wikipedia.org/wiki/Melodica) Special Guest: Evan You.

In today's episode, I talk about web performance, and whether or not web apps should be held to different standards than traditional websites. Links “The Cost of JavaScript Frameworks” by Tim Kadlec: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/ ReefJS: https://reefjs.com/ Preact: https://preactjs.com/ Svelte: http://svelte.dev/ Maintainable CSS: https://maintainablecss.com/ Inlining literally everything for better performance: https://gomakethings.com/inlining-literally-everything-for-better-performance/

Jake injured himself playing games. Jake also has a stupid cat. By the way, skip to 22 mins if you don't care about all that. Writing a Countdown solver → https://goo.gle/2SkHtk2  Here's the game show → https://goo.gle/3bPo1DM  Here's the C++ solution → https://goo.gle/2VRzoFP  Jake's unappreciated audio blog post → https://goo.gle/2VNmOqZ  HTM (JSX alternative) → https://goo.gle/3cYr9x7  Preact hooks → https://goo.gle/3aMP15p  ComLink → https://goo.gle/2VLcr6V  Throwing non-errors. Guide to promises → https://goo.gle/2VOuCc8  Gotchas with typeOf. isNaN vs Number.isNaN.   See https://goo.gle/HTTP203Podcast for other episodes.

In this episode of GeeksBlabla we discuss, React, How to get started ,Core concepts, React Ecosystem and a lot of topics around it. Guests Yassine ElOuafi Youssouf EL Azizi Amine Hakkou Notes 0:00 - Introduction and welcoming 0:05 - What is React? && React History. 0:09 - How is React different from other solution such as jquery/angular and Vuejs 0:19 - Imperative and Declarative in React? 0:22 - What do I need To know to start working with React? 0:31 - React Fundamental : JSX. 0:38 - Deference between JSX and template system. 0:41 - React Fundamental : Components, State, Props. 0:48 - React Patterns: HOC, render props, Compound components 0:52 - State Management Approaches. 1:03 - React and Typescript. 1:12 - Redux-saga vs Redux-thunk 1:14 - React Fiber, Virtual Dom, Reconciliation, concurrent mode. 1:34 - React Suspense && algebraic effects. 1:48 - Preact. 1:58 - WebAssembly and React. 2:04 - Styling in React. 2:08 - Server side Rendering with React. 2:12 - Meta-frameworks : Next.js / Gatsby. 2:25 - React Testing. 2:33 - Tools and Resources. Links React Yassine Blog Kent C. Dodds React Testing Library The Beginner's Guide to React Prepared and Presented by : Soufian El Foukahi Youssouf EL Azizi

This week on WPwatercooler we’re talking about the products and services we use on our latest projects. It’s WordPress Stuff we love, join us!Lead Generation and Sale Notification Popups for WordPress Stores – Holler Boxusefathom.comFathom Lite. Simple, privacy-focused website analytics. Built with Golang & Preact.What Is a Dickbar?Messenger Customer Chat – WordPress plugin | WordPress.orgSmallchat — Connect with your visitors.Site Kit by Google – WordPress plugin | WordPress.orgMessenger Customer Chat – WordPress plugin | WordPress.orgtemplates.gutenberghub.comTailwind UIGraphQL|A query language for your APIwpgraphql.comFathom Analytics Hosting|DigitalOcean Marketplace 1-Click AppFathom Analytics – WordPress plugin | WordPress.orgusefathom.com See acast.com/privacy for privacy and opt-out information.

Ward's Twitter https://www.partycorgi.com/ Party Corgi Discord Invite

A look back at the review of the PreACT for 9th and 10th grades and the PSAT for the 11th grader. Episode originally recorded 2018.We hope this episode will answer a lot of your questions on the tests and how you can use them.9th Grade Parents....reminder....the PreACT is written for 10th graders so please keep that in mind when you review the results.

Wir haben Marvin Hagemeister zu Gast und sprechen mit ihm über das Frontend-Framework Preact. Die von ihm und seinem internationalen Team entworfene Open Source JavaScript-Bibliothek verwendet die gleiche API wie React.js und zeichnet sich durch seine schlanke Größe von maximal 3 kB aus. In dieser Folge erzählt uns Marvin, wie das überhaupt möglich ist und erklärt, wie er es schafft, schnell und problemlos Abschnitte seines Codes zu löschen. Außerdem verrät er uns, wie es das Remote-Team von Preact meistert, sich über mehrere Landesgrenzen hinweg zu synchronisieren und gemeinsam an einem Strang zu ziehen.Dass Marvin jede Zeile seines Codes auswendig kennt, hat er am 12. Dezember 2019 auch in seinem Vortrag "The Art of Deleting Code" in unserem Büro in Bad Nauheim unter Beweis gestellt.Picks of the DayDennis: Loopback – ein virtuelles Audio InterfaceFabi: console.re – die Remote Javascript ConsoleMarvin: htm – rapid prototyping für React, Angular etc.Sebi: Unicode-Tastatur – für alle Unicode-Freaks unter euch, die häufig Sonderzeichen brauchen und jeden Code auswendig können.Schreibt uns!Schickt uns eure Themenwünsche und euer Feedback.podcast@programmier.barFolgt uns!Bleibt auf dem Laufenden über zukünftige Folgen und Meetups und beteiligt euch an Community-Diskussionen.TwitterInstagramFacebookBesucht uns!Erfahrt hier, wann das nächste Meetup in unserem Office in Bad Nauheim stattfindet.MeetupMusik: Hanimo

Carl Mungazi is a frontend developer at Limejump in London. He is a former journalist and switched to programming in 2016. Today the panel is discussing the benefits of reading source code. Carl began reading source code because he came into programming late and from a different field. His first project was with Mithril, and he read the source code and documentation to help him understand it. The panelists discuss how reading the source code has helped them and others to improve their coding. They compare reading and understanding source code to learning a foreign language, and discuss  different methods.  Carl gives some suggestions for reading source code effectively. He advises people to be patient and step through the code. Accept that you will probably take a wrong path at some point or another, but the more you read, the more you will see patterns in how libraries are structured. He also encourages listeners to approach the authors, as they are often happy to lend a hand. Reading source code is an active approach of stepping through, debugging, putting in break points, checking the stack, and so forth. It’s also important to do outside research.  Since he has been reading source code, Carl has come to prefer plain JavaScript and libraries with as little code as possible. The panel discusses the benefits of small, simple libraries. Carl gives examples of techniques that he learned from reading a library source code and how he applied it to his own coding style. Reading source code has made him more careful about mixing logic and UI, and now he separates them. He also is more confident in seeing a problem, going to a preexisting library, and just importing the fix for that problem rather than the whole library. Reading source code is really about understanding the code you use in your project. It may slow you down, but you’ll be thankful in the long term because it will help you solve future bugs more efficiently. Carl talks more about his debugging process. He still relies on a debugger, but reading a library helps you to see patterns and guess the output of a function. These patterns persist in other libraries as well. Once you can guess correctly what will happen, you go back to reading the code and find instances where the output is unexpected, and fix it. Carl’s closing thoughts are that through reading source code, he has learned that although code is used differently in each library, they are all written in the same language, and therefore interrelated. This gave him more confidence in reading code because they’re all fundamentally the same. When a bug is discovered, he encourages listeners to look at the source code before googling a solution.  Panelists AJ O’Neal Dan Shapir Steve Edwards Charles Max Wood Guest Carl Mungazi Sponsors Hasura.io  Sentry | Use the code “devchat” for $100 credit Adventures in Angular Links Mithril.js Preact Limejump Picks AJ O’Neal Zen of Python The Go Proverbs Go with Versions Link’s Awakening soundtrack Dan Shapir Programming Pearls book Lord of Light Steve Edwards Jabra Elite 65T Charles Max Wood Garth Brooks The Rocky movies Carl Mungazi Follow Carl @CarlMungazi and carlmungazi.com EcmaScript Spec HTML 5.2 Snarky Puppy

Carl Mungazi is a frontend developer at Limejump in London. He is a former journalist and switched to programming in 2016. Today the panel is discussing the benefits of reading source code. Carl began reading source code because he came into programming late and from a different field. His first project was with Mithril, and he read the source code and documentation to help him understand it. The panelists discuss how reading the source code has helped them and others to improve their coding. They compare reading and understanding source code to learning a foreign language, and discuss  different methods.  Carl gives some suggestions for reading source code effectively. He advises people to be patient and step through the code. Accept that you will probably take a wrong path at some point or another, but the more you read, the more you will see patterns in how libraries are structured. He also encourages listeners to approach the authors, as they are often happy to lend a hand. Reading source code is an active approach of stepping through, debugging, putting in break points, checking the stack, and so forth. It’s also important to do outside research.  Since he has been reading source code, Carl has come to prefer plain JavaScript and libraries with as little code as possible. The panel discusses the benefits of small, simple libraries. Carl gives examples of techniques that he learned from reading a library source code and how he applied it to his own coding style. Reading source code has made him more careful about mixing logic and UI, and now he separates them. He also is more confident in seeing a problem, going to a preexisting library, and just importing the fix for that problem rather than the whole library. Reading source code is really about understanding the code you use in your project. It may slow you down, but you’ll be thankful in the long term because it will help you solve future bugs more efficiently. Carl talks more about his debugging process. He still relies on a debugger, but reading a library helps you to see patterns and guess the output of a function. These patterns persist in other libraries as well. Once you can guess correctly what will happen, you go back to reading the code and find instances where the output is unexpected, and fix it. Carl’s closing thoughts are that through reading source code, he has learned that although code is used differently in each library, they are all written in the same language, and therefore interrelated. This gave him more confidence in reading code because they’re all fundamentally the same. When a bug is discovered, he encourages listeners to look at the source code before googling a solution.  Panelists AJ O’Neal Dan Shapir Steve Edwards Charles Max Wood Guest Carl Mungazi Sponsors Hasura.io  Sentry | Use the code “devchat” for $100 credit Adventures in Angular Links Mithril.js Preact Limejump Picks AJ O’Neal Zen of Python The Go Proverbs Go with Versions Link’s Awakening soundtrack Dan Shapir Programming Pearls book Lord of Light Steve Edwards Jabra Elite 65T Charles Max Wood Garth Brooks The Rocky movies Carl Mungazi Follow Carl @CarlMungazi and carlmungazi.com EcmaScript Spec HTML 5.2 Snarky Puppy

Carl Mungazi is a frontend developer at Limejump in London. He is a former journalist and switched to programming in 2016. Today the panel is discussing the benefits of reading source code. Carl began reading source code because he came into programming late and from a different field. His first project was with Mithril, and he read the source code and documentation to help him understand it. The panelists discuss how reading the source code has helped them and others to improve their coding. They compare reading and understanding source code to learning a foreign language, and discuss  different methods.  Carl gives some suggestions for reading source code effectively. He advises people to be patient and step through the code. Accept that you will probably take a wrong path at some point or another, but the more you read, the more you will see patterns in how libraries are structured. He also encourages listeners to approach the authors, as they are often happy to lend a hand. Reading source code is an active approach of stepping through, debugging, putting in break points, checking the stack, and so forth. It’s also important to do outside research.  Since he has been reading source code, Carl has come to prefer plain JavaScript and libraries with as little code as possible. The panel discusses the benefits of small, simple libraries. Carl gives examples of techniques that he learned from reading a library source code and how he applied it to his own coding style. Reading source code has made him more careful about mixing logic and UI, and now he separates them. He also is more confident in seeing a problem, going to a preexisting library, and just importing the fix for that problem rather than the whole library. Reading source code is really about understanding the code you use in your project. It may slow you down, but you’ll be thankful in the long term because it will help you solve future bugs more efficiently. Carl talks more about his debugging process. He still relies on a debugger, but reading a library helps you to see patterns and guess the output of a function. These patterns persist in other libraries as well. Once you can guess correctly what will happen, you go back to reading the code and find instances where the output is unexpected, and fix it. Carl’s closing thoughts are that through reading source code, he has learned that although code is used differently in each library, they are all written in the same language, and therefore interrelated. This gave him more confidence in reading code because they’re all fundamentally the same. When a bug is discovered, he encourages listeners to look at the source code before googling a solution.  Panelists AJ O’Neal Dan Shapir Steve Edwards Charles Max Wood Guest Carl Mungazi Sponsors Hasura.io  Sentry | Use the code “devchat” for $100 credit Adventures in Angular Links Mithril.js Preact Limejump Picks AJ O’Neal Zen of Python The Go Proverbs Go with Versions Link’s Awakening soundtrack Dan Shapir Programming Pearls book Lord of Light Steve Edwards Jabra Elite 65T Charles Max Wood Garth Brooks The Rocky movies Carl Mungazi Follow Carl @CarlMungazi and carlmungazi.com EcmaScript Spec HTML 5.2 Snarky Puppy

Az 51. adásban beszéltünk a dokumentáció fontosságáról, a lokális fejlesztői környezet egy parancssoros indításáról, az utility first CSS-ről és a Preact X-ről. Résztvevők: Edu Tibi Róka Tartalom: 00:00:32 – Firefox 00:30:55 – Naming conventions 00:36:58 – utility-first css 00:47:11 – Preact X Naming conventionsHow to Build Unique, Beautiful Websites with Tailwind CSSUtility-first CSS – You […]

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.6.5 Released, Ruby 2.7 adds Enumerator::Lazy#eager, Understanding Zeitwerk in Rails 6, Rails 6 adds ActiveSupport::ActionableError и Rails 6.1 adds HTTP Feature Policy Optimistic vs. Pessimistic locking in Rails, Visual Studio Code plugins for Ruby и RuboCop Meets Minitest Web TensorFlow 2.0 is now available!, Preact X, Building a CloudFront Cookie Dashboard и Creating custom JavaScript syntax with Babel Don’t Use JavaScript Variables Without Knowing Temporal Dead Zone, Keeping it simple with CSS that scales, Carbon - create and share beautiful images of your source code и SweetAlert2 - replacement for JavaScript’s popup boxes

Mit Code-Golf-Großmeister Marvin Hagemeister (Webseite, Twitter) hatten wir in dieser Revision das Vergnügen, das Warum und das Wie von Preact zu ergründen. SCHAUNOTIZEN [00:01:00] PREACT Preact (…

Mit Code-Golf-Großmeister Marvin Hagemeister (Webseite, Twitter) hatten wir in dieser Revision das Vergnügen, das Warum und das Wie von Preact zu ergründen. Schaunotizen [00:01:00] Preact Preact (Github) ist ein 3kb-Front-Framework mit einer React-artige API. Wegen des schon immer ausgezeichneten Supports für Server-Side-Rendering fand Marvin erst Interesse an Preact und dann uns seinen Weg in das […]

Episode Summary Today’s guest is Håkon Krogh, and the panel is discussing his talk on lightning fast SSR React apps given at React Amsterdam. He gives a brief overview and defines his use of the Uncanny Valley (called the Valley of Lies in his talk). In this instance, the Uncanny Valley in programming occurs when everything in a website or application looks great, but none of the buttons work or users simply can’t connect. This is especially common when users try to connect to a site or app with their cell phone rather than a computer. The panel discusses what can be done. It’s important to begin by measuring the lag in your applications. Designing the progressive loading experience first is suggested as a solution, as well as organizing what loads first and using React and HTML for different parts of the app. It’s important to realize that some tools don’t work in every situation. The panel talks about the merits of Next.js.  Next they talk about what kinds of applications require SSR that make the loading slow. They discuss the importance of SEO ratings and how it can affect your rank in a Google search. Services like Lighthouse can give you an SEO rating so that you can improve.  Håkon and the panel talk about other ways to improve on the Uncanny Valley. It’s important to make sure that users have a way to use your site even if they’re stuck in the Uncanny Valley. One way to do this is to provide fallbacks so that if your React isn’t working, the site is still usable. They discuss the merits of micro frontends, using SSR for only part of the app, and reducing bundle size. Unfortunately there is no silver bullet, so solutions will vary by what you’re building.  In spite of these setbacks, one of the great features of React is you don’t have to do everything in React. They discuss the emerging idea of shipping different JavaScript for different things and talk about some of the React-like alternatives available. Bridging the Uncanny Valley is vital because it is the reason many people are afraid of their computers, and a good user experience can make people gravitate towards your product. The show concludes with Håkon talking about things in the React community that are piquing his interest.  Panelists David Ceddia Thomas Aylott With special guest: Håkon Krogh Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan GitLab | Get 30% off tickets with the promo code: DEVCHATCOMMIT Links Håkon Krogh’s React Amsterdam talk Next.js SEO ratings Gatsby Lighthouse  Apollo GraphQL npm TypeScript Preact Inferno.js Follow DevChatTV on Facebook and Twitter Picks David Ceddia: FX microjs.com Thomas Aylott: Mindset by Carol Dwek Håkon Krogh: Bundlephobia 

Episode Summary Today’s guest is Håkon Krogh, and the panel is discussing his talk on lightning fast SSR React apps given at React Amsterdam. He gives a brief overview and defines his use of the Uncanny Valley (called the Valley of Lies in his talk). In this instance, the Uncanny Valley in programming occurs when everything in a website or application looks great, but none of the buttons work or users simply can’t connect. This is especially common when users try to connect to a site or app with their cell phone rather than a computer. The panel discusses what can be done. It’s important to begin by measuring the lag in your applications. Designing the progressive loading experience first is suggested as a solution, as well as organizing what loads first and using React and HTML for different parts of the app. It’s important to realize that some tools don’t work in every situation. The panel talks about the merits of Next.js.  Next they talk about what kinds of applications require SSR that make the loading slow. They discuss the importance of SEO ratings and how it can affect your rank in a Google search. Services like Lighthouse can give you an SEO rating so that you can improve.  Håkon and the panel talk about other ways to improve on the Uncanny Valley. It’s important to make sure that users have a way to use your site even if they’re stuck in the Uncanny Valley. One way to do this is to provide fallbacks so that if your React isn’t working, the site is still usable. They discuss the merits of micro frontends, using SSR for only part of the app, and reducing bundle size. Unfortunately there is no silver bullet, so solutions will vary by what you’re building.  In spite of these setbacks, one of the great features of React is you don’t have to do everything in React. They discuss the emerging idea of shipping different JavaScript for different things and talk about some of the React-like alternatives available. Bridging the Uncanny Valley is vital because it is the reason many people are afraid of their computers, and a good user experience can make people gravitate towards your product. The show concludes with Håkon talking about things in the React community that are piquing his interest.  Panelists David Ceddia Thomas Aylott With special guest: Håkon Krogh Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan GitLab | Get 30% off tickets with the promo code: DEVCHATCOMMIT Links Håkon Krogh’s React Amsterdam talk Next.js SEO ratings Gatsby Lighthouse  Apollo GraphQL npm TypeScript Preact Inferno.js Follow DevChatTV on Facebook and Twitter Picks David Ceddia: FX microjs.com Thomas Aylott: Mindset by Carol Dwek Håkon Krogh: Bundlephobia 

For the past few months, Futurice has been working together with Sanoma in creating a renewed voting advice application AKA "Vaalikone" for the 2019 Finnish parliamentary elections and the upcoming elections, such as the 2019 European Parliament election. In this presentation, we will share insights into the project and how we created a service that was used by a large part of the population with voting right. We came up with a neat solution for handling the peak load of 28M requests/hour during the election night. The UI was implemented using Preact with TypeScript.

For the past few months, Futurice has been working together with Sanoma in creating a renewed voting advice application AKA "Vaalikone" for the 2019 Finnish parliamentary elections and the upcoming elections, such as the 2019 European Parliament election. In this presentation, we will share insights into the project and how we created a service that was used by a large part of the population with voting right. We came up with a neat solution for handling the peak load of 28M requests/hour during the election night. The UI was implemented using Preact with TypeScript.

Tracy and Ben meet with three Preact Core team members to talk about the preact-cli, upcoming releases, and the general direction of this popular library. Hosts:Tracy Lee (@ladyleet) - This Dot Co-founder, GDE, RxJS Core teamBen Lesh (@benlesh) - Engineer at Google, Co-founder This Dot, RxJS Core team Guests:Jason Miller (@_developit) - Creator of @preactjs. Web DevRel at Google. Zouhir Chahoud (@_zouhir) - Technical Program Manager for Edge at MicrosoftPrateek Bhatnagar (@_prateekbh) - Works on Amp, User Experience Engineer at Google  

Panel: Charles Max Wood Guest: Henrik Joreteg This week on My JavaScript Story, Charles speaks with Henrik Joreteg. Henrik has been on JavaScript Jabber previously discussing &yet back in December of 2014 on episode 137. He has since then left &yet and now does independent consulting and works on his own projects. He first got into programming when he started a company that created online video tours for houses and he needed to teach himself programming in order to create the website. They talk about what led him to JavaScript, what he’s proud of contributing to the community, what he is working on now, and much more! In particular, we dive pretty deep on: JavaScript Jabber Episode 137 &yet How did you first get into programming? Liked computers as a child but didn’t want to spend his life on it originally Studied Business in college Create house touring video company Adobe ColdFusion How were you exposed to JavaScript? Gig as a ColdFusion developer jQTouch, jQuery, and Django Interested in building app-like experiences What have you done with JavaScript that you are proud of? Want to push the web into an app-like space Helped to create Ampersand.js Wrote Human JavaScript Created Simple WebRTC Promote web as an application platform What are you working on now? Redux and React New book: Human Redux Independent consulting Speedy.gift Redux-bundler And much, much more! Links: JavaScript Jabber Episode 137 JavaScript Jabber &yet JavaScript jQTouch jQuery Django Human JavaScript Ampersand.js Simple WebRTC Human Redux Redux React Speedy.gift Redux-bundler Henrik’s GitHub Joreteg.com @HenrikJoreteg Sponsors: Loot Crate FreshBooks Picks Charles Hogwarts Battle React Dev Summit JS Dev Summit Newspaper Theme on Themeforest Get a Coder Job Course Henrik Preact Parcel.js Rollup.js Space repetition systems Anki

Panel: Charles Max Wood Guest: Henrik Joreteg This week on My JavaScript Story, Charles speaks with Henrik Joreteg. Henrik has been on JavaScript Jabber previously discussing &yet back in December of 2014 on episode 137. He has since then left &yet and now does independent consulting and works on his own projects. He first got into programming when he started a company that created online video tours for houses and he needed to teach himself programming in order to create the website. They talk about what led him to JavaScript, what he’s proud of contributing to the community, what he is working on now, and much more! In particular, we dive pretty deep on: JavaScript Jabber Episode 137 &yet How did you first get into programming? Liked computers as a child but didn’t want to spend his life on it originally Studied Business in college Create house touring video company Adobe ColdFusion How were you exposed to JavaScript? Gig as a ColdFusion developer jQTouch, jQuery, and Django Interested in building app-like experiences What have you done with JavaScript that you are proud of? Want to push the web into an app-like space Helped to create Ampersand.js Wrote Human JavaScript Created Simple WebRTC Promote web as an application platform What are you working on now? Redux and React New book: Human Redux Independent consulting Speedy.gift Redux-bundler And much, much more! Links: JavaScript Jabber Episode 137 JavaScript Jabber &yet JavaScript jQTouch jQuery Django Human JavaScript Ampersand.js Simple WebRTC Human Redux Redux React Speedy.gift Redux-bundler Henrik’s GitHub Joreteg.com @HenrikJoreteg Sponsors: Loot Crate FreshBooks Picks Charles Hogwarts Battle React Dev Summit JS Dev Summit Newspaper Theme on Themeforest Get a Coder Job Course Henrik Preact Parcel.js Rollup.js Space repetition systems Anki

Panel: Charles Max Wood Guest: Henrik Joreteg This week on My JavaScript Story, Charles speaks with Henrik Joreteg. Henrik has been on JavaScript Jabber previously discussing &yet back in December of 2014 on episode 137. He has since then left &yet and now does independent consulting and works on his own projects. He first got into programming when he started a company that created online video tours for houses and he needed to teach himself programming in order to create the website. They talk about what led him to JavaScript, what he’s proud of contributing to the community, what he is working on now, and much more! In particular, we dive pretty deep on: JavaScript Jabber Episode 137 &yet How did you first get into programming? Liked computers as a child but didn’t want to spend his life on it originally Studied Business in college Create house touring video company Adobe ColdFusion How were you exposed to JavaScript? Gig as a ColdFusion developer jQTouch, jQuery, and Django Interested in building app-like experiences What have you done with JavaScript that you are proud of? Want to push the web into an app-like space Helped to create Ampersand.js Wrote Human JavaScript Created Simple WebRTC Promote web as an application platform What are you working on now? Redux and React New book: Human Redux Independent consulting Speedy.gift Redux-bundler And much, much more! Links: JavaScript Jabber Episode 137 JavaScript Jabber &yet JavaScript jQTouch jQuery Django Human JavaScript Ampersand.js Simple WebRTC Human Redux Redux React Speedy.gift Redux-bundler Henrik’s GitHub Joreteg.com @HenrikJoreteg Sponsors: Loot Crate FreshBooks Picks Charles Hogwarts Battle React Dev Summit JS Dev Summit Newspaper Theme on Themeforest Get a Coder Job Course Henrik Preact Parcel.js Rollup.js Space repetition systems Anki

Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: Azat Mardan In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University. Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React. In particular, we dive pretty deep on: Facebook - Licensing with React Using the Wrong version of React in some companies BSD licensing Patent wars Facebook developing React Difference in Preact and Inferno Rewriting applications What did Capital One do about the changes? React 16 Pure React Was the BSD patents - Med and Sm Companies Patents explained React Developers at Facebook Fiber - New Core Architecture And much more! Links: http://azat.co https://node.university https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan Picks: Cory Axel Rauschmayer post Prettier Charles Indiegogo for Dev Chat forum.devchat.tv Aimee Dev Tees Hacker News - Question on Stack Exchange and Estimates  Joe Heroku  El Camino Christmas Azat PMP  Azat - Short Lecture

Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: Azat Mardan In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University. Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React. In particular, we dive pretty deep on: Facebook - Licensing with React Using the Wrong version of React in some companies BSD licensing Patent wars Facebook developing React Difference in Preact and Inferno Rewriting applications What did Capital One do about the changes? React 16 Pure React Was the BSD patents - Med and Sm Companies Patents explained React Developers at Facebook Fiber - New Core Architecture And much more! Links: http://azat.co https://node.university https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan Picks: Cory Axel Rauschmayer post Prettier Charles Indiegogo for Dev Chat forum.devchat.tv Aimee Dev Tees Hacker News - Question on Stack Exchange and Estimates  Joe Heroku  El Camino Christmas Azat PMP  Azat - Short Lecture

Panel:  Charles Max Wood Cory House Joe Eames Aimee Knight Special Guests: Azat Mardan In this episode, JavaScript Jabber panelist speak with Azat Mardan. Azat is a return guest, previously on JSJ Episode 230. Azat is an author of 14 books on Node JS, JavaScript, and React JS. Azat works at Capital One on the technology team. Azat is the founder and creator of Node University. Azat is on the show to talk about changes in React and licensing. Some of the topics cover Facebook,  licensing with React, using the wrong version of React, patent wars, and much more in-depth information on current events in React. In particular, we dive pretty deep on: Facebook - Licensing with React Using the Wrong version of React in some companies BSD licensing Patent wars Facebook developing React Difference in Preact and Inferno Rewriting applications What did Capital One do about the changes? React 16 Pure React Was the BSD patents - Med and Sm Companies Patents explained React Developers at Facebook Fiber - New Core Architecture And much more! Links: http://azat.co https://node.university https://devchat.tv/js-jabber/230-jsj-node-at-capital-one-with-azat-mardan Picks: Cory Axel Rauschmayer post Prettier Charles Indiegogo for Dev Chat forum.devchat.tv Aimee Dev Tees Hacker News - Question on Stack Exchange and Estimates  Joe Heroku  El Camino Christmas Azat PMP  Azat - Short Lecture

CUBS is back with an episode on the Preact CLI! Chris and Una try it out for their own projects and discuss.

Toran Billups: @toranb | GitHub | Blog Toran Billips joined us for an insightful conversation regarding glimmer-redux: Predictable state management for Glimmer apps. Resources: Glimmer Redux Demystified Talk from Tom Dale on glimmer internals (contrast with Preact made in this talk) ember-redux Glimmer progress report that mentions the migration to Glimmer 0.8 (Big Changes) Blog post following EmberConf 2017 that announced GlimmerJS (for the Ember dev) The Frontside Podcast 086: Routing in Ember with Alex Matchneer An ember-rideshare Blog Post A Rollup plugin for glimmer-redux RollupJS Transcript ELRICK: Hello and welcome to another Frontside Podcast, Episode 89. My name is Elrick Ryan, a developer here at the Frontside. I'm joined by Wil Wilsman, another developer here at the Frontside. Wil, how are you doing? WIL: I'm good. How are you? ELRICK: I'm great, man. I'm excited for this podcast that we have coming up here. Today we are fortunate to have with us a podcast elite member now, Mr Toran Billups. Toran, how are you doing? TORAN: Oh, man. I joined the elite platinum club or something? ELRICK: Yes, you are in the platinum club right now. I think this is probably what? Your third or fourth episode by now? TORAN: Oh, yeah. I think the fourth. ELRICK: Oh, yeah. You're in the elite club right now. You are a Midwest programmer and I hear there is a difference between a Silicon Valley programmer and a Midwest programmer. Could you tell us about what the difference is? Because it's the first time I've heard anything about this. TORAN: Admittedly, I stole this from a very popular developer, Justin Searls who spoke at length one time on a podcast, not too different in this one about his experiences in consulting for companies, who are more in the startup phase or a company that you'll find in Silicon Valley that is mostly just trying to test an idea and get to market, versus his experience for finance or insurance companies based out of the Midwest. I like that idea because my experiences have taught me. I'm a little bit happier when I'm working for companies that are interested in quality or attributes of quality and view the software longevity as mission-critical versus a software that is really just a byproduct of an interesting idea and if we validate that idea in a market, we can always rewrite the software later. Midwest, I guess the short version is we care about the work we're doing and we understand that rewrites are difficult, if ever possible. ELRICK: Interesting, so the Midwest seems to be concerned with long term goals. TORAN: Yeah, I think sustainable -- ELRICK: Sustainable software, at least. TORAN: Yep. ELRICK: Today, you are joining us to not only talk about the Midwest and the beautiful Midwest programmers. You're here to talk about Glimmer Redux. TORAN: Glimmer Redux is a little library I wrote, I think last month. I should start off by asking you guys if you're familiar with a Glimmer JS or if you've heard of that. ELRICK: I've heard of Glimmer JS. I haven't had an opportunity to play around or mess around with it yet. I don't know if that's good or bad because I'm just really busy but I really want to get into it. Wil, what about yourself? WIL: I've read through the docs but I haven't played with it at all. It looks really nice. TORAN: I think the joke that was off the air last time I was on, Wil you might remember this. You're on that podcast with Charles. I said something like, "I'm not young enough to actually be working with Glimmer," and I felt that way for a long time because one thing you should know is it's a pre-1.0 and if you guys have ever worked in a pre-1.0 ecosystem, myself the biggest experience I have to draw from is really pre-1.0 Ember and there were some big changes before 1.0. You can imagine back to that throwaway comment about being very young, there was actually a big change in Glimmer itself recently where they decided to... I don't know if the right word is Pascal Case but they've literally gone away from that 'dasharized' components. It used to have 'foo-bar' and in your template, you would actually see lower case of 'foo-bar' and now that would just be all uppercase. Well, not all uppercase but 'FooBar' and no dash, which is a big change recently. WIL: So a class case, kind of like React or JSX. TORAN: Yeah, exactly. They have a great blog post. Actually, we can reference that in the show notes, about some of these big changes in that release. It was Glimmer 0.8 so it's still, it's making its way to the 1.0 but I got interested in this really for two reasons in the last couple of months. The first was, if you actually go build something with Glimmer -- and this is my experience -- is for the novice programmer just taking a look at it, it's really just a way to use web components to build an application. There's no routing. There's no opinions, really. There's no services like you have in Ember or contexts like you have in React. The first challenge you run up against is when you get beyond a single component or two components and suddenly, you need to share some state across this application. How do you do that? If you guys have some experience, I know the Frontside, with React, if you're not using MobX or Redux or something like that, a lot of times you'll see this pattern where you're actually passing a piece of state through the entire tree or the shared state through a big part of the component tree. Of course, that becomes painful as the application gets to a certain size. One of the things I thought about is if I was to build a real application, the one in mind that was certainly not built yet because I'm not using Glimmer at work but I always think about the ember-rideshare. I know you guys had Alex Matchneer, recently talking about routing and Alex mentions in that episode this challenge for the Ember router today, to be reactive to server-sent events. In the case, imagine you have an Uber or a Lyft app and after the ride is over, the server wants to send an event, maybe and then the app needs to react to that event -- sending you maybe to a new route or sending you back to the map to pick a new ride. The gist of the ride share app is, and Alex, of course I would reference anyone to that podcast, he does a lot better job describing the routing challenges and those are a little bit out of scope for this discussion, but imagine you're going to build an app that ambitious and you're going to build a Lyft in Glimmer. What I found was missing is really what we take for granted in Ember, which is the Ember Service and that is like a singleton or an object that allows you to have a piece of state and then share that state around by injecting that service in only the components that need to reach up and grab that shared state. Redux, which I know your audience is pretty familiar with but a quick recap, Redux is just kind of a global JavaScript object that has state and there's often a library that lets you connect to that state so you can use it in your various components. Glimmer Redux is no different than that, actually. It just allows you, instead of having to create maybe one global JavaScript object and kind of pass it down the hierarchy, you can instead just connect the components that need to be aware of Redux. The ones that don't, of course they just don't connect. ELRICK: I know that you had a hand or build ember-redux and now you build Glimmer Redux. Were there any challenges between building those two different add-ons into two different ecosystems? TORAN: I should take one minor step back because that question is a great segue. I didn't want to touch on the second motivation for Glimmer Redux, which is actually really closely related here and that is, of course I did write ember-redux so with every open source project, there's a little selfish motivation here. I imagine last year when Glimmer was announced at EmberConf that there would be a story from Glimmer to Ember. The idea being you're a small startup, you just want to get your web application going, you don't necessarily like all the big conventions or you just don't think you need all of Ember when you get started but six months down the road, you're suddenly looking at tree shaking and lazy loading with engines and you're thinking, "I wish we had that." Realistically speaking, like today what would a transition for a Glimmer shop to Ember be. Honestly, I think it's tough without a library like Glimmer Redux. Of course, I wrote this with pretty much a mere of the connect API. If people were to check out the ReadMe of Glimmer Redux and ember-redux and you looked at a connected or redux-aware component in both of those cases, the best case scenario is the only difference would be in the import. Instead of import connect from a Glimmer Redux, you would be import connect from ember-redux. Everything else underneath, all the ecosystem of Redux that you can use and both are completely compatible. In fact, if you were to move, imagine you Ember new and you're thinking, "I got to move my Glimmer ride-share to ember-rideshare. Since Redux does a good job in encapsulating all of the state transformations in vanilla JavaScript, you don't have to really worry about the differences between a number object and not having Ember object. After you did Ember new, essentially you would copy over your components. For the most part, they're still template-driven. A lot of handlebars and a lot of TypeScript to JavaScript is the biggest mismatch you would have between Glimmer and coming over to Ember, of course but there is Ember CLI TypeScript or Ember TypeScript, I think. Long story short, you essentially copy the directories of your reducers or middleware from your Glimmer app over to Ember and there should be no changes necessary at all. ELRICK: I know that is the dream that you touched on, I think they phrase it as 'NPM installing your way up to Ember.' In your perspective, do you think that is going to be a thing? Is it going to get there? What are your feelings on that? TORAN: I would definitely be in trouble if I didn't say upfront that I'm not on the Ember core team. Sometimes, people get that confused for some reason but I don't speak for the core team and I'm not really privy to anything. But I do think that the core team has this in mind that there will be a set of NPM installable modules that eventually land you the full set of tools and abstractions that we see in Ember today. A big one that I'd hit on earlier is services. What will services or the Glimmer 0.5 version of services look like when it lands and what about routing and those sort of things? This was really my personal take on how could I make that migration right now without asking permission from the core team. In a Glimmer Redux, I think honestly it offers a good 80% of that. You still have the routing issue, which is a little challenging and you have the TypeScript issue, which you just have to be aware of some of the limitations of using TypeScript in Ember. ELRICK: That's an excellent point that you made because when people outside of the core team take it upon themselves to then try to implement different things around the ecosystem, that can then be motivation or an example for people outside of the core team to see like, "This is a possible solution to a goal we're trying to reach." Kudos to you. TORAN: Back to your original question about 15 minutes ago, what was different about the ecosystems writing ember-redux the add-on and Glimmer Redux, which is... I don't really even want to call it an add-on. I kind of label it as a Glimmer library but to your point just a second ago, when I got interested and saying, "I wrote Glimmer Redux, now I want to share it so other Glimmer authors don't need to copy/paste this file," and the first resistance I hit up on is there really is no Glimmer library or Glimmer add-on. You could write an Ember add-on because if you guys get into Glimmer, you'll find this as well. There are certain hooks that are used in the Glimmer build process where Ember add-ons like Ember CLI SASS can be used from Glimmer. But the challenge I had using an Ember add-on, of course is that this wasn't an Ember component or anything Ember related. It needed to really be test driven from a Glimmer apps. Really, if you went to NPM installers, what you're pulling in is effectively my Glimmer app that also exports publicly this connect function, which is not necessarily you're leading, maybe anything to core team that could happen. A big reason for that as well and one of the challenges building this, is that Glimmer right now, after to try to emulate my 'quasi-success' in doing this, is really bring your own build system, to actually share a Glimmer components or internals like this connect API that Glimmer components can use. What I mean by that is on the website, one of the challenges I faced was -- this isn't a knock against the core team, this is just my honest experiences -- when I read the Glimmer JS docs and it says right in the installing guide, "Glimmer uses Ember CLI, this battle-tested command line interface from the Ember project." Now, pause right there because again, not to beat up on the Ember core team or anything but assuming in that one sentence that they're using Ember app, what I noticed when I opened the Ember CLI build file is the project was actually a Glimmer app. Now, I did a little bit of digging here and I think this is validated, at least back when I worked on Glimmer Redux last month, that Glimmer app is not like inheriting or pulling in a bunch of shared code from Ember app. It's actually a completely separate build tool. As part of this process, I actually for the first time had to go through and learn Rollup and understand how the Broccoli process is kicked off, how both Rollup and Babel are used to build this and then how to apply some convention. If you guys are familiar with Ember, you have this add-on directory and an app directory. The guidance from the Ember team is around how to structure add-ons. Of course, you write all of your kind of private-ish or add-on code in the add-on directory and then whatever you think will be public, you export from the app directory and that sort of merges it into the tree when the application is built. People are allowed to use your code but then also, they can override that code. One of the challenges here is if I wanted that exact same API and I want people to make this migration from Glimmer to Ember using Redux, I had to actually invent that convention so I wrote a Rollup plugin and it's all listed in the docs here. One of the strange things people who are checking out Glimmer Redux hit me with first is, "I see a Yarn installed Glimmer Redux but then second step is installing this Rollup plugin. What's the deal?" I think it is because most people assume the Ember CLI you're using is identical and somehow, I should have written an Ember CLI add-on for this. I think that was the biggest learning curve and people should just be aware of that. If you're interested in sharing code right now, there is really not a baked story and that's okay. It allows people to innovate. Of course, the innovator's dilemma being that, I don't really know without [inaudible] some migrating RFC or getting involved with the core team, how to make that thing. I ultimately just hope the core team improves this and I'm sure they will but for right now, I don't really want to wait around for it. ELRICK: Got you. What is Rollup, for people that are not familiar with what Rollup is? I'm sure everyone is probably familiar with Babel by now because it's used everywhere but what is Rollup? TORAN: Embarrassingly, I don't know the technical... But I would say the role that you can see, if you actually step through the node process as your Glimmer app is being built, is it helps really condense the overall build size. What I see is it's essentially traversing like Browserify in some ways. This is, again just my primitive look but it traverses all the imports you have and it tries to pull in the bare minimum to keep the bundle size as small as possible. ELRICK: Toran, you have had a lot of experience with Redux and Redux is now being used in several different software platforms, I guess or software areas like Vue and they probably even have in Angular now. They have it in Ember and React. Redux is kind of spreading its wings and it seeds across every ecosystem. Do you feel that Redux has reached a state where people are just satisfied with the current state of Redux or do you think that people are going to be then, looking to build another abstraction on top of Redux? Do you have any thoughts on that? TORAN: The fact that Redux is so simple has allowed it to become so ubiquitous. I heard someone say this term the other today, which is like, 'ubiquity over consistency,' and that I think describes the both the growth of Redux and why it is kind of de facto for data management across all ecosystems. I think there's two camps that I hear about and I'm curious if you guys see this in your consulting work but there is certainly, the developer see this ubiquity but no consistency and see chaos in their experiences. I can totally relate to this. There are development shops I've seen where one team goes this direction because there's no strict guidance goes another and then when those teams meet up for a project in 12 months, they look at each other and the apps are, of course nothing alike, which is a big problem that Ember tries to solve. My biggest question here really is kind of curving us slightly back to the Glimmer story. If I can reframe your question, Ember is traditionally very big on convention and I think a lot of the community that is still in Ember today in large part is because of this convention, these guide rails about the community has set up but Glimmer being this NPM install your way to Ember, I think along the way, there's going to be either a new set of users that are coming just for the winds of the Glimmer VM and they happen to find themselves, not necessarily in love with some restrictions or opinions that would come with a migration directly to Ember and I'm curious if the Glimmer community that will show up for that is mostly Ember backed, meaning that they want to slowly build with RFC as a process that the entire community uses and there's one solution like we end up with often an Ember. If a community evolves more experimentally like you saw in React, where there was, of course Redux but then there was MobX and then there was various little wares for Redux that different teams would try out and eventually, there was no one proven way but there was always at the heart of it, Redux with some extensions or other add-ons around it that got teams to where they are today. I'm curious to see where this Redux, especially with the Glimmer influence, will end up. WIL: You touched on a little, I think one of the, maybe not a problem necessarily but one of the biggest barriers in Redux and React and maybe Glimmer -- I'm not sure -- is that it's almost too loose without any opinions at all so it kind of gives developers the freedom to mess things up big time. What's your opinion on that with Glimmer, like Glimmer is headed toward this NPM install? Is it too loose? TORAN: I guess that's the question, I wish we both had the answer to. It's funny. It's a double-edged sword. If it's loose, it seems like somebody is going to go create a mess but at the same time, if it's loose on the surface, it often seems like it has less surface area and as a result, a lower learning curve. React is a good example where most people, I think have gone to React or at least in my experience, I like React because it was so simple and there wasn't a huge amount of things to learn. There wasn't this full ecosystem, at least out of the gate but of course, what you find the moment you want to join a team or go build something ambitious is that you've got to make a bunch of decisions and that is certainly the calling card of Ember. What makes Ember special is they've settled on a handful of those decisions. I think ideally, I'd like to see the community in Glimmer check out Redux, get an idea of what problem it actually solves for them and if it is useful, then find a set of middleware or extensions from the wider ecosystem that actually solve the problems they face. Back to this Glimmer rideshare example, I think one thing that stands in the way as I play around with that is just a very basic routing story. Even if that is as simple as I have a component that I'll just call it route, what hooks in this Glimmer component are correct to fetch data. In the Ember ecosystem, we have a very special route object, essentially who has a set of hooks that are known for handling the asynchronous stuff in our Ember apps but there isn't anything like that yet, in Glimmer which is the next stumbling block for me to actually go build something big. I'm kind of messing around with the idea of this reactive router built out of Glimmer components but until that's actually kind of surface, mostly just spit balling here. ELRICK: With flexibility comes a lot of power but then there's also the case where our flexibility could lead to chaos. But being that something as flexible, it allows you to adapt it to whatever your particular needs are -- you know, the 'special snowflake' as everyone ends up being. Because Ember has been around for a while now and has proven itself and its battle-tested in a lot of areas, now as NPM install in our way from Glimmer up to Ember, do you think that they'll be able to then, extract some of those hardened pieces of Ember out of Ember and then give us a solution inside of the Glimmer ecosystem based off of the Ember ecosystem? Then not have so many varying different opinions or different packages or add-ons or libraries that you may need to pull from that you may just have like a set of Glimmer-approved libraries or add-ons to use to then, get your way up to this full Ember app. Do you think that that's a road they're taking? Or a possible road? TORAN: Yeah, I think for sure. A lot of the talk right now if you're in the Glimmer channel on Slack in the Ember community, I think the next big step here is having the ability to take a Glimmer component as it exists today and use that, extrapolate from there and the plan is to prove out things in a more experimental ecosystem as pre-1.0 Glimmer ecosystem. As they become more solid, we essentially just adopt them and then use them as a first class. In Ember actually, this isn't true but I envision a world where in the months ahead, we're essentially using Glimmer components in Ember so I'm already challenging myself with how would a library or add-on author help people make this progression from Glimmer to Ember if they don't do something like I've done here with Glimmer Redux because eventually, there will be this shared component world, at least in the middle ground, where Ember has both Ember components and Glimmer components. I think it's a road yet to be traveled and that's what I'm excited to be on the podcast and get people talking about building libraries for Glimmer, just because there is not a cow path or a paved road for you right now. I think if you learn just a little bit of Rollup or you dive in and take a look at the DI system built in a Glimmer right now, there is a lot you can actually do with it. I know there are certainly big named add-on authors already checking it out in preparation for such a migration. WIL: Besides the whole Rollup process, was there any other friction points in integrating Redux with Glimmer? TORAN: One that I want to call out but it is, I believe still Rollup related. It's mostly a PSA, to warn people. If you are building one of these little libraries like I talked about with Glimmer and you're going to do a Yarn link, which means that you're going to just work locally and not really publish to NPM until you're done, be aware that if you're Yarn linking and then going over to another project to test this Glimmer library, then you'll actually get temporarily two copies of Glimmer. In fact, that is how this Rollup plugin I wrote -- sort of 'bring your own build' for Glimmer -- became essential as I was like, "I'm getting two copies of the Glimmer component," so what was happening is example, I was playing with this connect API, it was always calling into the wrong Glimmer code so the code that I was expecting in my add-on was never firing. We come to find out when you're not doing Yarn link or you're not working locally, this isn't a problem. Actually, Tom Dale reached out and helped me a little bit later because my first version of the Rollup plugin had this little hack in there that said essentially, "I'm going to mask away this duplicate Glimmer problem," and it turns out it's not a problem. If you are working locally, be aware that you will have this problem as my guess. ELRICK: What gets you most excited using Glimmer? Are there any specific features or things within Glimmer to get you most excited? I guess the second question would be, what do you think Glimmer is going to unlock for the future of app development in Ember? TORAN: I think the first thing I get excited about was visible in this talk that Tom Dale gave a couple weeks ago. I'll try and dig that up for the show notes where he show the advantages of Glimmer over the competition today. The big thing that just blew me away was some of the advantages over, even Preact, which I was kind of surprised that a lot of times there's this rivalry for performance especially between React and Angular and Ember but no one ever really talks about Preact, which is known in a lot of ways as the thinner, lighter-weight React, if I'm not completely wrong. I'm sure somebody is going to be table flip on that definition. But my view was that if you were really performance-hungry, you could check out Preact, which was for performance reasons there was a smaller bundle size so you're just actually shipping less JavaScript, which means they're parsing less JavaScript and Tom went directly after this library in his talk and just showed a very interesting point at the end. I don't want to spoil it for people but let's just say, it appears to show Glimmer as just an order of magnitude better as a primitive for building web components. I think that is the big draw and how will that make Ember better. I think, mostly in the same way that I just described, where we'll essentially get a component for free in Ember that is just a better performing primitive for the web. ELRICK: I'm not too familiar with the guts of Glimmer but from what I understand, Glimmer compiles down and it has some opcodes that then compile down to binary. Is that correct? TORAN: Yeah, I think there is a binary format that they're shipping or they will soon be shipping. If you're really interested in the technical details of that, I'll definitely be sure you check out this talk from Tom because now the real magic behind this is they essentially boil it down to the ability to compile these templates down to 'byte code,' as they call it and Tom has a really funny part in his talk where he says, "You know, it's not a marketing term, this byte code word," and it becomes true because later in the talk, you hear that, essentially the Glimmer VM or the big value add of Glimmers VM is that you're just feeding it with byte code until the next 16 millisecond buffer comes up to paint, in which case you just pause and that allows, I think as he describes, less jank or allows less freezing up that main thread because you're releasing control back to the UI every 16 milliseconds, essentially. ELRICK: Yesterday, there was a meet up with a lot of the Ember core team. Ed Faulkner had made a point that since Glimmer compiled down to byte code that then is not too far of a stretch to then use that with something like Web Assembly, that with then give Glimmer an extreme performance boost. He sets up Glimmer to be used in what can be potentially the future of the web, which is Web Assembly, which I thought was really interesting and it kind of blew my mind to think, "Oh, yeah. That is true since it compiled down to byte code and Web Assembly compiles down to that." We can get that performance boost in that Glimmer is forward thinking in a sense. TORAN: Yeah, man. I totally agree. One of the things I honestly value about the Ember core team is they're very both tactical and visionary at the same time, where in the short term, they're doing things to accomplish real pain points we have but without anyone really realizing it, they're also setting up the stage to solve huge problems that we're all going to face in six, 12, 18 months. I definitely appreciate and love the work these guys are doing. They should hear about it. Obviously, this is all open source and most of this time is gifted, just given away so I really appreciate the core team. WIL: Speaking of performance, we know that the Ember has a run loop and basically, most of these libraries have some sort of loop that determines when they should batch things together or render things to the screen. Does the Glimmer have this concept? What do they take advantage of to make it as performant as you say? TORAN: Yeah, that's actually a really good question and I'm probably minimally equipped to answer it but the short version of it is there is no equivalent run loop for batching work that I've seen inside of Glimmer. Instead, you're more directly interacting with request animation frame, which we miss directly from Mozilla here but requests animation frame tells the browser you [inaudible] browser call specific function to update an animation before the next repaint. Where does this come in for Glimmer? Essentially when you call set or you decide to change a property that Glimmer is listening to and if anyone was not familiar with Glimmer, you designate this by using the tracked attribute. The tracked attribute, when you change a value, it fires this 'set property did change' and behind the scenes, 'set property did change,' if you are familiar with Ember, in my mind is close to 'notify property change,' which is what happens when you do Ember.set. If you've ever actually change something in Ember behind the scenes, there is a notify property change event fired and then we queue that work and it's a similar-ish process except that there is no run loop. What we do is we just call schedule rerender, I think in Glimmer and that just fires off request animation frame to try and rerender within that 16 millisecond window before the next repaint. WIL: From my understanding, the request animation frame is Glimmer's run loop essentially. TORAN: I think I saw actually a discussion between someone at Ember core kind of saying in the public channel that, if you're using Embers run loop, the equivalent-ish today would be request animation frame but the point came up that there's really no way to have a different set of cues because Ember itself has many different cues in the run loop and request animation frame, as far as I know really is just one function with a single callback, where you try and fit in as much work before that repaint as you can. I don't think there's prioritization that you would get in the Ember run loop. But at the same time, I'm not sure if that's actually a requirement. I don't think request animation frame was as mature as it is today back when backburner, which is behind the scenes of what Ember run loop is using, was built years ago. ELRICK: Since Glimmer is using requests animation frame and not the Ember run loop, is it going to continue to use requests animation frame in the future or they're going to develop like a run loop equivalency for Glimmer? TORAN: That's definitely out of my depth. I know from looking inside the code, the rerender work essentially calls like a 'begin,' to say begin doing your work, which I believe is like the reconciliation type work if you have a React background, I believe. I don't know what decides to end that. If the request animation frame is truly saying, "We're at the 16 millisecond budget and we're going to quit feeding the Glimmer VM byte code instructions now because we need to go back and paint." I would guess that that is the high level narrative but I actually don't know the implementation details. ELRICK: Since Glimmer is pre-1.0, it's a place for you to experiment, try out new things, really exciting area to play around in. What kind applications do you see people building today using Glimmer and what's the good application that's a good fit for Glimmer right now for you to experiment with? TORAN: The big application that I've seen that exists is being built with Glimmer in its current form is the Glimmer Playground. The Glimmer Playground is an area to go mess around with Glimmer, if you've never used it or you just want to go [inaudible] with the basics. As far as what is an ideal application, honestly I think we're at a point where we need to push the bounds of what a purely component based library can do. I think if you could come up with some kind of basic routing story and have a mechanism to share state and bubble events, whether that's Redux or some kind of home grown service layer at some point. That would allow you, in my opinion to build just about anything. The only caveat that you're going to be missing is a ton of opinions and you're going to be paving new grounds so just be aware that happy path for any pre-1.0 is be aware that they could change anything, anytime. But that shouldn't really restrict you from making a hobby project out of it. Back to your original question, I would say building any app that you're okay to go back and rework, not necessarily reinventing Facebook or something like that with it at this moment but at the same time, it would be great if someone did in a hobby way because we need to see some of the constraints and challenges. I got playing around with it myself and noticing if I'm going to build anything with Glimmer, I've got to have a way to share state and bubble events up to the single atom at the top that allows me to share all state. I think without some experimentation, we just won't know what apps are possible. ELRICK: You've been talking a lot about Glimmer today and using Glimmer. Since Glimmer is pre-1.0, are there any limitations that people should be aware of when they're going to be going into building a new Glimmer app? TORAN: For Glimmer Redux specifically, one of the challenges that people would see and they should know about if they're going to use this little Glimmer library, is that it doesn't yet allow you to write reducers in TypeScript, which would be a little counterintuitive because if you get into Glimmer, you'll notice the big differences -- everything is in TypeScript and not JavaScript. Luckily though, I think this is really just a build tool decision. Truthfully, the spike version of this that I have where you can use TypeScript, it doesn't require any change to the Glimmer Redux library at all. In fact it's completely unchanged. The difference here is that the Rollup plugin I use needs to see a change. It's kind of weird in that way, back to my point earlier where you kind of bring your own build chain and one of the things I don't like right now, which is the reason I haven't published this TypeScript version of it is that I'm actually doing a TypeScript compile of all the reducers or middleware in the Rollup plugin. With the mass confusion right now between Broccoli, Rollup and Babel, I just don't feel really great about it. Mostly because I have not truly been in the guts of the Glimmer app build tool or the application pipeline yet and I want to be a bit more educated there before ship something, back to being a Midwest developer here. I just don't feel good about shipping something and say, "Oops, we got it wrong." I take a lot of time and I also take a lot of pride in what I am shipping so I want to have a really good story about TypeScript. It does make for a little bit of a weird experience: bouncing between Glimmer components written TypeScript and flipping back to reducer file written in JavaScript. just be aware of it and at the same time, I didn't want to completely halt shipping it because again, I think we need to actually build apps with this and a concession here being that, of course you have to write reducers in JavaScript was still enough for me personally to get some value out of building Glimmer apps and honestly, it got me building them sooner. WIL: Is there a way to use Glimmer Redux without the Rollup? Can we import something into our Glimmer app to use it or this Rollup is required? TORAN: Yeah, that's a great point. You can omit the Rollup plugin entirely. What that results in is you'll have to do some hand wiring yourself. One of the upsides or one of the benefits of this Rollup plugin that I wrote is this conventionally provides a store and redux-thunk, kind of like a happy path for people who are just not familiar with wiring up their own Redux store. If you forego this plugin, you just have to do that yourself. You may actually have to do some kind of Rollup hacking in your Glimmer app, which is the thing I want to avoid. The one in particular that I know you'd have to do is there is a Node ENV that is looking for a production setting in Redux so the first thing you have to do is use a Rollup replace plugin to replace Node ENV with Ember ENV. If you can't do that, you actually get an error in just trying to stand up your Glimmer app with Redux. ELRICK: Toran, are you giving any talks or have any books or anything that you want to get out there and talk about? TORAN: I'm not actually on speaking circuit right now. I am certainly, probably like you guys are, thrown a talk or two together for the EmberConf proposals that are now out. I think they're open until November 21st. If anyone is thinking about submitting a talk to EmberConf, this should be in next March. Now is the time to get those in and I certainly have one out there but I've got one, off the top of my head that I would certainly like to find some time and submit that's related to Glimmer. ELRICK: Cool. We had a wonderful podcast today. We touched on Glimmer Redux and Glimmer and I want to thank Toran for coming on. Thank you, Toran. TORAN: Thanks for having me, guys. The fifth time I have to be on, I don't know if that will be in 2017, though. ELRICK: Yeah, we're going to bring you back for a fifth time and I would also like to thank Wil for coming on the podcast as well. Wil, thank you. WIL: Thanks for having us, Elrick. ELRICK: Anytime. Toran, if people want to reach you, is there a particular place on Twitter or anything that people can reach out to you or email or anything? TORAN: Yeah, at GitHub, I got my email out there but also on Twitter, of course. You can reply me there. If you have a question specifically about Glimmer Redux, of course you can got to GitHub and throw an issue up there or hit me in the Redux channel on the Ember Community Slack. ELRICK: Thank you all once again for listening. This is the Frontside signing off and if you want to reach out, you can always hit us up at the Frontside.io and we always want to hear about your new project that you're working on. Thank you for listening and that's peace from the Frontside. WIL: Everybody have a good Thanksgiving!

We’ll look at how apps built using React, Preact, Vue, Angular & Polymer can be used to build instantly interactive, engaging & data-plan sensitive user experiences. We'll also look at how this investment paid off on core business metrics. You’ll leave this session learning PWA best practices, patterns for efficiently loading websites and the latest tools for getting fast and staying fast. Video: https://www.youtube.com/watch?v=aCMbSyngXB4

Latest posts in webpack blog, egghead courses on Cycle.js and Error Boundaries, StackBlitz — an Online VS Code IDE for Angular & React, transpiler from Polymer or Vue to Preact, npmtrends.com graphs of downloads React vs Angular vs Vue. - https://medium.com/webpack/stabilizing-webpack-3-week-18-19-e8005c8a02ac - https://medium.com/webpack/road-to-webpack-4-week-20-21-1641d03ce06e - https://egghead.io/courses/cycle-js-fundamentals - https://egghead.io/lessons/react-error-handling-using-error-boundaries-in-react-16 - https://stackblitz.com - https://medium.com/@ericsimons/stackblitz-online-vs-code-ide-for-angular-react-7d09348497f4 - https://github.com/gothinkster/realworld - https://twitter.com/_developit/status/898952382960119808 - http://www.npmtrends.com/angular-vs-react-vs-vue 5 minutes of React - podcast about React hot topics and JavaScript ecosystem. https://5minreact.audio

This time we needed bear facts to fill in for Henning who was sick unfortunately. Other than that we covered the Node kerfuffle as well as the re-occurance of the React license kerfuffle. Also Kahlil thinks Medium is going down the fugly path (it's just his opinion maaan). Also: Bluetooth door locks and a pretty interesting compiler by Jason Miller of Preact fame.

Some of the latest news from the Preact world: the mobile version of Uber website uses Preact as well as the new Transformers promo site, and the author of Preact gave a great talk called "Preact: Into the void 0" at JSConf EU 2017. I will also share my impressions of an egghead.io course and take a look at preact-cli, a tool for quick PWA app creation. - https://preactjs.com/ - https://eng.uber.com/m-uber/ - http://www.transformersmovie.com/ - https://youtu.be/LY6y3HbDVmg - https://egghead.io/courses/up-and-running-with-preact - https://github.com/developit/preact-cli 5 minutes of React - podcast about React hot topics and JavaScript ecosystem. https://5minreact.audio

Show Notes Wes Bos' Site Level Up Tutorials site Level Up Tutorials YouTube channel Scott Tolinski personal site Cloudflare Next.js Hacker News Example in Next.js GraphQL Graphcool create-react-app React dev-tools Redux dev-tools Preact.js React Storybook Meteor Blaze Sick Picks Wes: Parcel App Scott: Fish shell Shameless Plugs Learn Node React Native for everyone

React 15.6, webpack 3, Babel Notes, mobx-state-tree 0.7, Preact on egghead.io - https://facebook.github.io/react/blog/2017/06/13/react-v15.6.0.html - https://twitter.com/dan_abramov/status/875149571688734721 - https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b - https://github.com/babel/notes - https://github.com/mobxjs/mobx-state-tree - https://egghead.io/courses/up-and-running-with-preact 5 minutes of React - podcast about React hot topics and JavaScript ecosystem. https://5minreact.audio

The band is back together! Henning watched Moana 100 times. Rockbot had a Twitter break and a 10 year college reunion. Kahlil is porting tinydraft.net to Preact. preact-cli is out. Tom Dales says Frameworks are becoming compilers. Ben Schwarz makes CalibreApp. CSS-in-JS is a huge thing.

News: - React Amsterdam 2017 - Hacker News readers as Progressive Web Apps written in React, Preact, Svelte, Vue, Angular and viperHTML - TodoMVC for the RealWorld™ — Exemplary fullstack Medium.com clone powered by React, Angular, Node, Django, and many more - Prepack - a tool for making JavaScript code run faster. Links: - https://twitter.com/ReactAmsterdam - https://www.youtube.com/playlist?list=PLNBNS7NRGKMHxfm0CcYNuINLdRw7r4a9M - React Amsterdam 2017 playlist - https://youtu.be/3J9EJrvqOiM?list=PLNBNS7NRGKMHxfm0CcYNuINLdRw7r4a9M - Complexity: Divide and Conquer - http://divideandconquer.surge.sh/#1 - https://github.com/tastejs/hacker-news-pwas - https://medium.com/@ericsimons/introducing-realworld-6016654d36b5 - https://github.com/gothinkster/realworld - https://prepack.io 5 minutes of React - podcast about React hot topics and JavaScript ecosystem. https://5minreact.audio

Henning is out battling EvilHenning once again. Snail facts! JSConf EU happened and Kahlil did stuff there. Rockbot will be at WebRebels. npm@5 is coming. Merry

Preact - Fast 3kB alternative to React with the same ES6 API. My experience. - https://preactjs.com/ - https://www.youtube.com/watch?v=ETjTVV4qGoY - "React 30" podcast episode about Preact with author of the library Jason Miller 5 minutes of React - podcast about React hot topics and JavaScript ecosystem. https://5minreact.audio

In this episode, we are joined by Trey Shugart who is a front-end developer (Principal Developer) at Atlassian, proponent of web components, and author of SkateJS to talk about Web Components. Items mentioned in the episode: Fast and the Furious 8, Skate JS, Preact, React, Chrome browser, Rust episode, Polymer, X-Tag, jQuery, Flux, Functional Programming, Safari, Firefox, Web Assembly, W3C, Progressive Web Apps, Ken Wheeler, Service Workers, Lighthouse, TypeScript, Flow, nwb, Nest, React, Angular, Ember, Jason Miller, Knockout, Dart Guests: Trey Shugart - @treshugart Panelists: Jem Young - @JemYoung Ryan Anklam - @bittersweetryan Brian Holt - @holtbt Stacy London - @stacylondoner Picks: Trey Shugart - Flow Type Trey Shugart - Line 6 helix Trey Shugart - Skate Maintainers Trey Shugart - Jason Miller Jem Young - Ryan Anklam Jem Young - The Wee Baby Burgess - Austin Ryan Burgess Jem Young - Iron Fist Ryan Anklam - Spotify Discover Weekly Playlist Ryan Anklam - Ancillary Justice Brian Holt - Flow Type Brian Holt - Babel Preset Env Brian Holt - Planned Parenthood Stacy London - Web Developer Roadmap Stacy London - Broken Social Scene - Halfway Home

Preact Unveiling Ignite 2 – Red Shift callstack-io/haul: Haul is a command line tool for developing React Native apps

Jonathan Jackson: @rondale_sc | Ember Weekend | 201 Created Show Notes: 01:01 - 201 Created 03:09 - 2017 Ember Community Survey 14:06 - Handling Changes and Churn 27:53 - FastBoot Resources: Boots and Shoeboxes [SlideShare] Typeform EmberConf JSX Isomorphic JavaScript Ember Weekend Episode #66: Bug Integrat (with Charles Lowell) Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 60. My name is Charles Lowell. I'm a developer here at The Frontside. With me is Robert De Luca, also a developer. Hello, Robert. ROBERT: Hello, hello. CHARLES: Today, we actually have a meeting of the podcast minds. We have with us a very special guest, Jonathan Jackson. You probably know him from the Ember Weekend Podcast. If that's your thing, it's a great podcast. I listen to it, you should definitely check it out. Hello, Jonathan. JONATHAN: Hey, how are you doing? I'm really excited to be on the podcast. I am an occasional listener. It's similar to my own podcast where if I don't edit it, I tend not to listen to it. It's when I have long trips you guys are number one, number two right behind The Adventure Zone which is a D&D podcast. CHARLES: You worked at 201 Created. Why don't you tell us a little bit about that? It's an interesting company. JONATHAN: Actually, when we book to this podcast, I was not at 201 Created. This is a very new thing for me. I think I started right around the time of Ember Conference out in San Diego and I'm just realizing that this is not exclusively an Ember podcast. This is the first podcast I've been on where I can't just assume blanket knowledge of Ember stuff. But it's an Ember conference out in San Diego. I actually gave a talk there about FastBoot which is a server side rendering technology. Right after that, the entire 201 company which I think is four. It's very small. The entire thing, the whole crew went to do a company event and basically camped out in the mountains for a few days, which was really, really fun. But I started working there and 201 is a consultancy based out of New York but I think it's more than half is remote. I think Matt's on the West Coast, two of them are in New York and I'm in Jacksonville right now. We do a lot of really cool stuff. We worked in a lot of different companies. You can actually see the website at 201-Created.com and you can see the different clientele we worked with. But we specialized in consulting, training as well. As well as a couple of other services that we offer. It's been a real great experience. It's been very fun and also I'm learning a ton which is really cool to be in a different environment. I have done consulting for a little over four years, previously at Hashrocket. I got to tell you, consulting will get your wheels turning. It's been nice to see how different consultancy takes a stab at things. It's been super fun. CHARLES: Yeah, it's a fantastic company. I've definitely known them for a while, certainly through my involvement in the Ember community and one of the things that always struck me is just how seriously they take the community aspect of it. We were talking about just a little bit ago, it was 201 that sponsors -- well, sponsor isn't really the right word for it. It does the Ember Community Survey which I think is a practice that we're now used to in the Ember community but I think it's something that I would love to see wider communities do. Maybe you could talk a little bit about that and explain what this community survey is, why it exists and what's the knowledge that's derived from it and how do we take action on that? JONATHAN: 201 also does contribute workshops and things like that. The idea is to make Ember a more inclusive space, a place where people feel comfortable being a part of our community and a big part of that is self-reflection and realizing where you have weak points and how you can actually mend areas that are being neglected or whatever. Basically, shining a light to figure out where we need to improve and a big part of that is the community survey so figuring out what technologies are being used, figuring out what demographics are represented or under-represented and trying to figure that out. It's actually been really cool. I think this is the third community survey and it's live right now. I feel like we could probably shed a little bit about some of the questions. This year, they did a really cool thing where they actually put all of the questions before they put the survey up live. They actually asked for a comment period which is very, very Ember thing to do. CHARLES: Because I was actually going to ask about that. Who is the final arbiter of the questions that get in because part of the survey is determining you're trying to get hard metrics on a set of questions but it's the questions that you don't know that you should be asking which are really the tricky ones. JONATHAN: It was really interesting to watch the document change over time. There was a committee discussion between some of the people in core team and Matt Beale and Tom Zalman who's been doing the organizational stuff as an intern at 201 and he's been doing a fantastic job of really staying on top of it. It's a surprising amount of work to get a survey together, especially when you have a comment period so there's tons of little adjustments here and there need to be made, to wording and phrasing and also like responses. Surprisingly enough, you can actually have biases in your questions based off of the responses that are allowed because multiple choice. It's been a really interesting effort and I think trying to weigh and balance that side of things, where you want things to be worded in a way to where people can answer more honestly and without a bias coming into the question. Because the questions change year over year, trying to get data that is historically relevant so we can see what versions were being used last year and versus this year, what was your experience level with Ember last year and this year. But still make those changes that are recommended. It's an interesting balancing act. I was very interested in the process. I was trying to stay as involved as possible but I think also, Isaac was working on that as well. It's been a team effort. The survey is a very interesting aspect of the Ember community and it's only been three years but it feels like longer. CHARLES: What I love is the work. Once you actually get the survey up, the work has just begun, which clearly a lot of thought went into it, not just the questions that is very beautifully presented -- ROBERT: But the survey, what's the software that you're using to do that? JONATHAN: I think Typeform is the thing that they're using. I feel like it actually works on mobile and I have a great analytics tools. If you're doing a survey, you should come talk to me. ROBERT: Does that like track people that half-fill out a survey and exit? JONATHAN: Yeah, it does. It actually does track like -- what's the word for that -- there's a word for that. Basically, the main metric that we're looking for is people who open the form then complete it and the percentage there, that's the respondent percentage. I've actually haven't seen the metrics yet. I think I might just wait until the conference. You're exactly right, this is only the first step so once everyone fills it out, then there's a bunch of data extraction because some of these questions are open-ended and allow users to directly input their own feedback and trying to sort that and make that useful information as a lot of work and a lot of effort. It's interesting to see, of course there's some obvious graphs that are going to happen like we see transitions. It's easy to graph out the number of people using things on a time axes or the X-axis or whatever. There's some kind that are obvious but I'm actually looking forward to seeing the results. I was only really involved in the actual administration of the survey in as far as I provided some feedback before the main feedback period. But it's been really a community effort which is great because it's a community survey. That's pretty neat. CHARLES: One of the questions that I have is how do you ensure, because the only people who hear about the survey are the people who are already involved. In order to get -- I don't want to say statistically valid -- a broad and more informative data set, how do you try and balance the concern of we want to make, maybe half people exposed to this who aren't inside my community or maybe sitting on the boundary somewhere or slightly over somewhere versus at some point, if someone's an attorney for example, then we don't really care if they hear about or participate in the survey. Certainly within the developer community, which is ill defined to begin with, how do you try and draw those lines to make sure that you get the best knowledgeable dataset possible? JONATHAN: You know, I don't really know. I guess, it's the meta point that I should probably make but it will prevent me from giving my opinion. Basically, I think that since this is a community survey, it makes quite a bit of sense for the community avenues for learning about Ember to be used to actually distribute the survey itself. For instance, these podcasts, like my podcast as mentioned in the survey and now, this podcast is going to mention in the survey. I want to say, "It's going to be in Ember Weekly." That's just a guess, I don't know. But there's really avenues: Reddit, Twitter, etcetera and then the Ember blog itself. Those are the means for dispersal within the Ember community. The one metric that we get from that is what can we reach or who can we reach? How many people can be reached through the normal means? That in itself a metrics. But I think it's kind of valuable to test that every once in a while. I believe over the first two, we saw 100% increase in respondents from Year 1 to Year 2 so it'll be interesting to see from two to three to see if that number continues to increase at a really rapid clip or if we're seeing some other trend there. It is an Ember survey so we are going to assume a lot of Ember-related things. We're trying to gain insight into the Ember community so it's probably not great to put it on JavaScript Weekly, for instance and get a bunch of React developers in that. They're going to be like, "I don't use this." Why are you using Redux, they don't understand. Oh, wait, Ember Redux, what's that? That sounds up my alley. ROBERT: I did feel that form out at the survey with my experience that I've had with React recently, things that I would like to see come over to Ember. I don't know... That'd be interesting to see or I wouldn't want them to fill it out because they would, obviously ruin the data set but I think another survey with more information from other communities to see like, "What's preventing you from utilizing Ember or what are the barriers to learning it?" Maybe from other communities might be interesting. That would be cool to do cross-pollinated surveys where you can be like, "We'll do it, if you do it and then React can provide us something and vice versa. I feel like the word homogenization is bad, usually but sharing ideas is good, I think. CHARLES: If you've never experienced this in your development community, the amount of work that goes into actually analyzing the survey and trying to draw and make inferences from it is just astounding. Who does that? Is that like Matt sitting up in an ivory tower? That's was just the wrong term. Basically, he can sequester himself for a month and put on his thinking cap and just come out with these mind-blowing deductions? JONATHAN: To be honest, I wasn't here last year at 201. My suspicion is that Tom will do quite a bit of the data munging, I think is the word. Then we'll go through phases where I think Isaac and Matt are working pretty closely with the survey stuff so they'll probably do feedback loops, then eventually before anything happens, I think with EmberConf, there's usually a survey blog that comes right alongside the EmberConf thing, where you share some of the results. I think that those things will go out to core and then core will start to pick it apart, toss that around exactly and then come back and basically, you're going to try to get as many people who are pretty smart, looking at it and trying to make sure the data makes sense and honest and doing the right things the survey needs to do, in relevant, I guess is the other metric. CHARLES: Now, as part of the survey, one of the things that you mentioned was the purpose is to surface weaknesses and gaps that need to be filled. When you think about your experience and the way that you filled out the survey, obviously it's anonymous, share what you're comfortable sharing but what were some of the things that you perceived as maybe holes that need to be filled and you're hoping that the survey will bring to light. JONATHAN: That's a very interesting question. I think, the thing that I'm interested in seeing is maybe different than what I've seen. One of the things I'd really like to see the survey that bring to light -- it's probably the most important metric in my mind -- is where people are at in the upgrade process because the cadence of releases an Ember is such a big facet of what makes Ember really powerful, especially for large companies and stuff like that. But I've personally seen people get stranded in certain spaces. Usually by the time they call a consultant to help them get un-stranded, they're at a point where they're going to try to work towards pushing past it. I think this is felt primarily around the 1.13 switch. People did get stranded there and some people are still working on very large apps to push past that and I would really like to see just where the community is at right now, in general. Especially as a consultant because you come into a project and I don't necessarily know what to expect. I think on certain teams, I am always shocked I see like, "Oh, you're using beta and everything. You guys are on top of this. That's really cool. Let's do some feature [inaudible]," and you're really excited. But then other times, you get called in and they're like, "We're still using 1.13 and we have bind others in our source and could you please help us?" CHARLES: Right and it's just that mountain is just too big to cross. That's something that you see in software development as the tools that you use tend to change and for lack of a better word, rot over time. In comparison to what's more newly available, it's the phenomenon of JavaScript churn, which is known in the community at large, scope down to just one framework where you've got different versions of the framework and you've got this churn. It's been somatic for Ember to try and it has been very aggressive attacking this problem and yet still, it manages to happen. How does that work, just given the amount of attention? JONATHAN: Ember, hands down handles this better than most other JavaScript projects that I've seen. I've gone to old backbone apps throughout my career and knock out in Angular one, etcetera. I've seen the rot that we're talking about here and usually, once it gets too bad, the authors of the JavaScript libraries are unable to push it forward at all. Either band in it or end of life it and you're going to have to invest your own time to get pushed past this point. In Ember, it really strenuously disagrees with that philosophy. They try super hard. All the people in core and really the community at large, the philosophy is like, "No, we're not going to break Ember. Ember is very serious here. We're not going to leave people stranded," yet it still happens. The reason I'm curious about seeing it is really about how do we make that story like a solved problem. Is it possible to do? Is it possible for us to basically make it to where the Ember community can very honestly say, "If you choose us if you choose this framework, it will be around. There will be a path forward for you for five to ten years and that's not something you can get a promise from anywhere else." I just want to see what are the ways that we can make that promise more strong. I think, the LTS was a big step in that direction. I think that was actually last EmberConf which the LTS was announced? ROBERT: Yeah, absolutely. Definitely all of our clients have moved to LTS as rather than trying to do every six weeks because they find that much easier to upgrade in between and they're more stable. JONATHAN: They're more stable and I think it's such an easier sell like if you actually start talking about going up the pipeline and you're like, "I have to talk to my boss and my boss just to clear money. We have to clear time, etcetera." We're going to put a [inaudible] aside every six weeks to upgrade seems a little untenable for a lot of companies. I think for larger companies, it's sometimes okay because they're actually utilizing some of the edge features which is cool and I think that's a big thing. I feel like I have no real insight here but I feel like that's what LinkedIn kind of does, where they're usually pushing the boundaries because they're utilizing features like engines were first brought into LinkedIn. I think it kind of pushing it at the edge. ROBERT: If you have the new LinkedIn Ember app, if you will crack open the inspector, when I last looked, I think the beginning of this week, they had two beta versions deployed. The Ember data version, that was beta and actual Ember, it was beta. CHARLES: Usually large companies are associated with big lumbering end piece that are in terrible condition. That's actually a breath of fresh air. Shout out to LinkedIn. ROBERT: Ember Data is 2.12 canary and Ember is 2.10 Beta 2 patch so it looks like they have a patch version. JONATHAN: It doesn't surprise me that Data is being pushed. I think last I spoke to [inaudible] right around December, he was doing a lot of perf work on there so I think he's really pushing that pretty hard. There's a lot of really cool stuff like that and I feel like it kind of runs the game. You see the smaller teams who choose Ember for stability, they sometimes get stranded so I want to see if some survey data can probably correlate. You could correlate the size of your company to the version of Ember you're on. Maybe, we'll see some trends around if it does it mean that smaller companies have more difficult time pushing forward. That would actually be a little counterintuitive. I would expect that smaller companies would be able to push forward at a faster clip because they usually have to support fewer browsers, etcetera. It'd be interesting to see information like that because I think that promise for ease of upgrade and there will be a path forward, that's a big part of what makes Ember really appealing to me. Especially as a consultant for four years, you see so many projects. I don't ever really want to advocate a rewrite but we're going to have to spend a significant amount of time fixing this and it's because you went with Mootools or something. Everybody guess Mootools wasn't so bad. CHARLES: But the point is that you didn't go with a holistic solution so you basically had to write your own framework. JONATHAN: Yeah. ROBERT: Yeah, in Ember, it is a feature that you will not be left behind and you can upgrade. That is something that is really nice. I have upgraded a lot of Ember apps. JONATHAN: I think Mike North calls that the patchwork app application. It's not just like React apps where you have React-Redux and Preact and all of this other stuff that you kind of piece together and make your own little quilt and that's your application. But this also happened in Backbone. It happened in jQuery before that and it was just like take this thing, take that thing, then I have this custom quilt, which is not bad. There are some advantages -- pros and cons. CHARLES: Ember is giving you a blanket. JONATHAN: And it's going to be a comforter. It's going to probably all look the same and be right. ROBERT: My experience is I love Ember and I love the convention over configuration but whenever you hit that wall of the convention is actually getting in the way now, that is a very tall wall to scale in Ember. CHARLES: Yeah, I think the flip side of it is like you say, Rob because everything does have to mesh, because that blanket has to be one solid weave, it means that you've got a hole in the blanket, the surgery required to excise that hole and then patch it -- ROBERT: I love his metaphor. His metaphor is -- [Laughter] ROBERT: It's so good. CHARLES: It takes a lot of effort. ROBERT: Today, I'm quilting daily. CHARLES: That's right. Next topic, crochet. [Laughter] CHARLES: But, yeah in order to make that surgery on the blanket to mix metaphors, which I love to do so freely, you have to make that cut and then make sure that the weave is again, seamless. I think that takes a lot of thought, it takes a lot of effort and it takes a lot of time. It means that there are shiny things out there that you might not be able to have. I think, one of the ways that the community and the technology is mitigated is with the add-on ecosystem, which is very, very strong and allows you to riff and experiment and push those boundaries. But there are core pieces, things like the rendering engine, which can't really be modified or hooked with an add-on. They can but not in deeply fundamental ways or the templating. We saw that happened. There was a big kind of shift from first, the old handlebars to -- ROBERT: HTMLbars? CHARLES: HTMLbars and then Glimmer 2, which there's been a flurry of activity around there but that was definitely one area where there was a hard wall right now. I feel like for me it's around the handlebars itself. I would like to see that environment become more powerful because certainly, with the React Native work that we've been doing around here, you get to see just how simple like the JSX model is, React aside because like Vue, you can do with JSX. I think JSX is a separate technology. It's certainly integral to React but there are a lot of other frameworks now that are using just the JSX part for the templating. Seeing that there is real power in being able to have the functional programming aspects of JavaScript right there inside your templates. From my perspective, I think that in Ember, there's a wall there that needs to be scaled. ROBERT: To be clear to the Ember developers that are listening like us kind of advocating JSX, if you are having like, "No, that's a terrible idea. I hate JSX," I had that very exact reaction about a year and a half ago. If you go look at my Twitter feed, you would see me ranting about how much JSX is a bad idea. After I actually played with it, I'm on the opposite side. I think JSX is really awesome and I think there are things to learn from it. CHARLES: I definitely love having templates. I love having the separation. I like having it in a different file but at the same time, I don't want to lose sacrifice the power that comes. I think that for people who are kind of sitting on the fence or have played with it, if you actually are strict about not having side effects and things in your templates, it really is a great experience. I think there's a lot of people who have scars from doing ERB or liquid templates, where you can have all kinds of crazy side effects -- ROBERT: That's where my scars came from -- ERB. CHARLES: Yeah, I can show. I can roll up my sleeves. I will be like, "You see this? I got that back in aught-seven with an ERB app, where they were calling out to a service from inside the template." ROBERT: Setting the variable and modifying everything. CHARLES: Yeah. There's definitely that tradeoff. One of the things that is great about the Ember community in particular is when there is, it takes a while to generate the will to recognize that this is a major problem but then the solution that you do get does, eventually match the weave of the entire blanket, which is really, really nice. But it can be frustrating when you have those core pieces of infrastructure that are presenting those walls to you. ROBERT: I'm excited for Angle Bracket components because that's actually a lot of the gripes that I had with handlebars. Whenever I got a bunch of the curlies next to each other, like a bunch of components around each other, they all kind of just mold together and seeing the brackets and just looking like HTML, it makes it so much easier to grip. CHARLES: Yeah, it's weird because you think that small things won't have big impact and you think that big changes ought to have a big impact. An example of this, I was kind of derisive of the whole Angle Brackets syntax. I was like, "Urgh! Angle Brackets, dah-dah-dah..." Then we started doing more JSX and you start seeing like, "I want to have my templating construct separate from my JavaScript and scripting constructs," and it actually makes a huge difference in clarity there. Obviously, the change to make all that happen is big but it's a small difference in the syntax. Tiny but I think it has a huge impact in the readability and the clarity of the templates and by the same token, all the performance increases. At this point, I couldn't even give a flip. It's nice. It's great but there's a barrier, there's a threshold that has been crossed, actually some time ago. Performance of rendering is -- I can't even remember the last time it was a problem. What about you? Have you run up against performance issues in your Ember apps? JONATHAN: Some performance issues but usually, they're a result of some rather inefficient rendering. Basically, a combination between user and keyboard or whatever. I wrote something really bad. It's not Ember getting in my way. I don't particularly mind the curly braces within my template but I think a big part of that is just editor choice. If your editor syntax highlights then it also knows how to indent handlebars correctly, that makes a huge difference. ROBERT: Are we about to start an Emacs versus Vim war here? [Laughter] JONATHAN: No, as a matter of fact, I suspect you would win that when the Vim -- there's no good solution for indentation in handlebar templates that I found in Vim. If anyone knows that [inaudible], "Oh, there's one plugin," please ping me on Twitter because that would be nice. CHARLES: Well, yeah. It's true. I can deal with it. I don't think it bothers me quite as much as it does Rob but I think what has been interesting is in our hypothetical code, you always like pay snippets in Slack. We started using Angle Bracket syntax just because it's so much clearer. Even though, none of us actually use it in any of our apps, when we're actually exchanging ideas, that's what we use. JONATHAN: Yeah, there's some cool things that come with Angle Brackets that aren't just aesthetic. The container element is like you don't have to deal with the tag lists stuff anymore. I feel like there's a few tradeoffs that are going to be really interesting to see when those start becoming the norm. CHARLES: Yeah, I like also the separation of what they did from JavaScript attributes to HTML attributes. It's really clear. JONATHAN: Totally. I think it's [inaudible] cool stuff. CHARLES: It's exciting. I remember being derisive of it -- not divisive, that's not the right word -- but I'm thinking like, "Why are they spending so much time on this," but I actually think it is going to have a big impact, small change. JONATHAN: Totally. CHARLES: No dis to the people who are working on it. I know it doesn't feel like a small change at all. ROBERT: Yeah, it only took a year and a lot of really hard work. [Laughter] ROBERT: Like I peek in there and I'm like, "Hmmm... Nope, not smart enough yet." CHARLES: One of the things that I want to ask you, you mentioned that at SO Ember, you gave a talk on FastBoot. You've actually got a lot of experience around the subject so I'm just curious. First of all, what were you talking about? JONATHAN: I think my talk was actually called Boots and Shoeboxes, which there's a little library function into the FastBoot suite called the Shoebox where you can communicate between node and the browser. It's not like well-known enough to where that title resonated with people. I got up on stage and I was like, "You know, we don't have any descriptions on the speaker note like website. He just talks about FastBoot. I hope that I don't disappoint you," because they had no idea what I was talking about. Actually, I feel like the problem that's the FastBoot solves is a persistent thorn in people sides. CHARLES: So what is the problem just to give full context? I think is it called like Isomorphic JavaScript for something -- JONATHAN: Yeah, I don't like using that word. CHARLES: Yeah, there's like server side, SSR -- JONATHAN: Yeah, SSR, you'll see that a lot. CHARLES: I guess the question is why would you even? JONATHAN: That's a multi-faceted question. I think the first section of it would be what's the problem? I think for a lot of people, the biggest problem is SEO. A lot of JavaScript frameworks are not search engine friendly, then that affects a lot of different things. It means that they're not archivable either so it's not like you can have this on archive. They're not very crawable. This is becoming less of an issue because Google Crawler, for instance will actually parse JavaScript now. But I feel like that's still limited. Also you have to then think about how the Crawler is going to like actually execute your JavaScript. You're like, "Wait a second, so now I have to have a compatibility table for Google Crawler? That sounds madness." I think that's a big component. There's also the idea of speed downloading as low as poor connectivity devices or locations, I guess. Having to download all the JavaScript before you see the first meaningful thing is not a very good experience. Especially for a huge swaths of different types of sites like Discourse, I think is a big Ember forum software. Forums are mostly just static text, like you just want to read the text so time in First Meaningful Paint could be like as soon as you get text onto the page, that's could be really fast. Some sites that doesn't make sense for it like if you're posting a video game or something like that, like you need interaction for that site to be meaningful. There's still tradeoffs there but there's a whole host so I guess that's the need. Then the solution for a lot of people is to start rendering JavaScript on their backend software and presenting full HTML along with a JavaScript source tag so that you get a Meaningful Paint first and then you get the JavaScript a little afterwards. The whole point of my talk, which I was basically like -- CHARLES: That's a hard problem. JONATHAN: Oh, it's a very difficult problem. CHARLES: Unlike anyone who says they have a solution, you should look at them with extreme mistrust. JONATHAN: Yeah and there's a whole bunch of different solutions that people have tried. You could actually have prerender.io, I think is the service that will actually render it for you and you put it in front of your CDN and they'll actually do that and create static files for you, which is a solution or no script tags. You basically render all of your stuff as much as you can on the server side and you put everything into no script tags and that will presents its own problems. There's a bunch of different solutions that people have tried. In FastBoot, the solution that Ember went with and I think that it's really cool because server side rendering and this is the big reveal of my talk. I think it's recorded so you can check it out. But the bigger reveal is that the server side rendering is not just about rendering. It's also about routing and data fetching and authentication and etcetera. There's a whole bevy of things that you also have to handle very well. It's not just taking a component, the view layer to component and rendering it to HTML and then serving that. It's much more than that. You want your app to basically run in node. FastBoot does that remarkably well. There are some spots where it's a little fuzzy but does it remarkably well. CHARLES: What's an example of how you would might need to handle authentication? That sounds terrible. ROBERT: One of the problems for a lot -- JONATHAN: That's exactly the problem. You actually have access to headers and stuff and FastBoot land so you can do authentication by using traditional token off, which is pretty cool. There's a lot of really cool things and routing is obviously handled quite well so the request comes in and it does the normal Ember router. The Ember app instance itself is running in node so all of the things you expect to work in the browser, work in Ember and node, with the exception of any time you need to access the DOM because the DOM is expensive like very, very, very oddly expensive. Like JSDOM is just expensive and unreliable, then you have to deal with compatibility tables for that. Anyone who has written tests for Phantom and tried to bind a function or something, they know the pain. I think it's fix now but I was always bitten by that so many times. It doesn't even give you the right error. Forget about it. CHARLES: You have all these things. It's basically authentication. It's data. It's making sure that you have in your, so to speak, headless environment as an authentic replica of your application running in the user's browser, as you can possibly retain. JONATHAN: Yeah. CHARLES: How feasible is that? Like what you're saying is that Ember takes that whole approach and says, "Okay, we're going to make sure we handle all of these cases?" JONATHAN: Yeah, I think Ember has done a phenomenal job of this. It's still alpha software, although I believe that the path to 1.0 is basically paved. It just needs some documentation. I think FastBoot hits the nail right on the head and gets a lot of the stuff really in a good place. It's also a big part of FastBoot's call to action where this stuff is possible elsewhere. You can do all of these things. You can make all of the stuff work in the React ecosystem or Vue ecosystem, etcetera. But in Ember, it's Ember install, Ember FastBoot, I think or Ember CLI FastBoot which is a really compelling sell because I've looked at some of the alternative approaches and in other ecosystems, they're very complicated. It's not possible. It's just their ad hoc -- ROBERT: And it's usually a 10,000 line medium posts that you have to follow line by line -- [Laughter] CHARLES: Right so instead of giving you actually a working code, what you get is a treasure map. JONATHAN: Yeah, exactly. It's like you just shop at Ikea. Here you go, build it. There's some really cool stuff that it unlocks and the fact that it's so low-hanging fruit, for instance Ember Weekend, which by all accounts does not need to be on FastBoot, isn't on FastBoot because it's ostensibly free and it's a good testing ground for me to learn about FastBoot. But the future -- ROBERT: It's interesting in handling audio on a FastBoot, how was that? JONATHAN: Since the user doesn't actually can't listen in node land, the user can only listen in a browser, we don't do anything with the player in FastBoot land, which is fine. There are some weird things like you have to basically have guards around like key events, for instance. Because Mousetrap relies on, I believe in jQuery to bind its events, you have to basically say, "In node land, we're not going to bind any of these Mousetrap events because they will not work," but there are some things you have to learn about the ecosystem but by and large, it's a solution that you just drop in and you just get for free. I think that's a huge sell. That's another thing with the convention over configuration argument, the model is that eventually, once the solution arrives, most of the people who are using Ember can just use it right away. It really does help with [inaudible] activity devices. There are some really interesting things about how time to first paint, I think Martin [inaudible] just released an add-on that basically says, "I'm going to take all of your JavaScript files and mark them as async and then when you download, the time to first paint becomes almost immediate," because it's just going to say, "I have HTML. Here's the HTML and serve it." Then in the background, because of script tags or whatever, it just goes and fetches the stuff in the background and you end up like time to First Meaningful Paint is really cool so it'll perform software that is super neat. If Discourse wanted to say, "Here's the stuff and we're going to make it work later," like as soon as the JavaScript has download, that's a really cool sell too. There's a lot of weird edge cases and describing the interactions is I think the hardest part about FastBoot. It's just like describing why this might be really good for you is the hardest part because a lot of people don't have these problems. If you're doing a marketing site, you're probably going to use Squarespace or something. ROBERT: Yeah, like a static site generator or something? JONATHAN: Yeah, exactly. ROBERT: Something that will give you great SEO results. JONATHAN: Exactly. ROBERT: You want to play around with that. JONATHAN: This dovetails into something Edward Faulkner was talking about eight or nine months ago when he was working on the inline content editor for Ember. It's really, really neat. I actually like to see where that's at now. I think it was Cardstack that funded a lot of the stuff for it. But if you combine things like that, then also FastBoot, you're starting to talk about something that could do what WordPress does, which is a really interesting thing like the really, really low hanging fruit. Type these few commands and you're point clicking your way to a website which is really, really cool. CHARLES: All right everybody, thank you so much for listening. Thank you, Jonathan for coming on by and talking with us today. JONATHAN: Yeah, thank you so much for having me on. This podcast is super awesome. I'm really excited to actually be able to be a part of it. I feel like you are at Ember Weekend that one time and you were in Norway? CHARLES: Finland. JONATHAN: Yeah, Finland and we weren't able to actually have a video open at the same time because of the data problem. It's been actually kind of cool to actually have a real conversation. That's been really great. CHARLES: Yeah, that has been awesome. That was a good conversation and that, your podcast obviously is EmberWeekend.com. Everybody go and check it out. Thanks for listening.

In which I talk with Zouhir Chahoud, the creator of Preact Habitat.

As we look forward to all the great trends and changes that will happen in 2017, in this episode we discuss our thoughts and opinions on the various development trends and notable things that happened in 2016. Looking forward on 2017, we share some of the things we’re excited to see in the new year. Items mentioned in the episode: Preact, React, Inferno, Vue JS, Ember, Angular, Box, Yarn JS, Firefox, Mozilla, Microsoft, Edge, Chakra, Visual Studio Code, Flexbox, CSS Grid, IE, TypeScript, Elm, Flow, Webpack, Progressive Web Apps, React Native, Babel, Redux, WebKit, ES6, Safari, Apple AirPods, Apple MacBook Pro, iPhone 7, Service workers, Web workers, Apple Pay, WebVR, React VR, WebAssembly, Dear JavaScript, OpenSSL, Wearables, Brexit, 2016 US Election, SMACSS, BEM, PostCSS, CSS Houdini, Net Neutrality, Netflix, Atom, Sublime Panelists: Ryan Burgess - @burgessdryan Jem Young - @JemYoung Ryan Anklam - @bittersweetryan Brian Holt - @holtbt Mars Jullian - @marsjosephine Stacy London - @stacylondoner Picks: Ryan Burgess - Electric Objects Frame Ryan Burgess - 2017 conference list Jem Young - Travelers Jem Young - Everyone Ryan Anklam - VIM - devicons Ryan Anklam - Runner’s World Podcast Brian Holt - Run The Jewels 3 Brian Holt - Fish Shell Mars Jullian - React Status Mars Jullian - Frontend focus Stacy London - Nuclide Stacy London - Yarn

On this episode we discuss the following topics: - Recent acquisitions in Europe, including Spotify's purchase of Preact and Foodpanda's sale of Delivery Club to Mail.Ru - A new European venture fund called KEEN Ventures - Several rounds of funding including Unbabel, Otonomo and Second Home - Jonathan Keane had a chance to catch up with Italian cloud company ClouDesire - We discuss the Brexit effect on prices of products and services from Apple, Microsoft, HTC, Dell and Amazon For information regarding your data privacy, visit acast.com/privacy

Preact is a fast, tiny alternative to React that shares its ES6 API. In this episode, we chat with the author of Preact, Jason MillerFollow us on Twitter

Brent Leary Interviews Ujjal Kohli From Preact by Brent Leary and Small Business Trends