Concludes with the implementation phase where the selected approach is detailed out, emphasizing the importance of revisiting and possibly revising strategic decisions based on practical considerations during implementation. "we thought we were going to do this and we didn't find a way to implement so that wasn't going to be too much work."

The use of decision matrices and structured design processes encourages reflective thinking and abstraction, leading to more innovative and effective solutions. "you're starting to do abstraction...if you do this during the day I promise you you're going to get new ideas when you hit the hammock or the bed"

Discusses how a decision matrix helps maintain a clear focus on the problem, facilitates shared understanding, and drives thoughtful examination of each potential solution. "you're going to have shared understanding...you're going to be able to say I don't think you're saying that right."

Advises against subjective judgments within the matrix, recommending the use of color coding to visually represent the evaluation of each criterion. "use colors...to show subjectivity."

Stresses the selection of relevant and salient criteria for evaluating approaches, differentiating between merely describing features and critically analyzing their implications. "you want things that are salient or relevant."

Details on how to set up a decision matrix, emphasizing the importance of clearly defining the problem in cell A1 and using the subsequent columns and rows to evaluate different approaches against defined criteria

Introduces the decision matrix as a critical tool for evaluating different approaches, using a live-editing spreadsheet format to facilitate collaborative design. "what is a decision matrix it's a spreadsheet that more than one person can see at the same time and edit at the same time."

Highlights the process of creating use cases focused solely on user intentions, leaving out the implementation details for later phases. "the best first phase for use cases is to talk about only what people intend to accomplish."

Emphasizes the need to explore different strategies (e.g., automated solutions versus tools for users) to address user objectives more effectively. "you're then going to start thinking about what are the ways that you could possibly address it."

Strategy is defined as determining the direction, focusing on user intentions and potential approaches to meet those intentions without specifying how they will be achieved initially. "strategy means to be a general or to lead and fundamentally it means about where are you going."

The speaker discusses the importance of distinguishing between strategic direction setting and tactical implementation decisions in design, particularly for larger projects

• you're going to be able to modify the top story title to try to make it about the problem
• the other thing you're going to do is you're going to now add another thing to that top story you had the title description now you're going to have that problem statement

Covers the transition from identifying and understanding design problems to formulating solutions, emphasizing the necessity of a clear, succinct problem statement in this process.

Describes the 'top story' as a pivotal part of project management in design, which synthesizes understanding and outlines the plan forward. "you need to have a ticket that says this is what the overarching plan is."

Explains the concept of reflective inquiry where questioning one's own thoughts helps advance understanding in design. "reflective inquiry... helps you think it also helps agendaize your background thinking."

Introduces the Socratic method as a tool for probing and understanding through structured inquiry, which helps uncover underlying truths about design challenges.

Discusses the strategic use of questions to clarify goals and intentions in the design process, promoting a deeper exploration of problems

Recommends creating a glossary to consistently define and use terms, enhancing understanding within teams

Advocates for precise use of language to avoid ambiguity and ensure that design intentions are clearly communicated and understood.

• Be percise about the meaning
  • Builds better understanding (of differences and similarities)
• Keeps everyone on the same page => better collaboration

Stresses the role of writing in design, not for documentation, but as a tool to visualize and refine ideas collaboratively: * Forces us to concrete thoughts * Allow us to not lose threads * Allow us to share our thoughts

Emphasizes that design is not a magical skill but involves concrete, learnable practices that enhance team-based software development.

Transformers give Clojurists some of the benefits of "Object Orientation" without many of the downsides Clojurists dislike about objects.

1. Objects couple behaviors required from multiple callers into a single class, while transformers do not change existing behaviors for existing callers by default
2. Objects push inheritance first design, whereas transformer inheritance is a function of shared structure between Clojure data structures derived from one another and design is driven by concrete implementation needs, like regular Clojure
3. Objects couple state and methods in spaghetti ways and transformers are just immutable maps. And just like how Clojure lets you stash stateful things like atoms in functions, transformers allow you to build stateful transformers, but like Clojure the default convention is to do everything immutably
4. Objects try to provide data hiding as a function of encapsulation whereas transformers are doing the opposite, exposing data otherwise hidden by a closure

There are many strategies for reusing code in the software industry. In Clojure, we use what some call a "lego" method of building small, single purpose functions that just can be used in a million different contexts, because of a tasteful use of simplicity in the right places. This works tremendously well for 95% of use cases. In certain use-cases, like for building hierarchies of functions that are highly self-similar, like with UI toolkits, transformers provide a better alternative.Transformers allow you to build a UI toolkit with 25% the code of normal function composition and 25% of the code required for evolution over time for the widgets in that hierarchy. The lego method is great for vertically composing things together, but when you want to make lateral changes for only certain callers in the tree, you have to defensively copy code between duplicative implementation trees and just call them "grandpa-function-1" and "grandpa-function-2" and then make versions 1 and 2 for all functions that wrapped the grandpa-functions afterwards. Transformers provide a solution for that situation, in the rare cases we end up in them in Clojure, without the downsides of a traditional object system.

