moonliteTech

@ScriptedAlchemy @astrodotbuild having a chuckle I recommended astro to the dev that wrote module federation... note to self, read bio!

@MoonliteTechLLC @astrodotbuild 200? lol. Try 9000

Its official. Im giving up on nextjs & module federation webpack plugin. Deleted the package, writing new version of package for rspack only

@ScriptedAlchemy @astrodotbuild lol just read your bio, nm :D

@MoonliteTechLLC @astrodotbuild Then you do not work at a large enough scale.

@ScriptedAlchemy @astrodotbuild number of modules scale or serving concurrent users scale?

@andrejusb you used a png, is it able to grab from a pdf as well, or would you convert it to png first?

Qwen 3.5 Test for JSON Structured Data Extraction Quick test of the new Qwen 3.5 models on JSON structured data extraction from images. Testing and comparing results for 9B FP16, 27B Q8, and A3B 35B Q8. The 35B Q8 model wins in terms of both speed and accuracy. Test was run on MLX-VLM using a Mac Mini M4 Pro with 64GB RAM Video: youtube.com/watch?v=zCoBF1… Code: github.com/katanaml/sparr… Sparrow UI: sparrow.katanaml.io

@therealdanvega I use it for everything except coding. I do like to ask it architectural software 'big picture' type questions.

I'm genuinely curious, is anyone using Grok? If so what are your uses cases for choosing it over other models?

Astro 6 is here! We completely rebuilt the Astro dev server and build pipeline onto a new, more powerful runtime-agnostic architecture. Plus: New Fonts API, CSP support, an experimental new Rust compiler, and more... astro.build/blog/astro-6/?…

@RyanCarniato @solid_js Looking forward to migrating to solid...

I asked AI why @solid_js 2.0 is a big deal. And I think I found an answer that speaks to me. Does it speak to you? @0u1u3zEAQAO0iYWVAStEvw/rJM9ws3Kbg" target="_blank" rel="nofollow noopener">hackmd.io/@0u1u3zEAQAO0i…

I am exclusively an anthropic model user for coding. I use Cursor with plan mode normally. Today I wanted to try a few different models and see how they performed. In React, I have a list of things that can sort by tag or filename, and wanted to add field level filtering. This is very representative of the types of tasks I use AI for. My steps were: 1) initial prompt to do the filtering 2) follow up prompt saying that we need to auto expand any closed nodes once we have a search value 3) feed it my 'react state management guide.md' and see how well it aligned (best practices type stuff) 4) tell it to add transition animations to our work A few conclusions from my sample size of 1... Gemini 3.1 pro was very very slow. It asked me the search scope if it should be across tags, filenames, and field names. Built fine (but slow). When asked to do the autoexpand, it never could figure it out. It didn't follow the best practices in my state document by default but was able to align once show the document. Codex 5.3 was very fast. It never asked me about the search scope, and I had to prompt it in afterwards. It did fine on the expand follow up prompt. It had already done the state best practices without seeing the document. It hallucinated a transition animation that never did work. Sonnet 4.6 was very fast as well. It asked me about the search scope, and I never had to prompt it for the expand, it simply did it. It lined up with the state doc before even seeing it. It hallucinated the transition animation but was able to solve it when it figured out that I had tailwind animations installed but not registered. Overall, I think I will stick with anthropic models and do a similar test in the future.

The <Suspense> is over. Solid 2.0 Beta is now released (next tag on npm). 🎉 github.com/solidjs/solid/…

Every Node.js developer has lost a background job to a server restart. We just open-sourced @platformatic/job-queue, a new queue library built for reliability from day one. Deduplication, retries, request/response, graceful shutdown. All out of the box. 🧵👇

@ankurnagpal You mean Jarvis?

A big new consumer category will be an AI house manager for the entire family Can live in a group chat and can handle tasks like: - Manage groceries - Plug into home security - Scheduling maintenance & cleaning - Smart home controls and automations Who's building this?

@devagrawal09 @solid_js yes, 10+ year old code base....

@MoonliteTechLLC @solid_js 0.8😱 Not even 1.x??

Hello to everyone who started using @solid_js in the last ~12 months give us a shout, talk about your experience, share your AI rules, shout out the awesome ecosystem libraries you use

@devagrawal09 @solid_js largish refactor from angular 0.8 (zero in front) to solid next month... will keep a list

@MoonliteTechLLC @solid_js not yet, working on it open to hearing about issues you might be running into with llms and solid code

@CFDevelop anything the public can play with?

It took me about 6 months working weekends and late nights just to get a digital modular synth VST working on Windows many years ago It took me a few weekends of vibe coding to upgrade the code and port to Mac Nothing is impossible anymore

