Things that went well: newer protocols and interactive methods with agents. MCP and CLI toolings for better loops. Things that could have better: More edgy and opinionated workflows.

I must write the digest with links, that is the only way to concretely and forcefully keep internalizing the memories as learnings.

After a few light notes on where it's useful and where it adds concern in personal, this is getting wrapped up almost now. Naman formally wraps this up. I think formal closure, I shall skip? Let me hang for a second.

Its good that it's getting wrapped up almost. Thinking of the long task to jot all these together into a report with all the links and resources. I hope I finish that before it's too late to do.

The conference is getting stretched and hanging long and slow. It's been a long day and long conference. Both loaded with a lot of packed noise, but some gems here and there.

This panel discussion actually feels a lot more humane and unpretentious and nonceremonious. Right harness that can determinstically tell validate is underlined by Adnan.

I think there definitely a noise and quality and originality issues. But there are gems here and there that can be picked. Unless you have a better alternative to keep nudging you, such activities are in a way touching the grass, although wet and muddy.

Naman adds that this is the time for disruption and big names ignored it 22 and new names then are now household name. Time to take them seriously and fall forward along with the new protocol acceptance.

Still thinking about interaction with Bijoy on the value of such places and events. And I am still trying to justify this to myself in one way or the other.

Naman pokes about the new agentic patterns. Zahle goes in the direction of building on top the agents for broader possibilities. Ashita stretches this with agent inbox for agentic logs that LangChain is bringing.

Adanan reminds us to not throw the playbook out. Keep the humans in mind. Bringing the flexibility of the LLM into the UI as well.

According to Ashita. Agentic UX now clubs agents alongside the humans as executives driving the human indents. Smile corroborates that with an example.

Panel discussion brings Naman Sancheti, a new face, adnan, ashita, Smile and Zahle together. Good to see two women in non moderator roles on stage.

Oh. Panel discussion already here. I thought this would get cancelled due to time. The hall is as filled as it was when it was starting in the morning. And I am also approaching towards 200 notes mark today.

Sometimes we have recurring see .md outputs break inside the chat experience. This feels richer and more ambitious. Zahle ends his talk very quickly and sweet and short intro.

Generative UI is a agentic chat native UI where the conservation itself uses the the UI as a part of the interactive communication. This helps have a richer experience in your agentic chat experience beyond just words.

Zahle Khan now comes, oh, he was the one who introduced the OpenUi protocol to me outside yesterday. This is interesting and makes sense why this following Ashita's A2UI.

Ashita plugs her three series article here: https://dev.to/ashita/how-i-added-websocket-powered-realtime-streaming-to-mcp-apps-3oh6

This A2UI protocol kind of reminds be the OpenUI abstraction for the UI as well to communicate your UI system with the agent.

Ashita mentions the A2UI protocol that is JSON based. There is this A2UI library on npm packages.

Goose gets a plug by Ashita with Amzon Bedrock that has access to frontier models as well.

MCP Apps are a new things only a few support these. Sandboxed View iframe with restricted permission helps with the security and access across seams.

MCP Apps then, help you build multistep user paths.

Another example is rendering the app directly in the Agentic chat client.

Agentic experience is evolving on three fronts. First one is WebMCP. It's like JS function that your agent can export.

React Aria Library example to refer to accessibility tree and labels. Aria labels are no more nice to have, they are interface for your agents.

Agentic experience also caters to now to the bots intend along your human users. Agents are unpredictable in new ways.

These days over half of the traffic is automated bots.

Ashita opens with the context of the user experience and human user, api patterns and ui was always for a human on the other end. Now agents have fundamentally changed that.

After Mohith's long masterclass on his system architecture on his app, now Ashita Prasad from AWS talking about the building for the agentic experiences in React.

Mohith also admits that voice agents aren't the obvious answer for every user. Always look for a better solution and something better will be there.

Mohith plugs OpenAPI that documents all your API with all the decorations. This person's immersion in his architecture is really inspiring and I am.on the edge of my seat.