• Concise expression of application logic
• Actually being incremental
• Tab focusing
• Simple types
• Simple control flow
• Overall system complexity

Summary of Raph Levien's Blog: "Towards principled reactive UI"

Introduction

• Diversity of Reactive UI Systems: The blog notes the diversity in reactive UI systems primarily sourced from open-source projects. Levien highlights a lack of comprehensive literature but acknowledges existing sources offer insights into better practices. His previous post aimed to organize these diverse patterns.
  • "There is an astonishing diversity of 'literature' on reactive UI systems."

Goals of the Inquiry

• Clarifying Inquiry Goals: Levien sets goals not to review but to guide inquiry into promising avenues of reactive UI in Rust, likening it to mining for rich veins of ore rather than stamp collecting.
  • "I want to do mining, not stamp collecting."

Main Principles Explored

• Observable Objects vs. Future-like Polling: Discusses the importance of how systems manage observable objects or utilize future-like polling for efficient UI updates.
• Tree Mutations: How to express mutation in the render object tree is crucial, focusing on maintaining stable node identities within the tree.
  • "Then I will go into deeper into three principles, which I feel are critically important in any reactive UI framework."

Crochet: A Research Prototype

• Introduction of Crochet: Introduces 'Crochet', a prototype exploring these principles, acknowledging its current limitations and potential for development.
  • "Finally, I will introduce Crochet, a research prototype built for the purpose of exploring these ideas."

Goals for Reactive UI

• Concise Application Logic: Emphasizes the need for concise, clear application logic that drives UI efficiently, with reactive UI allowing declarative state expressions of the view tree.
  • "The main point of a reactive UI architecture is so that the app can express its logic clearly and concisely."
• Incremental Updates: Advocates for incremental updates in UI rendering to avoid performance issues related to full re-renders, highlighting the limitations of systems like imgui and the potential of systems like Conrod, despite its shortcomings.
  • "While imgui can express UI concisely, it cheats somewhat by not being incremental."

Evaluation of Existing Systems

• Comparison with Other Systems: Mentions SwiftUI, imgui, React, and Svelte, discussing their approaches to handling reactive UI and their adaptability to Rust.
  • "SwiftUI has gained considerable attention due to its excellent ergonomics in this regard."

Technical Challenges and Proposals

• Challenges in Tree Mutation and Stable Identity: Discusses the challenges in tree mutation techniques and the importance of stable identity in UI components to preserve user interaction states.
  • "Mutation of the DOM is expressed through a well-specified and reasonably ergonomic, if inefficient, interface."

Conclusion and Future Work

• Future Directions and Experiments: Encourages experimentation with the Crochet prototype and discusses the ongoing development and research in making reactive UIs more efficient and user-friendly.
  • "I encourage people to experiment with the Crochet code."

This blog post encapsulates Levien's ongoing exploration into developing a principled approach to reactive UI in Rust, highlighting the complexity of the task and his experimental prototype, Crochet, as a step towards solving these challenges.

Summary of "Towards Principled Reactive UI" by Raph Levien (September 25, 2020)

• Introduction and Motivation:

  • Levien revisits the topic of reactive UI in Rust, building on his previous work to further explore efficient expression methods in the context of Rust's capabilities and limitations.
  • Discusses the diversity of reactive UI frameworks and the potential for adopting successful concepts from existing systems without needing to create an entirely new framework.
  • "It is not the intent of this post to provide a comprehensive review of the literature" – Indicates a focus on identifying promising techniques rather than exhaustive cataloging.

• Goals for Reactive UI Systems:

  • Emphasizes the need for concise expression of application logic, with references to various frameworks like SwiftUI and imgui that have addressed this in differing ways.
  • Highlights the necessity of incremental updates to UI elements, criticizing some approaches like imgui for not truly being incremental.
  • Discusses challenges such as implementing tab focusing and handling simple types within the UI toolkit, pointing out the difficulties faced by frameworks like Iced in these areas.

• Principles for Building Reactive UI Frameworks:

  • Identifies three critical principles for any reactive UI framework: use of observable objects, expression of mutations in the render object tree, and stable identity of nodes within that tree.
  • Questions the standard use of observable objects due to their complexity and potential inefficiency, especially in a Rust context.
  • Advocates for a system where UI logic can trigger re-computation without requiring detailed context about what changed, potentially borrowing concepts from Rust's async infrastructure.

• Introduction of Crochet Prototype:

  • Introduces Crochet, a research prototype designed to explore and implement the principles discussed.
  • Crochet aims to simplify the reactive UI model by not relying on observables and using a simpler system for tracking UI changes.
  • Discusses potential advantages of Crochet, such as better integration with Rust's async features and a simpler approach to handling UI mutations.

