Search
481 results for “develwithoutacause”
-
Over the last few days while working on an upcoming blog post I've performed quite the yak shaving:
1. I wanted to use `@layer` in a #CSS demo (ironically one showing that it doesn't solve this particular use case).
2. My auto #CSP setup using #JSDom and #CleanCSS failed to parse `@layer`.
3. I upgraded #CleanCSS.
4. I removed #JSDom and replaced it with #parse5, which works with `@layer`.
5. I wanted to use `Object.groupBy` here which requires `target: "ES2024"` in #TypeScript.
6. Therefore I needed to upgrade TS.
7. Upgrading TS broke #Karma for reasons I couldn't understand.
8. Therefore I migrated from Karma to #Vitest (which I've wanted to do anyways).
9. Now #Netlify is confused that I have both an 11ty and Vite project and fails, asking me to pick one.
10. I pick one in `netlify.toml`, but a bug in Netlify refuses to accept it. -
Over the last few days while working on an upcoming blog post I've performed quite the yak shaving:
1. I wanted to use `@layer` in a #CSS demo (ironically one showing that it doesn't solve this particular use case).
2. My auto #CSP setup using #JSDom and #CleanCSS failed to parse `@layer`.
3. I upgraded #CleanCSS.
4. I removed #JSDom and replaced it with #parse5, which works with `@layer`.
5. I wanted to use `Object.groupBy` here which requires `target: "ES2024"` in #TypeScript.
6. Therefore I needed to upgrade TS.
7. Upgrading TS broke #Karma for reasons I couldn't understand.
8. Therefore I migrated from Karma to #Vitest (which I've wanted to do anyways).
9. Now #Netlify is confused that I have both an 11ty and Vite project and fails, asking me to pick one.
10. I pick one in `netlify.toml`, but a bug in Netlify refuses to accept it. -
Over the last few days while working on an upcoming blog post I've performed quite the yak shaving:
1. I wanted to use `@layer` in a #CSS demo (ironically one showing that it doesn't solve this particular use case).
2. My auto #CSP setup using #JSDom and #CleanCSS failed to parse `@layer`.
3. I upgraded #CleanCSS.
4. I removed #JSDom and replaced it with #parse5, which works with `@layer`.
5. I wanted to use `Object.groupBy` here which requires `target: "ES2024"` in #TypeScript.
6. Therefore I needed to upgrade TS.
7. Upgrading TS broke #Karma for reasons I couldn't understand.
8. Therefore I migrated from Karma to #Vitest (which I've wanted to do anyways).
9. Now #Netlify is confused that I have both an 11ty and Vite project and fails, asking me to pick one.
10. I pick one in `netlify.toml`, but a bug in Netlify refuses to accept it. -
Over the last few days while working on an upcoming blog post I've performed quite the yak shaving:
1. I wanted to use `@layer` in a #CSS demo (ironically one showing that it doesn't solve this particular use case).
2. My auto #CSP setup using #JSDom and #CleanCSS failed to parse `@layer`.
3. I upgraded #CleanCSS.
4. I removed #JSDom and replaced it with #parse5, which works with `@layer`.
5. I wanted to use `Object.groupBy` here which requires `target: "ES2024"` in #TypeScript.
6. Therefore I needed to upgrade TS.
7. Upgrading TS broke #Karma for reasons I couldn't understand.
8. Therefore I migrated from Karma to #Vitest (which I've wanted to do anyways).
9. Now #Netlify is confused that I have both an 11ty and Vite project and fails, asking me to pick one.
10. I pick one in `netlify.toml`, but a bug in Netlify refuses to accept it. -
-
`jj new` feels like it will take some getting used to, I'm not convinced the Git integration is *quite* there yet, and I really want to name individual commits. I think you can kinda solve that last one with bookmarks, but it's clearly not the intended use of them.
I wasn't able to get the diff editor working with #Meld, which is a shame because moving content between commits is an area I frequently struggle with and feel there's better UX opportunities out there. Hopefully I can get that working at some point in the future.
https://jj-vcs.github.io/jj/latest/tutorial/#moving-content-changes-between-commits
-
#rules_prerender can actually do this and it's a very powerful feature, but using it in that ecosystem requires buying into a much larger toolchain not everyone will want.
https://github.com/dgp1130/rules_prerender/
I'm imagining a more flexible, standalone tool which could be effectively used in any web toolchain.
-
@passle The full repo is here with the relevant source code, explanation of how it works, and some notable caveats.
https://github.com/dgp1130/out-of-order-streaming/
It's a very cool idea to incorporate into any #SSR component model using shadow DOM. I'll have to consider it for #rules_prerender if and when we get to SSR support.
-
@surma @jaffathecake Very cool stuff! I'm a big proponent of build systems and I've always been frustrated with how web devs seem to couple bundlers and build systems together into a single tool, when they are completely different concepts. Would love to see more build system usage in the web space!
On the #Bazel front, I happen to be working on #rules_prerender, a ruleset for doing static site generation in Bazel, built on top of #aspect_rules_js.
https://github.com/dgp1130/rules_prerender/
It's maybe 90% feature complete towards 1.0, but unfortunately not yet documented. I've been distracted and haven't had the time to builds the docs site (examples are more thorough if you can follow what they're doing).
https://github.com/dgp1130/rules_prerender/tree/d5c9ac48b2f221d64c9bf9bf9b026e859f29a56e/examples/
I don't know if that would be useful for you, but I figured it tied in with the web + build systems + Bazel theme so it might be interesting to you.
-
Are there any good #web conferences / meetups with an #RFP open in the #BayArea or virtual?
There are a few projects I've been working on which I'd love to give talks about and share with the community (not Angular related). Could be talking about any/all of:
1. #HydroActive - A different take on hydration in an HTML-first world. https://github.com/dgp1130/HydroActive/
2. #rules_prerender - A #Bazel ruleset serving as a fast and scalable #StaticSiteGenerator. https://github.com/dgp1130/rules_prerender/
3. #HTMLFragments - A no-tooling, web standard-based approach to HTML over the wire. https://blog.dwac.dev/posts/html-fragments/Greatly appreciate boosts for reach!
-
This change also has a side benefit of giving you full control over the `ts_project` which compiles your prerendering logic. No more awkward wrapping in #rules_prerender, much cleaner!
-
Just landed a major update to #rules_prerender yesterday. I redesigned the core component API to better express dependencies between different "slices" of a component. For example, if you only depend on the client-side JavaScript, the bundler will still find the associated CSS styles.
https://github.com/dgp1130/rules_prerender/issues/40
Really excited about the direction here! Next step is the actual documentation site.
-
Speaking of not writing documentation: I also prototyped a very cool idea for how to greatly simplify the developer experience of #rules_prerender *and* make it understand even more complex dependency graphs.
Still more experimenting to be done, but I'm hopeful this is a viable strategy and will be a big improvement for developers! 😁
-
Released a new version of #rules_prerender with full #Preact support built-in.
https://github.com/dgp1130/rules_prerender/releases/tag/releases%2F0.0.27
Getting closer and closer to something I'd be willing to call a 1.0.0!
Biggest open issue is still actually writing all the documentation, though I keep getting distracted by other features.
-
After a lot of work, I've finally landed a release of #Bazel #rules_prerender which is compatible with #aspect_rules_js! https://github.com/dgp1130/rules_prerender/releases/tag/releases%2F0.0.17
This has been a long time coming, and the issue shows how big a change this was (https://github.com/dgp1130/rules_prerender/issues/48). It didn't help that I kept getting distracted with other things and forgot everything I was doing. 😅
#aspect_rules_js does seem like a solid improvement and it sets up #rules_prerender for a lot of awesome improvements in the future (#ESM, #bzlmod, better bundling, etc.) Super excited about where we can take this next!
Shout out to @alexeagle and Greg Magolan (who I don't think is on Mastodon?) for their help, couldn't have done it without you!
-
A sincere "fuck you" to #GetYourGuide (and any other app) which listed a tour fully online, let me pay and complete the transaction, and email me the result. But instead of emailing me a QR code, it emails me a link to their *native app*, forces me to install the 40 MB binary on mobile roaming data, remember the password to log in to the same one-off account made to purchase the ticket, *and then* show me the QR code to show the tour guide. Just email me the damn QR code!
This accomplishes *nothing* but adding 14 clicks, 5 - 20 minutes to the check in time (depending on how easily the user guesses their password), and requiring a mobile data connection.
-
"New frameworks are using compilers to optimize the code you write into efficient DOM operations, like #Svelte and #Astro."
Me: *cries in #Angular*
"I think there's a framework that does everything with template literals"
"I think you mean #HTMX"
Me: *cries in #LitElement*
-
Great post on #ClosureCompiler, it's history at #Google and how it evolved compared to #TypeScript.
https://effectivetypescript.com/2023/09/27/closure-compiler/
I can help with one of the last points:
> True to form, this tool [tsickle] is open source but pretty inscrutable to an outsider. It may be used by Angular but I couldn't tell.
I can confirm that Angular does *not* run `tsickle` or Closure in user projects with `ng build`. There was an experiment some years ago where we tried this to see if we could improve bundle sizes, but found that asking users to write Closure-optimizable code was too difficult and hard to justify outside Google. As a result, we never ran this in prod.
I believe we do technically run `tsickle` in Angular GitHub repositories, as we have a unique build system setup with #Bazel and #rules_nodejs. If you've ever contributed to Angular, you probably ran `tsickle`. We've been trying to remove this dependency, but I don't think it's happened yet.
-
I really like #Radiance as a boss fight in #HollowKnight, it's really clean and reads so well with obvious answers for each attack which are just complicated enough to be hard to execute.
But #AbsoluteRadiance is too far I think.
-
I've been working through #EldenRing #ShadowOfTheErdtree trying to nerf myself to keep the bosses challenging. So far I've actually managed to do almost the whole thing with 0 Scadutree fragments.
I've been intending to upgrade when I hit a wall, but I've managed to get much further than expected.
The two bosses I'm currently stuck on:
#Metyr one shots me too much such that I'd have to do it practically hitless and I just don't want to do that.
#Bayle actually doesn't do that much damage, but he has a lot of health and once my buffs run out the fight SLOOOOWS down. Debating pushing through that one just cause I like Bayle.
Other than that, the only two bosses left are #Romina and #Radahn. I can't imagine I'll get through Radahn without some amount of upgrading, but I've gotten far enough that I'm wondering if I can actually see it to the end. We'll see if I have the patience for it.
-
CW: #EldenRing #ShadowOfTheErdtree Final Boss
I'll have to cheat #Radahn back to life just so I can have a real opportunity to learn his phase 2 moveset.
Other than that, I'm excited to try out some more new weapons and builds. Lots of cool stuff in the DLC for sure!
-
CW: #EldenRing #ShadowOfTheErdtree Final Boss
So #Radahn was definitely cool and has a pretty interesting moveset however I think is scaling is utterly messed up. I found him to be impossibly tanky until I respecced into a completely different build and then beat him in 15 minutes.
I basically had a #Rellana build going in using her twin swords. Except these swords absolutely suck against him. The light and heavy attacks are too slow to punish many of his lighter moves and don't do enough damage in the bigger windows. Uncharged R2 is usually the best option, and it's not great.
Moon-and-Fire Stance fares a bit better. The magic projectile is a decent punish and the flame spiral does significant damage. But none of his moves can really be punished by the full spiral, he always trades a blow with you. In phase 1 that trade is *usually* worth it, but phase 2 utterly wrecks you eliminating that option and heavily nerfing your damage.
-
Anyone have any good home camera recommendations? I've been using #Nest but frankly I just don't think it's a very good deal.
* The #GoogleHome and Nest apps have different features I can't make sense of.
* Apparently #NestAware lost 24/7 video history at some point.
* Event history is super precise. I can't rewind even a few seconds before an event was detected.
* It's expensive: Aware is $80/yr, Aware+ with 24/7 video is $150/yr.
* The app has really poor performance and is awkward to use (performance has gotten better lately but still not great).
* Never really figured out how to export videos correctly.I just don't like it and think I'm overpaying for this. Are there better options out there?
-
Looking into the current state-of-the-art for #NodeJS security and I'm kind of baffled by how primitive it is compared to browsers.
* No #TrustedTypes.
* No `SafeHtml`.
* No #ContentSecurityPolicy.
* No permission abstractions.
* Not even a way to ban `eval()`.Best thing I've found is `--frozen-intrinsics`, which is interesting, and I don't think there's a browser equivalent. You still have to freeze `globalThis` though to get much value out of it.
https://nodejs.org/en/docs/guides/security/#monkey-patching-cwe-349
There are also some interesting security policies, which look like they have a lot of potential. However they're all experimental right now and seem focused on code integrity.
https://nodejs.org/api/permissions.html
This this really the state-of-the-art for #Node security right now? Am I missing something?