Mohith now walking us through the backend as well in a react conf, I think he can passionately talk about his whole architecture thoroughly end to end.

Mohith actually is walking us through the entire architecture of his application and it's applicable. It is indeed fresh but also packed and long. And it stays low enough with system and explains how voice agent, LiveKit RPC, frontend, Zustand.

Mohith use usePorcupine for the audio hooks and STT to LLM to TTS pipeline and long term memory via Super memory. The knowledge graph here helps to stay consistent in its suggestion. Langchain is also used to orchestrate the LLM for predectibility.

This is also with an active user scale of 2k-3k in a day. Auto trigger UI actions inspired from perplexity. I really Mohith showed the demo of the UX. This really sounds impressive.

These users mostly high school kids, who would expect a different UX. They decided to have multiple modal and primarily voice mode for better user engagement and experience.

Now Mohith, running his own startup with 20 people on Agentic Voice AI. Who got a gig of move a career counseling agency to an agentic application with 20k existing users.

Having said that, the justification would be that this is also for getting the pulse of what is happening around the world and not diss it as a mediocrity.

Also, I need to agree that because I only have strong academic conferences as a reference, all these conferences will appear mediocre. Also, YT content is more efficient at giving value over time.

I remember being highly disappointed at this other conference on data viz last year and this one feels a lot more utilitarian over that one.

Bijoy is hopeful that I would hit the 200 notes mark today. There are enough sessions. But also thinking about the conference and it's quality.

Time for the break now. The general energy seems to be going down as another long is nearing its end but not quite. Following sessions don't seem to fit in a theme. Range from designing for agentic experiences to realtime UI generation.

Just like Janardhan's talk, this too feels like a workflow prescription, not quite original or inaccessible otherwise. Or things at the edge. Nonetheless nudgy for us to follow and solidify these approaches and their needs and limitations.

This demo running the browser tab and adding a ToDo, leaving th traces of logs in the chat and tests being populated.

Santosh then demos a ToDo app with basic functionality with a playwright MCP connected in his Claude.

Santosh then explains the ideal cases for autonomous triage and repair of existing e2es and for bootstraping or for initial exploration.

Because of the bills and size, nightly e2e preferring cli over the playwright is always more efficient.

But MCPs have a unique advantage of being a part of the agentic loop. Since it's part of the agentic muscle, it knows where exactly it's facing reading through your console.

But the token context is expensive. Like for playwright, it's 17k token in our context. CLI is a better alternative in that approach, token efficient. But headless unless MCP that always need a browser head.

Sontosh goes to make the case for MCP benefits for structured data returns, host side execution and standardized auth and better governance. There are other options too like CLI and scripts and API calls.

Oh. Did 150. Santosh starts setting up with attempted crowd work and loud thinking about the need to connect logs with agents.

Santosh Selvasundar now about Playwright + MCP for E2E. Janardhan was actually more about Dev Tools and Sontosh is actually taking it forward with Playwright. Santosh is frequent at React Nexus.

This was a straight forward and unoriginal or very obvious workflows that we only sit on and laze to fully utilize. This has long been my operendi where I am not setting the setup well.

Now the flow is from promts-context-code-render-pixel-devtools.

Design tokens and exact CSS variables helps. Typography rules. Component rules. And conventions. All of this helps the agent better.

Regression baseline can also be defined in playwright for real browser testing, mobile viewport, etc. We can commit the baseline snapshot and agents can make change and have regression run.

Accessibility can also be improved, better aria and labels and SEO as well. The visual regression can be then solved with Playwright and also cyprus.

We can you use this for input automation, automatically fix complex UI flows. Emulate and debug to validate responsiveness. And also take care of performance.

Janardhan tells then about installing the MCP in your agent json, and now it can now open chrome dev tools protocols. And reads the live DOM. Instead of image, now structured data. It can scroll and click.

For example, signup form can give you generic error. The dev tools can give us more nuanced network preview. These errors and diagnostic clues are in the runtime data.