• Comparative Analysis with Other Frameworks:

  • Compares Crochet's approach to other frameworks like Jetpack Compose and imgui, highlighting differences in handling actions from widgets and mutations within the UI tree.
  • Describes Crochet's approach to avoiding recomposition from the root for performance efficiency and its potential impact on the development of reactive UIs in Rust.

• Closing Thoughts and Future Directions:

  • Levien encourages experimentation and feedback on the Crochet prototype to refine and validate the proposed principles.
  • Notes ongoing discussions and contributions from the community that influence the development of Druid and Crochet.

Concluding Insights:

• This blog post represents Levien's ongoing efforts to refine the theoretical foundations and practical implementations of reactive UI frameworks in Rust, highlighting new research directions and the introduction of the Crochet prototype as a platform for further exploration and development.

Summary of the Talk on the Future of Web Frameworks by Ryan Carniado

• Introduction and Background:

  • Ryan Carniado, creator of SolidJS, has extensive experience in web development spanning 25 years, having worked with various technologies including ASP.NET, Rails, and jQuery.
  • SolidJS was started in 2016 and reflects a shift towards new paradigms in web frameworks, particularly in the front-end JavaScript ecosystem.
  • Quote: "I've been doing web development now for like 25 years... it wasn't really until the 2010s that my passion reignited for front-end JavaScript."

• Core Themes and Concepts:

  • Modern front-end development heavily relies on components (e.g., class components, function components, web components) which serve as fundamental building blocks for creating modular and composable applications.
  • Components have runtime implications due to their update models and life cycles, influencing the performance and design of web applications.
  • Traditional component models use either a top-down diffing approach (like virtual DOM) or rely on compilation optimizations to enhance performance.
  • Quote: "Modern front-end development for years has been about components... however, in almost every JavaScript framework components have runtime implications."

• Reactive Programming and Fine-Grained Reactivity:

  • Ryan advocates for a shift towards reactive programming to manage state changes more efficiently. This approach is likened to how spreadsheets work, where changes in input immediately affect outputs without re-execution of all logic.
  • Fine-grained reactivity involves three primitives: signals (atomic atoms), derived state (computeds or memos), and side effects (effects). These primitives help manage state and side effects without heavy reliance on the component architecture or compilation.
  • Quote: "What if the relationship held instead? What if whenever we changed B and C, A also immediately updated? That's basically what reactive programming is."

• Practical Demonstration and Code Examples:

  • Ryan demonstrated the implementation of fine-grained reactivity using SolidJS, showing how state management and updates can be handled more efficiently compared to traditional methods that rely heavily on component re-renders and hooks.
  • The examples provided emphasized how reactive programming can simplify state management and improve performance by only updating components that need to change, reducing unnecessary re-renders.
  • Quote: "The problem is that if any state in this component changes, the whole thing reruns again... what if we didn't? What if components didn't dictate the boundary of our performance?"

• Performance Implications and Advantages:

  • The "reactive advantage" in SolidJS and similar frameworks lies in their ability to run components minimally, avoiding stale closures and excessive dependencies that can degrade performance.
  • Ryan highlighted that in reactive frameworks, component boundaries do not dictate performance; instead, performance optimization is achieved through smarter state management and reactive updates.
  • Quote: "Components run once... state is independent of components. Component boundaries are for your sake, how you want to organize your code, not for performance."

• Future Directions and Framework Evolution:

  • The talk touched on the broader impact of reactive programming and fine-grained reactivity on the evolution of web frameworks. This includes the potential integration with AI and compilers to further optimize performance and developer experience.
  • Ryan suggested that the future of web development might see more frameworks adopting similar reactive principles, possibly leading to a "reactive renaissance" in the industry.
  • Quote: "A revolution is not in the cards, maybe just a reactive Renaissance."

• Q&A and Additional Insights:

  • During the Q&A, Ryan discussed the potential application of SolidJS principles in environments like React Native and native code development, indicating the flexibility and broad applicability of reactive programming principles across different platforms and technologies.
  • Quote: "The custom renderer and stuff is not something you need a virtual DOM to... the reactive tree as it turns out is completely independent."

Summary of "Xilem: An Architecture for UI in Rust" by Raph Levien (May 7, 2022)

• Introduction and Motivation:

  • Levien introduces Xilem as a new UI architecture specifically tailored for Rust, addressing the unique challenges posed by Rust's aversion to shared mutable state.
  • The architecture aims to combine modern reactive and declarative UI paradigms in a way that is idiomatic to Rust, learning from the limitations of previous architectures like Druid and other Rust UI projects.
  • "Rust is an appealing language for building user interfaces for a variety of reasons, especially the promise of delivering both performance and safety" – Explains the motivation behind developing a Rust-specific UI framework.