It's interesting how I used to stress over cleaning up every sentence I wrote, and now I'm like, "eh, if something is a little clunky, at least people will know it's me that wrote it instead of AI"

Of course frontend has a concept of architecture. The short version is we learned what you are suggesting doesn't work well in this space. The history of web development answers your question. There is a category of data, we refer to as "state", that is ephemeral. Now we can define ephemeral in different ways since everything persists somewhere but the key is that the ownership of this state is very much tied to the User Interface. Focus, selection state, as so on are shallow examples of this, but you can also think of this in terms of projections of those too. This category only gets larger as things become more interactive. Early web development did not exactly understand this. And when our life began on the server we'd lose this information between actions. POST a form, bye bye state. Now we wised up to that and started serializing it back and forth. ASP.NET had it's ViewState and so on. But we hit a fork in the road in mid 2000s because keeping ephemeral UI state on the server didn't scale great. We wanted RESTful backends, so we could spin up microservices. MVC became king. Its simple model fit: Model (persistent data), View (projection of that data), Controller (singleton that wires it up). What is missing is this non-persisted state. This worked pretty well for simple things. But sort of ignored the problem. Which was ok because people wanted quicker interactivity so more and more started moving to the client. Dawn of SPAs recognized that a more structured approach needed to be taken on the client. So what did we do? We tried to bring our MVC there. Angular, Backbone, Ember, these frameworks followed it. But a pattern started emerging.. we had this thing that had no place. Singleton controllers didn't cut it. `$scope` in angular is the most obvious. And as any early Angular dev will attest became a huge mess, but Ember also started adding all these new concepts, It was more like MVC(insert 12 more letters here). But this was the problem. In fact the misery that was Angular.js => Angular 2 was IMO motivated almost entirely because of this unreconcilable gap in design. React wasn't the first to realize this though. MVVM frameworks like Knockout.js replaced Controller singletons with per View (or per Model) instance wrappers as a natural place to hold this ephemeral state. The VM standing for View Models. But I'd say React was the first to consolidate on a pattern that was already happening in the wild. For better or for worse VMs did much more tightly couple things. Pretending these things weren't coupled just made traceability very difficult. React owned it and was like there is a natural split between the Model and the VM but the VM and the V are not benefiting from the seperation. And thus Components were born. But people early days still really liked their separation. So we built really complicated stores. So we could model all but the most ephemeral state as a sort of hoisted Client model. Early attempts were really awkward because synchronization became really buggy. So work went into making this predictable, singular so that state couldn't get out of sync. Redux comes to mind. But there was this tension. Lifecycles were clearly tied to the UI, so there was this constant issue around either holding too much state that was unnecessary or needing to like register/unregister. Obviously things like Angular had services and DI as their approach. But the problems were the same. Around the mid 2010s... thanks largely to GraphQL it became better understood that except for where the user was the source we could basically view state as derived from the server. When people started using it, the need for Client side stores shrunk considerably. This evolved eventually into things like React Query. Now even though the sources no longer needed management, we still have this derived state graph running through our components. It might not be as obvious because of say the way React re-runs components. But by 2018 with the introduction of Hooks you could start seeing it right in front of you. An irony not lost on me because it was like looking at 2010 Knockout.js code. The result while not realized completely mechanically is an acknowledgement that State and UI are not easily separable, they overlap. Modeling Component === state like early React might have oversimplified things, but something like MVC categorically misses. A lot of the progress in the last 5 years around Signals is based on preserving these 2 graphs(UI, State) ability to co-exist in a way that is natural. As projects get larger it is the only sane approach to modularity. It's arguable that patterns around strict contracts/regions should be solidified into concepts, and to be fair boundaries around errors and loading(Suspense) do contain these things. We have natural boundaries around nested route sections (tied to URL subpaths). But each graph has their own mostly homogenous primitives so those coordination points are extra concepts, and because of the fluidity of this relationship being too strict here will cause you great pain later. So architecture is very much at the top of mind of those designing these systems and tools. However, frontend web is also the most accessible platform. So I don't expect every bootcamp dev to know, understand, or appreciate these things. The structure we have created to allow this modularity and co-location can also be greatly abused. Partially because new devs can be "productive" within their small slice. Which is by design and generally beneficial. But doesn't bestow the same sort of architectural purity and rigor one might expect to find in such large complex systems. To me this is more cultural than an engineering. The information is out there. We're living in it, but who needs to know? It's hard because people who know a bit more keep respinning on the same expectations of what doesn't work and take few steps in before they realize it. And I think a lot of engineers outside of frontend have no appreciation for it.

AI writes 90% of my code and I handle the remaining 90%.