Next is ofcourse playwright. Dev tools for agents enabled the closed loop for our coding agents. But still may not be enough.

In such cases, the agent analyzes the codebase and makes guesses. Misalignment and responsiveness breaks occur. Solutions to these chrome dev tools MCP and now also CLI.

Janardhan is setting up for the use of dev tools and agent loop. Sets how backend flow can fully be completed through the i/o. But the frontend speaks through pixels.

Now Janardhan from Oracle taking about Fixing AI's Blind Spot and giving it eyes in the browser. Sounds like a big playwright plug. Let's see.

WebMCP is upcoming idea where your page declares what if can do for the agents. This helps immediate tool calling.

This accessibility tree is being used by screen readers. Labels are important. Claude runs as extension, but can access everything your local storage.

Accessibility is the priority and non accessibility do really bad with agents. Not accessibility tree gets more importance than ever, getting more importance than your visuals.

They can fill complex forms with accessibility trees, screenshots and DOM. These modalities have these priorities because generally DOM is too big.

Adnan makes a case of agents impersonating to take actions on our behalf. Where an agent can book a restaurant on your behalf and also get you a discount. Bots can already navigate the website so well that weren't necessarily designed for them.

Oh, reminds me how I am treating my sitemap too as a common good experience for both humans and agents.

Adnan refers to the Cloudflare Radar where almost 60% visitors are bots. But there also specific agents looking for your site. So, agent experience is also a user experience.

Now Adnan Arif Sait, talking about making out UI agent-ready. And how agents uses websites.

Google Rich Results and Schema Validators are the tools one could use. Reminds me that I need to uodate my Homepage Image on my schema also because it's a fallback image too.

Sriram also mentions a few pitfalls: don't use next/scripts for JSON-LD, don't have unsanitized output like xss vector, SSG with dynamic data and don't base your dynamic data on cache.

This talk so far fully sounds like my blow wrote about my opengraoh and JSON-LD couple of months back.

Not for rankings, or required for ai overview, don't guarantee much. Bot can irrespectivly look at your page. In the frontend, and how the bots works and now they say the bots can run js in headless browser.

The fields in your JSON-LD and different fields in it such as rating and offers. Sriram debugs that reach results don't mean higher rank explicitly. But schema is only about rich results, knowledge and content classification.

Schema markups adding them into the application page helps with better search result. This talk seems to be about JSON-LD. A simple bit of code you add to your page.

G Sriram (Bijoy made a pun, yes, the one you are thinking of) now will speak about the Structured data and schema markup for FE Dev's. SSR, CSR and search in agentic era.

Eval harness that costs nothing to run is something that your team will end up using.

Local model accuracy can also be improved by reference anchoring with bad example and good example. Ensemble voting also works well without costing much.

These local models can be improved with reasoning and chain of prompts. It can also use criteria decomposition like tone. Accuracy and policy. All criteria can be individually evaluated.

These evaluations can run at 1. During development, 2. In headless chromium+webGPU, 3. In regression step. Than directly in production. But accuracy is as at par with frontier or enterprise models.

So, browser evals are real and no api costs after the download. So react app on main thread. And two parallel threads generator and judge threads using indexDB in the browser. We can have a spectrum for the evals.

So, building and verifying, charges you twice. So, to cut corners and bills, we reduce the scope of the testing. And slowly issues can accumulate quietly.

AI can have a wide window through the prompt changes and that can be bad compliance.

So, this is about LLM-as-judge to eval a free form. But this evaluation could cause you a huge bill. Hence local AI to save the bills.

This seems to be about local LLMs. And LLM as judge. AI outputs are in free from and we can't assert them well.

It is also quickly over. Might be the session that not only short, but also least amount of sentences may be. Quickly moving to the Megha Pathak from Flipkart taking us beyond API.

Mohit's arguments is that the barrier now has reduced and you don't need the headsets. Today, you can to laptop first modelling.