• Xilem Architecture Overview:

  • Xilem leverages a view tree for declarative UI descriptions, supports incremental updates through diffing, and features an innovative event dispatch system using id paths.
  • Introduces Adapt nodes, an evolution of the lens concept from Druid, allowing for better composition by managing mutable state access between components.
  • "Like most modern UI architectures, Xilem is based on a view tree which is a simple declarative description of the UI" – Describes the core structural concept underpinning Xilem.

• Comparison with Existing Architectures:

  • Levien critiques existing architectures like immediate mode GUI, The Elm Architecture, and React adaptations in Rust, identifying their limitations in the context of Rust's programming model.
  • Highlights the challenges with integrating asynchronous operations and complex state management in existing systems.
  • "Another common architecture is immediate mode GUI, both in a relatively pure form and in a modified form" – Discusses how Xilem addresses deficiencies in these models.

• Innovative Features of Xilem:

  • Xilem's event handling distinguishes itself by not relying on shared mutable state but instead uses a path-based dispatch system to manage state mutations.
  • The architecture supports highly granular change propagation and efficient state management through features like memoization nodes and adaptive state nodes.
  • "The most innovative aspect of Xilem is event dispatching based on an id path, at each stage providing mutable access to app state" – Highlights the unique approach to event handling in Xilem.

• Challenges and Future Directions:

  • Discusses potential areas for further development, including multithreading support, fine-grained change propagation, and integration with dynamic languages through Python bindings.
  • Expresses interest in exploring other domains like text-based user interfaces (TUI) or adapting Xilem principles to web-based environments.
  • "We haven’t yet built up real UI around the new architecture" – Acknowledges that Xilem is still in the conceptual stage and requires practical validation.

Concluding Insights:

• Xilem represents Levien's ongoing efforts to refine UI architecture in Rust, addressing the specific challenges posed by Rust's language features while embracing the principles of modern UI design. This architecture aims to provide a robust foundation for building intuitive, high-performance, and safe user interfaces in Rust, encouraging feedback and experimentation to validate and expand its capabilities.

Summary of "Xilem: an architecture for UI in Rust" from raphlinus.github.io

• Motivation for Xilem: Existing UI architectures in Rust like Druid face limitations due to Rust's avoidance of shared mutable state, making them a poor fit for conventional UI systems. Xilem aims to provide an architecture better suited to Rust's paradigms, inspired by existing works and innovations specific to UI needs.

  • "However, finding a good architecture is challenging... Rust is a poor fit for UI."

• Design Goals and Influence: Xilem seeks to blend modern UI design principles such as reactive and declarative UIs with Rust's emphasis on performance and safety. It draws inspiration from SwiftUI, Flutter, and React.

  • "The goals include expression of modern reactive, declarative UI, in components which easily compose, and a high performance implementation."

• Core Components of Xilem:

  • View Tree and Widget Tree: Utilizes a declarative view tree for UI description, which is diffed against its successive versions to update a more traditional widget tree. This setup helps manage UI state and changes efficiently.
    • "Xilem is based on a view tree which is a simple declarative description of the UI."
  • Incremental Computation: At its core, Xilem incorporates an incremental computation engine that optimizes UI updates and event handling.
    • "Xilem also contains at heart an incremental computation engine with precise change propagation, specialized for UI use."
  • Event Dispatching: Introduces an innovative event dispatching mechanism using 'id paths', allowing mutable access to app state throughout the component hierarchy.
    • "The most innovative aspect of Xilem is event dispatching based on an id path."

• Comparative Analysis:

  • Druid and Immediate Mode GUI: Xilem addresses challenges like static vs dynamic widget hierarchies and complex state management seen in Druid and immediate mode GUIs.
    • "The existing Druid architecture has some nice features, but we consistently see people struggle with common themes."
  • Elm Architecture and React-like Implementations: Discusses the limitations of message dispatch in Elm and the adaptation challenges of React patterns in Rust.
    • "The Elm documentation specifically warns against components, saying, 'actively trying to make components is a recipe for disaster in Elm.'"

• Technical Implementation:

  • Example: Uses a simple counter to demonstrate the declarative construction of UI and event handling within Xilem, showing how the architecture supports mutable access to app state without the typical challenges of Rust.
    • "fn app(count: &mut u32) -> impl View<u32> { ... }"
  • Identity and Event Propagation: Explains the use of stable identities and id paths for event propagation, which is crucial for maintaining state consistency across UI updates.
    • "A specific detail when building the widget tree is assigning a stable identity to each view."

• Future Directions and Integration:

  • Async Integration: Discusses the potential integration of asynchronous operations, which are crucial for responsive UIs.
    • "Async and change propagation for UI have some common features, and the Xilem approach has parallels to Rust’s async ecosystem."
  • Environmental and Threading Considerations: Outlines plans for handling environment settings and multithreading, which could enhance performance and scalability.
    • "Another very advanced topic is the ability to exploit parallelism (multiple threads) to reduce latency of the UI."

The post concludes by acknowledging the conceptual stage of Xilem, inviting feedback, and highlighting its potential application across various UI domains.

Summary of "Towards a Unified Theory of Reactive UI" by Raph Levien (November 22, 2019)

• Overview and Motivation:

  • Levien explores various reactive UI frameworks to develop a cohesive understanding and communicate effective strategies for the Druid UI system.
  • Reactive UI allows UI construction and updates to be more intuitive and less redundant compared to traditional object-oriented approaches.
  • "My own main motivation for exploring reactive UI is primarily because the object-oriented idioms don’t translate well to Rust" – This highlights the shift towards reactive UI due to language and paradigm limitations in Rust concerning ownership and callbacks.

• Theoretical Framework and Tree Transformations:

  • Reactive UIs fundamentally involve transforming UI component trees across various stages: user data → widget tree → render object tree → draw tree.
  • Levien discusses tree representation either as a data structure or as an execution trace, both impacting how UI transformations are managed.
  • "The main theoretical construct is that reactive UI is at heart a pipeline of tree transformations." – This signifies the central role of managing UI component hierarchies through transformations.

• Diversity in Framework Implementations:

  • Despite common goals, implementation details in reactive UI frameworks vary significantly, influencing how application state is managed and updated.
  • Differences are often seen in how these frameworks handle state, incremental updates, and dependency tracking.
  • "The details of implementation still seem wildly divergent." – Points to a lack of standardization in implementing reactive principles across different systems.

• Incremental Transformations and Diffing:

  • Emphasizes the importance of incremental updates in UI frameworks to minimize the performance costs of updating UI states.
  • Discusses strategies like diffing, which involves comparing new and old UI trees to determine necessary updates.
  • "One of the fundamental goals of a UI framework is to keep the deltas flowing down the pipeline small." – Highlights the challenge of efficiently propagating changes through the UI system.

• Push vs. Pull Interfaces in UI Frameworks:

  • The distinction between push and pull interfaces in managing data flow through UI systems is crucial, with many systems using hybrid approaches.
  • "Pulling from a tree basically means calling a function to access that part of the tree." – Describes how data is retrieved or updated in UI components.

• Case Studies and Examples:

  • Provides insights into specific UI frameworks like Druid, Imgui, Flutter, Jetpack Compose, and React, each illustrating unique approaches to tree transformations and state management.
  • These examples highlight the practical applications of theoretical concepts discussed throughout the blog.

• Future Directions and Academic Gaps:

  • Levien seeks further discussion and academic input to refine these theories and potentially translate them into systematic, robust UI development practices.
  • "I’m also curious if there’s good academic literature I’m missing." – Shows an openness to expanding the theoretical underpinnings of reactive UI based on community and academic feedback.

Concluding Thoughts:

• Raph Levien’s exploration into reactive UI frameworks is a deep dive into understanding and characterizing the diverse implementation strategies that exist, aiming to refine and communicate effective methods for building reactive user interfaces, particularly in the context of systems like Druid that utilize Rust’s programming paradigm.

Here is a detailed summary of the article "Super Charging Fine-Grained Reactive Performance" by Milo:

1. Introduction to Reactivity in JavaScript

   • Definition and Importance: "Reactivity allows you to write lazy variables that are efficiently cached and updated, making it easier to write clean and fast code."
   • Introduction to Reactively: "I've been working on a new fine grained reactivity library called Reactively inspired by my work on the SolidJS team."

2. Characteristics of Fine-Grained Reactivity Libraries

   • Library Examples and Usage: "Fine-grained reactivity libraries... Examples include new libraries like Preact Signals, µsignal, and now Reactively, as well as longer-standing libraries like Solid, S.js, and CellX."
   • Functionality and Advantages: "With a library like Reactively, you can easily add lazy variables, caching, and incremental recalculation to your typescript/javascript programs."

3. Core Concepts in Reactively

   • Dependency Graphs: "Reactive libraries work by maintaining a graph of dependencies between reactive elements."
   • Implementation Example: "import { reactive } from '@reactively/core'; const nthUser = reactive(10);"

4. Goals and Features of Reactive Libraries

   • Efficiency and State Consistency: "Efficient: Never overexecute reactive elements... Glitch free: Never allow user code to see intermediate state where only some reactive elements have updated."

5. Comparison Between Lazy and Eager Evaluation

   • Evaluation Strategies: "A lazy library... will first ask B then C to update, then update D after the B and C updates have been completed."
   • Algorithm Challenges: "The first challenge is what we call the diamond problem... The second challenge is the equality check problem."