Mohit's demo feels slow, also very expensive on 5.5 codex with a lot of MCP tool calls.

Mohit has IWSDK configued in his vite application in this demo, references to playwright and docs. This allows for oversight verifications mode with the ai.

There is a lot of verification of the builds to keep tuning it well. Now with the sdk, the agents can interact and iterate now better.

Started with a couple of renders in browsers to set the expectations. There are challenges to enter in this space.

Returning after the lunch for Mohit Kumar Toshniwal on XR experiences in browser leveraging agents.

So far, satisfying sessions. The last panel discussion was a filler, could have been skipped. But good to see a lot of original talks today, on the egdes.

Oh time for lunch now. Break time. No one is waiting for the emcees to finish. Back by 2-15.

Rishab suggests to add the breadth, since AI had the depth to give you. Chaitnya adds that syntax knowledge is the baseline and how to become an orchestrator to do different things in parallel.

Apurv instead had to actually do workshop for the PMs faster with PRD.

Sweta then pokes onto the conflict of the platform stability and development speed. And Respectively, the teams have conflict. Nattu says this is a problem that always existed. Chaitnya and Apurv have opposite experiences.

Chaitnya too corroborates and highlights the importance of the deterministic checks. The agent.md become quickly stale and fall behind as you keep refactoring big.

Oh, century of the notes today before lunch. Rishab adds that evals have helped him trust better. Apurv too adds that having your own agent over services like Greptile and CodeRabbit is better for your specific context and quality checks.

But the scores sound very similar to the the existing review skills. He adds that we lazy in teaching the LLMs what good is.

Nattu jumps on to response, corroborating to that tone. And plugs mergemitra, his tools, that is trained on their past PRs, which stands to be different from Greptile and CodeRabbit with their own Rubrics and scores..

Rishab adds to that, saying the importance of dependency graph in such processes to be surgical and efficient. Sweta, the moderator invokes a response from the panelists further on the overconfidence in tone of the models.

Chaitanya highlights the limitations of AI in 15M lines of code context and also the cost for it. Skills, although, with just description, at scale, pollute context. It only benefits the LLM lords at OpenAI and Anthropic.

Apurv iterates the priorities and boundaries, and custom skills. But then underlines that context being more important than thr prompt.

Rishab corroborates to Nattu. Demands work to be done on the codebase ready. Chaitnya story for yesterday about the huge Atlassian Codebase that monorepo and messy and has implications underline the need to be careful about agentic infusions.

Nattu goes on to speak about the quality checks with agents as an easy task but refactoring is hard byte that doesn't give the reliability.

In case of complex, messy and giant codebase, Nattu goes on to plug Code Walnut and as problem that they are trying solve. Slop and bloat that emerges out of shallow agent leashing, can be tackled using good docs at the module level.

Apurv defines it deligation. Chaitnya keeps it real and admits that things are still baked. Yet goes on to say synchronous, asychronous in CI and autonomous with goals through loops.

AI for Code Generation is the title. Sweta, Apurv, Chaitanya, Nattu and Rishab coming together here. Hype, Reality and what's next.

Now time for the panel discussion that was skipped on Day 1. All the speakers from yesterday are coming together today to this panel.

Sumanth is launching this product on product hunt today. One indie developer solving his own personal problem. This was a such sweet presentation and talk.

Sumanth now talks about AI as a developer partner that helped him with S3 migration, Konva Canvas Editor, Claymorphic UI design system. Deployment.

Pixel Macha has a feature that takes a selfie with your webcam and searches across for your photos with facial recognition. This is cool, the speed is slow seamless, it's unbelievable.

Sumanth then takes a live photo through his phone, and shows that the photo arrived on the laptop. The PixelMaacha UI allows to crop, overlay and export.

Camera clicks, uploads bia FTP.

FTP started in 1971 and standardized in 1985 by RFC. It already exists as a protocol across. No sdk nothing.