6. Algorithm Descriptions

   • MobX: "MobX uses a two pass algorithm, with both passes proceeding from A down through its observers... MobX stores a count of the number of parents that need to be updated with each reactive element."
   • Preact Signals: "Preact checks whether the parents of any signal need to be updated before updating that signal... Preact also has two phases, and the first phase 'notifies' down from A."
   • Reactively: "Reactively uses one down phase and one up phase. Instead of version numbers, Reactively uses only graph coloring."

7. Benchmarking Results

   • Performance Observations: "In early experiments with the benchmarking tool, what we've discovered so far is that Reactively is the fastest."
   • Framework Comparisons: "The Solid algorithm performs best on wider graphs... The Preact Signal implementation is fast and very memory efficient."

This summary encapsulates the key concepts, methodologies, and findings presented in the article, focusing on the innovations and performance of various fine-grained reactivity libraries, especially the newly introduced Reactively.

Is Big-Data about storage and joins? Or is it about computing efficiently over massive scales?

Are these two different features? OWL for defining rules? and SPARQL for recursive queries?

SHACL

Here's a detailed summary of Daniel Petronik's talk about Fluree, an immutable graph database with Clojure, and its significance in the context of data sharing across trust boundaries:

• Introduction of Speaker and Topic

• "my name is Daniel Petronik and I work at Fleury where we are making an immutable graph database with closure" - Introduction to the speaker and the subject of the talk.

• Historical Context of Shipping

• "stepping back into a serious problem of shipping boxes in the days of yore" - Petronik starts with a historical analogy to illustrate a complex system of logistics and shipping before modern containerization.

• "it's a very long journey and then you go across the ocean eventually you'll reach your Port of Call" - Description of the arduous process involved in shipping goods before the advent of container ships.

• Introduction of Containerization

• "shipping things isn't that expensive we have containers" - Introduction to containerization as a transformative technology that simplified and reduced the cost of shipping goods globally.

• Parallels to Data Sharing

• "shipping data across trust boundaries is expensive, risky and not worth it for many categories of applications" - Draws a parallel between the old shipping methods and the contemporary challenges in data sharing across organizational and technical boundaries.

• Detailed Problems in Data Sharing

• "every step of the way when somebody touches it you've got to pay for Freight, you've got to pay for labor" - Analogy to the logistical and bureaucratic hurdles in managing data across different systems.

• Introduction to Semantic Web and RDF

• "at the foundation of all these things that they came up with is the resource description framework rdf which is just a notation for graphs" - Introduces RDF as a foundational technology for managing data more effectively.

• Proposal for Simplifying Data Interaction

• "let's simplify the shape of the data and get rid of that application server that special snowflake" - Proposes a simplification of data handling to improve interoperability and reduce complexity.

• Role of Fluree in This Paradigm

• "Flurry right we've we've got a database" - Discusses how Fluree fits into this new paradigm by offering a graph database that incorporates these simplified, standardized approaches to data handling.

• Future Vision and Call to Action

• "this isn't going to cover every use case but just like containers didn't take over everything in order to provide value they took over enough that it made a huge difference" - Reflects on the potential impact of Fluree and similar technologies in changing how data is shared and managed.

This talk emphasizes the need for new methodologies in data management that reduce friction and lower costs, drawing an extended metaphor between the evolution of physical goods shipping and data sharing practices.

Reactivity?

Summary of "So you want to build an ECS-backed GUI framework"

• Introduction to ECS and Bevy for GUI: The authors discuss using the Entity-Component-System (ECS) framework within Rust, specifically Bevy, to build a UI framework. They highlight the unconventional nature of ECS-based GUIs but reference prior implementations like flecs and various Bevy experiments demonstrating the feasibility and potential of this approach.

• "It's a type-safe, trendy solution for state management and most importantly: it'll be blazing fast" and "existing experiments like belly, bevy_lunex, bevy_ui_dsl, cuicui_layout and kayak_ui show a ton of promise using Bevy's ECS."

• Challenges of Developing bevy_ui: The text outlines that the issues with bevy_ui stem not from its ECS or Rust foundations, but rather from the inherent complexity and labor intensity of GUI framework development, which involves numerous components and meticulous coordination.

• "most of the problems that plague bevy_ui aren't driven by the decision to use an ECS, or even to use Rust. They're the boring, tedious and frustrating ones: writing GUI frameworks is a lot of work with many moving parts."

• Authors’ Background and Disclaimer: Alice is a maintainer (not the lead) of Bevy and Rose uses Bevy professionally, indicating their deep involvement but also stressing that their opinions are personal and not official.

• "Alice is a maintainer of Bevy, but not the project lead or even a UI subject-matter-expert. Rose is an employee at the Foresight Spatial Labs."