A local FTP server was a good experiements. Setting up permissions across different OS makes local FTP hard to scale. So Sumanth thinks of online server. Most cameras have wifi and have FTP protocols.

Sumanth is from smallcase, He starts with a story. The problem of the memory card relay race, for quick photo sharing from photopher to social media team. Tethered camera, messenger apps are long processes.

Good, easy talk by Jerard. It felt smooth because not much cognition engagement was demanded. Next is Sumanth is a photographer developer now talking about Building Live Event Photography Platform with FTP Server.

So, new things needed apparently. jerard says they will be donating this project to the OpenWallate foundation. ThunderID cares about DevX and has support across.

This makes the App security more crucial than ever before. Who access system, access what, and how secure access are the questions. Jerard then plugs their ThunderID SaaS. But the encryption with the existing vulnerable algorithm has threat from upcoming quantum computer.

No one raised their hand when Jerard asked if anyone developed an Authorization system. It is complex, no one did it. Most of IAM platforms are build in the cloud native era or before.

Jerard Rutnam from WSO2, again a sponsor talk, about the authorization part after the authentication. He is part of the ThunderID open source.

TVM Apache gets a recurring plug. This was a very packed talk that talks in very detail about alternatives that is WebLLMs, sounds very constrainted and if too many ifs. Yet very interesting experiements to run.

WebLLM also gives a us storage knobs, a cache back policy. Models can be kept alive by setting up heatbits. Treat the GPU is borrowed and owned. Shipping for the local AI means shipping for hardware you do not knwo, not for sensitive data etc.

Some cons are that it takes time to download the weights. It can take long time. Once the model is downloaded, it can be used. This can be circumvented with design sugar.

Context issues can be solved with KV Cache without which O(1) operation can be O(n^2). Almost all browsers support the WebGPU. They often ask for RTX.

Almost same but very very small, with a little drop in quality can be helpful. Reminds me of the beautiful ngrok blog on this quantization approach explainer.

2011 WebGL, 2017 WebGL 2, and then 2023 WebGPU. But the LLM models are very big. 14gb is just LLAMA. Quantization can solve this. fp32, fb16 and then even INT4 are lossy compressions.

Harsh introduces WebLLMs. And there apparently no API calls in here. But that would mean needing a hardware which is not cloud and CPU is not good for these matrix parallel compute.

Next up is Harsh Pathak from Groww about Browser being the Backend, and Running LLMs in react with webGPU. This is interesting.

You post to temporal api, and polling for the state with the workflow id. Aqsa shows a demo to of these isolated steps and isolated retries with Temporal, eventually after success given to react/client.

Aqsa introduces workflows with durability, retries with context. And enter temporal. Flow is fetch data. Call LLM. Format output. All isolated steps, easier for temporal to automatically retry. In the React Side, this helps you stop guessing.

Aqsa is frequent at React Nexus and also runs GoGirl. She starts her talk with a scenario that is slower than usual API calls which fails fast. But API calls to agents could fail very slow. Which could mean more bills, silent failures, parser could throw later.

Next up is Aqsa fro. DOcean about From Click to Agent. Titled Building Resilient AL with Temporal and React.

This is a lovely and nuanced story of engineering. The presentation is very rushed and bit disconnected from real time delivery, more like very rehearsed. But a lot has been presented. And it seems Prakhar left around 10 mkns

Buffer on both sides to feel then with polling window. User might go offline and the return. This should keep filling the gap. Both side know how many messages they recieved. Sever id is also important.

New WebSocket() has no timeout. Resume, don't restart. The experience should be seamless. Their state shall stay preserved. Both sides count. Both side remember!

But websockets isn't the only thing. There are browser APIs as well. Real world has a lot of mess and network switching as well. Navigator.online(), setTimeouth have their own quirks.

Calling Websocket close isn't a single step. It will also close TCP. If the user looses the internet, waiting could be long, as long as 60 sec. That could be very long. But what about the missed dictation meanwhile, Prakhar's story doesn't have that.