• Vision for bevy_ui: The post aims to clarify the rationale behind using ECS for GUI, addressing common critiques and misconceptions, and outlining necessary improvements for making bevy_ui competitive and functional.

• "This post aims to record how you might make a GUI framework, why we're using an ECS at all, and what we need to fix to make bevy_ui genuinely good."

• Common Misconceptions and Arguments: The discussion addresses several typical arguments against developing a native Bevy GUI framework, like the feasibility of a single framework satisfying diverse application requirements and the tendency to prefer existing solutions to avoid 'Not Invented Here' syndrome.

• "One GUI framework to rule them all?" and "Bevy should just use an existing GUI framework."

• Technical and Social Reasons for a Bevy-Specific GUI: The authors argue for a Bevy-specific GUI to ensure consistency, ease of maintenance, integration with Bevy’s core features, and avoiding dependency risks which can complicate maintenance and updates.

• "Consistency with the rest of the engine is valuable in its own right. It makes for an easier and more consistent learning experience for new users."

• Implementation Challenges: The article details specific technical challenges involved in building bevy_ui, such as managing a UI tree structure, input collection, text rendering, and integrating with Bevy's system for rendering, state management, and data transfer.

• "Storing a tree of nodes... In bevy_ui, this is stored in the World: each node is an entity with the Node component."

• Strategic Plan for Improvement: The authors propose a mix of straightforward, controversial, and research tasks to progressively refine and enhance bevy_ui. These include enhancing documentation, adopting new layout strategies, creating a styling abstraction, and improving integration with accessibility features.

• "We can split the work to be done into three categories: straightforward, controversial and research."

• Conclusion: The text concludes with optimism about the future of bevy_ui, encouraging the Bevy community to engage in its development to realize its potential fully.

• "But critically, none of it is impossible. If we (the Bevy developer community) can come together and steadily fix these problems, one at a time, we (Alice and Rose) genuinely think bevy_ui will one day live up to the standard for quality, flexibility and ergonomics that we expect out of the rest of the engine."

Here's a detailed and comprehensive summary of the information provided about the Sciter documentation on "Flows and Flexes":

• Sciter's Layout Responsiveness Principles
• Flex Units: Defined as 0.5, 1, 2, or simply , these are used in layout properties such as width, height, margins, paddings, and border-width. "The flex unit (width:1 or just width:) can be applied to pretty much any existing CSS property."

• Flow Property: Manages the layout inside an element, similar to display:flexbox and display:grid in W3C CSS. "The flow property - declaration of layout manager used inside the element."

• Flexible Margins

• Affects horizontal positioning inside a container using left/right flex ratios. Example: "These rules will shift a child horizontally inside a container with left(0.7)/right(0.3) ratio."

• Flexible Dimensions

• Child elements can be set to fill the container's space completely using width: 1 and height: 1. "These rules will instruct a child to fill a container's free inner area in full."

• Flexible Border Spacing

• Distributes spacing evenly among children within a container. "These rules will instruct children to be spread inside a container's with equal spacing."

• Flow Configurations

• Default: Automatically discovers flow based on content.
• Horizontal: Positions children in a single row. "Children are replaced in single row."
• Horizontal-wrap: Arranges children in multiple rows. "Children are replaced in multiple rows, if they do not fit in one row."
• Vertical: Organizes children in a single column. "Children are replaced in single column."
• Vertical-wrap: Similar to horizontal-wrap but for vertical arrangements.
• Stack: Stacks children on top of each other. "Children are replaced on top of one another."
• Grid(): Places elements in a defined grid layout. "The grid flow allows to replace elements as grid cells using 'ascii template'."

• Row(): Similar to grid but organizes content by columns automatically. "The row() flow is a variant of a grid() flow and is different only by method of grid content definition."

• Specific Layout Tips

• Tips for using flex units to fill vertical space, aligning children using vertical-align and horizontal-align, and breaking rows or columns explicitly are provided to optimize layout management.

This summary condenses the critical aspects of the Sciter documentation on CSS flows and flexes, focusing on how these properties can be implemented to manage layout responsiveness effectively.

Here's a structured summary of the article "Why Not Flexbox?" discussing Subform's decision to develop its own layout engine instead of using Flexbox:

• Background on Flexbox and Subform: Initially, Subform used Flexbox post-Kickstarter launch, but user feedback revealed its complexity as a barrier for designers familiar with Photoshop or Sketch. "Flexbox was too difficult to learn."

• Complexity of Flexbox: Flexbox adds new concepts like flex, justify-content, and align-items to existing CSS ideas (margins, padding, etc.), creating a complex, often unintuitive system. "Flexbox introduces new concepts...on top of existing CSS concepts."

• Subform's Layout Engine:

• Simpler Conceptual Model: Designed to be more intuitive with fewer concepts applied more uniformly. "Compared to Flexbox, the Subform layout engine has fewer concepts, applied uniformly."