First issue, send() was not synchronous as expected. There is buffer in network. It ques. Hands to TCP and it may or may not deliver. A lot of things can happen.

Websockets connection can open and close with users input audio. But real world was a lot more messy. Requiring them to go back to the drawing board.

These users have a very low and flaky network. Only thing these users care about is that the job should be done. For real time dictation, audio chunk in, stream transcript back.

Prakhar is a platform engineer at Adalat Ai, which sounds high pressure real time performance for dictation for the users who judges and court staff. Users trust is very important.

Next one after the break is by Prakhar from Adalat Ai about websockets that hold up in production. I am really looking forward to this one.

Yeay. Time for coffee now. Break. I really like this day. Hardly a push for agentic flows. Only imagekit's Harshit did it with that extent yet so apt and useful.

This reminds me to start using MCPs aggressively. I have been avoiding that to stay in logs and with knobs and with tool UI. And to keep the context managed. But now it's time to be serious again with MCPs.

Next prompt is about using imagekit MCP, that uses url based parameters. This will create a plan and next prompt shall implement it. Lossless optimization of the images. Oh, so, imagekit MCP is essentially image size reducer. I do this manually using Adobe Lightroom.

The image size in the demo are actually big, in MBs. The biggest one 29 MB. LCP is too large because of this image. Cumulative Layout Shift (CLS) leading to bad UX. These are the issues given by the model.

Harshit uses prompt to record and find three biggest performance issues in his repo in the demo. Plugs Cursor as a preferred development tool.

Harshit shows a demo with a webpage having a video in the background and image. The lazy laoding is loading the images as we scroll.

Lighthouse gets a plug. Lazy Loading is loading on demand. I really this approach to fix some of my issues with the images. Embarrassed that I haven't done this yet.

Harshit brings MCPs now to close the feedback loop for performance. And think of performance not as an afterthought, but right during the development.

Okay, imagekit sponsor talk now. Harshit Budharia now on debugging image and video performance issues with MCPs.

I wish Gaurav went before Zubair though. That would have been good progression and relevance, and Gaurav setting the stage for Zubair.

Sentri plug for their sdk and open standards. Logrocket, Graphana too gets mention.

Better error tracking with release, device and other contexts. We can also use browser tracing the users whole story from click to fetch to parse to render and time taken at each step.

Another observability metric is Core Web Vitals like LCP (loading), INP (responsiveness to interactive to next paint). CLS (stability for cumulative layout shift). There also more.

But observability goes beyond. These metrics could be real user monitoring (RUM) beyond 'works on my machine', where users have wide range of devices. Like using cool.animation or webGPUs.

Existing metrics could be API latency, Error Rate, Uptime, Deploy passing, Tests (although AI written 😉). Monitoring can give you answers to the questions you know.

Gaurav stresses on the trust issues and blow backs and low times due to AI reliability to add context and background to the observability approach.

Next one is by Gaurav Tewari, taking about Frontend Observability beyond just the console logs apparently. He is from SigNoz. Gaurav brings his talk with a storytelling.

This was another walkthrough that I really liked. A lot of low level details, but something that feels very real and rooted.

So the flow is more like from playwright to headless chrome to prometheus to graphana.

Prometheus gets a plug. Now the agent has a coordinator with HTTP and set of controllers as individual users. Getting and simulating the browser client behaviour as much as possible using headless browser and playwright.

User config files are simple JSON files, terraform config, AWS instances are the abstraction Zubair explains to run the load testing. Like to test max number of user concurrently using Mattermost.

Zubair now moves to explain the Load test tool's architecture which is built inhouse. K6 gets a ug, which is existing tool, but Zubair needs were big different justifying the need for custom tool

Tracking to.manu in the local state is also not desirable. And we shall break down the initial load bundles. Yet there are a few caveats regarding client performance and most were heuristic.

Cost Benefit of Websocket vs polling sometimes can decide what's the negotiation that can be made. Websockets are expensive. Polling can work often.