• Design Choices:

  • Uniform Usage: Utilizes the same units (pixels, percentages, stretch) uniformly across different settings. "Uniform stretch units."
  • Default Settings: Includes 'default between' settings to avoid common CSS issues like margin manipulations. "Default between."
  • Expressiveness: Facilitates more specific spacing configurations between elements. "This approach is far more expressive than Flexbox."

• Learning and Implementation: The article encourages experimentation with Subform's layout engine and provides resources for further learning. "The best way to learn the layout system is to just play around with it."

For further details and in-depth understanding, you can check out the full article here: Why Not Flexbox?

Does this mean, removing children computations from the graph every time the parent re-evaluates?

Solid's design minimizes creation overhead by using efficient data structures for managing subscriptions and avoiding unnecessary memory allocation. "Signals hold the list of subscribers so that they can notify them when they update..."

Balanced Granularity: By reducing the granularity where it pays off the most, such as by diffing a few values for attributes, Solid optimizes performance without sacrificing reactivity. "So what if we only made one for each template to handle all attributes as a mini diff..."

Balanced Granularity: By reducing the granularity where it pays off the most, such as by diffing a few values for attributes, Solid optimizes performance without sacrificing reactivity. "So what if we only made one for each template to handle all attributes as a mini diff..."

• What if we write self adjusting reactivity graph?
• Reactive graph is composed of computations that depend on each other.
• Managing those dependencies has overhead
• The more granular the graph, the more overhead
• At some point the cost at weights the value, there's an optimum to be found here.
• What if we would write this graph by hand?
  • We'll probably write less nodes
  • Things that we know doesn't change won't even be in the graph
  • Things that change frequently together might be clumped together (kinda like neurons)

IMPORTANT * It's better to clump all attributes together and diff at the leaf. * I'm not sure about the insertion

• I think that means: reactivity on orederly reduced lists is hard to granular.

• What does "reconciling lists" means in this context?

• Does the translation happens at compilation (build) time? Or at run time?
• At compilation time we are bound to the syntax (i.e if the compiler is implemented for jsx we can't use it with cljs).
• Also it can't be dynamic (kind of the point of compilation)
• If it happens at runtime, does translation more performant than decision tree?

Efficiency through Simple Algorithms: The story of udomdiff illustrates that sometimes simpler, practical approaches to algorithm design can yield high performance. The library leverages a basic Set lookup combined with common list manipulation techniques, demonstrating efficiency through simplicity. "And guess what it was smaller and about the same performance. Maybe even better."

Performance Plateaus and the DOM's Role: The author begins by discussing how despite various optimizations, web development libraries face performance limitations due to the fundamental constraints of the DOM. "The DOM. Ultimately that is our biggest limitation."

When this is properly partitioned and named it is just a set of rules and properties that compose to express complex behaviors.

Just like physics in real life.

If the systems communicate sequencially using data changes to components of entities (state) it seems like order is of concern. This sounds like manual state propagation, can automatic propagation (reactive, propagator) solve ordering and improve efficiency?

https://www.flecs.dev/flecs/index.html

Semantic type system can be extremely powerful declarative tool

Don't we also need some kind of associative store that associates entities ids to components?

How?

This approach is especially suited game engines which operate of a single attribute of all the entities (i.e the position of all entities, shadow of all entities, etc..) and not the overall attributes of a single entity.

Based on WebGL

• Data ownership:
  • Wallabag has a paid hosted service
  • But the project is open source and self-hosting should be possible

• Collection & Recollection:
  • Looks like wallabag is sensitive to URL variations like memex
    • It will double save a url with hash and without hash
    • This probably will apply to Wikipedia's mobile domain and I won't know if I already saved a page on desktop/mobile

• Annotations
  • Text & Images
• Smart Bookmarking
  • Full-text search
  • Automated Tagging

Does mymind support integrations? I would like to automatically export entries to logseq/obsidian.

Does it have to be that way? Can't we optimize production process without compromising quality?

I believe fine engineering can enhance both.

I don't see anything inherent in mass production that must contradict quality.

It might be that one of the easy ways for mass production is compromising quality, but it's like any other problem: resources (time, effort, ingredients...) and quality can always be tradedoff.

Does it have to be that way? Can't we optimize production process without compromising quality?

I believe fine engineering can enhance both.

I don't see anything inherent in mass production that must contradict quality.

It might be that one of the easy ways for mass production is compromising quality, but it's like any other problem: time and quality can always be tradedoff.

Does it have to be that way? Can't we optimize production process without compromising quality?

I believe fine engineering can enhance both.

I don't see anything inherent in mass production that must contradict quality.

It might be that one of the easy ways for mass production is compromising quality, but it's like any other problem: time and quality can always be tradedoff.

How?