Nested JS objects can create a lot of issues. Redux Reducer Performance can be improved with applying single pass reducer pattern. Batching and polling is an approach.

INP, TTFB Load end event, FCp, LCP are standard metric to measure. There are also Chrome Dev Protocols. And there is App Specific metric too, like switching channel, time to load threads.

Quantification is the first step according to Zubair to come to specificity from broader terms. CPU usages, Frame rates. HTTP Archive. All these tools already available.

A lot of users when typing on the same channel, and store gets overwhelmed on the client. So, a balance between over fetching and under fetching.

Zubair is from Mattermost. He gets directly to the point. Why does the client side matter for the scale. He gives the Websocket context, using Redux to manage the global state at the store.

Emcee too introduced the talk about the tools and approaches to performance beyond the AI's reach too today. Loving this day.

Now, Load Testing Real React Application for Production Performance by Zubair. Primarily the client side performance

Nikhil Soni's talk was nicely technical, enough low level and yet the only one on React Native. I am not from the React Native context. But this felt like a good start of the day.

Soni mentioning the solace and joy that brings to see the crash report graph going down and it becoming his wallpaper. All now stability rate now 99.99%.

The launch crashes are often about the module issues or memory issues. In Module Registration Architecture, some of the modules were failing from main thread. Forcing these modules to run only on JS thread since UI thread will crash them.

Soni also also mentions Hermes Dsym as a life saver to get the whole trace properly. Such tools helped Soni to diagnose the launch crashes.

There is also Lauch Crash, which is very hard to debug since first attempt failing doesn't leave you much traces to look at.

Partial Unmounting and Cache cleaning are only a part of the problem. Soni says the real root is also at the Memory Explosion. Thresholding number of images via setting the cache limit with SDImage. Also, dynamic cache units to get the best values.

Size and resolution, image buffering in e-commerce are a usual challenges. Looks like this talk is slowly building for imagekit talk later. Scheduled cleaning of cache is needed in an use effect in an interval to clearMemory()

Also, unmount images when not visible. Such partial unmounting strategy can drop memory warning by 85%. But there is also image buffer explosion.

Stack growth and memory spikes. Memory management strategies like partial unmounting strategy, smart memory management. Like get the device memory variables and accordingly devide caching strategies.

Oops. Can't update the the last entry. It's Dsym. Autocorrect changed it to Daym*, damn indeed.

Traces with Daym with debugging symbols. Oh date format here to is causing issues. Reminds me of the speak2 lives.

Datadog and bugsnack to identify the crashes and to investigate and identify the user journeys.

Code Red where no features and only fixing the existing issues. Running the crash rate benchmarking. Best vs Average. Hotels and Booking 0.4 rate, highest rates across industries on crashes.

Nikhil is mostly about to talk about the crashes. How the crashes increase as the user growth keeps up exponentially until week 10 before it starts to flatten of sorts.

Nikhil Soni now here begging to talk about crash free apps

Oh. It started. In hindsight, and eventually, the emcees were candid and engaging. Today as well feels nice. I need to give more credit to the emcees. They are trying well.

I guess the imagekit sponsor talk is happening today. They could talk about LCP, loading optimization and optimization, but let's see.

There is one lined up on Browser Telemetry, Logs and Error Correlations as well. I wish there was one React Dev Tools as well. Or hope this is about React Dev Tools.

Load testing and scaling doesn't feel that relevant to the frontend. Very curious to see what that talk brings.

There seems to be only one session for the React Native. Today appears to begin from it. And more about how to NOT crash. I am not sure the scope and definitions of crashes here yet.

Also, Day 2 really feels promising from the schedule atleast. Very fresh, more rooted and relevant. Also, hopefully less hovering, more grounding. Lets see.

Audi is some 25% filled. It's already 930. Bijoy said he will bring laptop today. Hi-hellos from yesterdays people happening. Looking forward to the day today.

Here for Day 2 now. Wish to sit at a new angle and location. But this would be easier for Bijoy to locate and also can't imagine a better angle.