ShortFuse @ ShortFuse @lemmy.world

Posts

0

Comments

300

Joined

2 yr. ago

Double NAT with DMZ.

Those SIP ALGs are more trouble than they are worth. If you are using SIP devices, use a different outbound port on each device (eg: 5060, 5061, 5062).

SSR is a overloaded term.

• There's SSR to help improve FCP (first contentful paint). This is not really so much an improvement to the client side framework as it is a crutch to workaround the fact that the frameworks are dynamically constructed clientside. But the first paint would just be Root node which is essentially empty. Because React and Vue are so heavily tied to the DOM structure, it expects to be the compositor of the tree, not something written in HTML. For pure HTML to be the compositor, you would need to add some rehydration to React/Vue to take a pre-composed state and reintegrate it into what React expects.
• SSR is also used to dynamically build content that is presented to the user that is not necessarily tied to rendering. This is popular with PHP, where instead of putting a blank table and then having the client fetch content over JS and then populate that table, the server just hands you the precompiled HTML. Not all the data as sent over JS may be useful (eg: only 10% is used after filtering and pagination), so to save transfer size and query latency, it may be the server that gets the always data from the store or cache. There's less client JS in execution, which may also help in performance.
• Then there's SSR for the purpose of improving SEO. This relates more to the first point, but maybe the first paint isn't important. Maybe client-side construction is plenty fast. But because the root is just blank, search engines that don't perform synchronous JavaScript can't actually read the content being shown to the user after all the rendering is said and done.

Personally, I've moved to Web Components that solves almost all of this. You can author layouts in HTML and anything that you want in your HTML file for SEO is included in the source. I would only use SSR to target the second issue, where you want to save on trips to build dynamic content. It is somewhat wasteful to give clients instructions to fetch and render when the server can do that on the first trip. The issue is rehydrating, or picking up from that state, but that truly depends on how complex your Web Components are. If they are sparse and simple enough, then all states should be able to be expressed over attributes. First paint can be reduced with the template shadow root, but I feel it's more trouble then it's worth and has negligible performance gains compared to just doing a prerender JS to register components and the browser will only render synchronously what's in the viewport anyway. That means time to first paint is not dependent of how big your page is. It's only dependent on how many elements you want to register before DOMContentLoaded.

From a financial aspect, I'm not about to ditch static CDNs to reinterpret nearly every single request with some server for SSR. The costs are nowhere near the same to try to reinterpret with SSR. You can micro-optimize to death with a SSR to CDN route and then hydrate, but I feel you risk complicating deployments to where you're so vendor-locked you have extra hoops to jump to make changes. God forbid you want to change frontend systems. At that point the DX pain is too much to justify and wanting to get out is inevitable.

I've been in the SpecialK discord all of yesterday messing with stuff and went to bed.

Now I wake up and find that not only did they (SpecialK devs) fix the 8bit pipeline problem, but it paves the way for real HDR in all Direct3D12 games.

You have until launch day to return pre-orders and I was considering it, but we might have fixed HDR/black levels now.

Y'ALL actually stands for Yet Another Linux Lauding

As a PocketPC (WinMo) user before the iPhone even existed, I take offense to the claim.

They pioneered capacitive touchscreen for ease of use, but I had ditched dumb phones years before iPhone.

Note XDA refers to the old Windows Mobile XDA phone and then became an Android community. I was there for that transition and none of us were very impressed with the iPhone, but understood that it would be something for the tech illiterate would eat up.

When Android came out, we went from Custom Roms for WinMo to Custom ROMs for Android.

KAKATTE KOI!

(EVEN LOUDER GAMECUBE CONTROLLER NOISES)

Yes in Windows Server since, IIRC, 2012". No in Windows client versions.

I'm so used to Server commands I sometimes am surprised when commands like logoff don't work.

Are PWAs "only" websites that are shown as an app or do they have features that would distinct them from "normal websites"?

In theory, they're the same. In practice, user agents (read: browsers) can dictate extra, uh, privileges to PWAs. For example, Safari Mobile won't allow push notifications for just websites. As a dev, we don't control this aspect. We just code "isPushAllowed()` and continue from there. As a marketer or apps/software I learn what browsers and environments allow what, so I know they need to install as a PWA to get access to some APIs.

Can PWAs reserve disk space for offline downloads for example (Spotify has got a PWA but that one is mainly their website shown as an app).

Branching off the other point, it's up to the user agents. For example, Safari Mobile will delete storage for websites after a certain time (I think 6 months). But PWAs have unlimited lifespan (a misconception years ago). It's not what you asked (storage size vs lifespan), but it gives you a clue to how browsers manage this. I personally haven't experienced much issue with storage, but I do know there's even a File API which gives access to your actual drive. I would imagine if browsers are allowing us to access "unlimited" storage over the file system, the restrictions for the Local Storage aren't that important.

A short search brought me here which mentions 80% of total disc space for Chrome, 50% for Firefox, and 1GB for Safari. Nothing here talks about PWAs, but I'd imagine Safari is the only one worth concern. I can research more if you want, but it's not in my use case to concern myself with local storage.

Edit:

And I probably can't install a listener via PWA like Discord does for their Rich Presence, can I?

As long as there's an API, for better or for worse, we can do it in PWA. From what I read, there doesn't seem like anything like this in the Web API. Background tasks are currently somewhat restricted in the interest of battery conservation of mobile devices. From a theoretically point, an app running in the same environment as the PWA could have somethig shared between them. There are API in addition to Web APIs, like extensions, but there's probably a lack of normalization for detecting what is running on the device.

The idea of making everything in the Chrome Addon/Extension API in to real API is part of Product Fugu and from looking Chrome never built anything to expose what native system processes are being run with a web site. It's honestly such a specific (and invasive) prospect I doubt it'll ever happens. The closest is chrome.tabs but there's no web equivalent.

Sharing of other PWAs running probably won't happen because sandbox/isolation is pretty core to Web right now. Cross-app data sharing is something I don't know about yet, but maybe if PWAs mature we'll see that. Then games and media players can "broadcast" to other PWAs data like presence. I'd imagine that branch from the Web Share API.

I'll take this opportunity to state my bias. I believe in the Web standards, meaning it shouldn't matter what browser or environment you use. They should all be the same. I want this for myself and express this to my clients.

But because standards are "living" it's always a moving target. What is supported today by your preferred setup may not take full advantage of what a Web App provides. But the idea is, after a while, you will gain those features later in your setup as browsers get better.

This is something I've seen in practice since I wrote a lot in PWA and told my clients that eventually it'll be in Safari, but I'm not going to write a native app for outdated browsers. And the investment paid off. Before, Safari users didn't have Wakelock, Push, or good WebRTC experience, but today they're mostly indistinguishable from Chrome Android. I didn't have to change a single line of code to make that happen.

You wrote:

To mitigate problems caused by DRY fundamentalisms, the "write everything twice" (WET) principle was coined.

I'm listing when and how it was coined with the article that coined it. If you have another source to claim it wasn't in the fashion I've described feel free to provide sources to the contrary. I even sources it from the very Wikipedia entry you shared.

WET is a clear guideline

Again, feel free to provide sources to back up your claim.

Your comment sounds like a weak attempt at revisionism.

Again. Feel free to back up your claims with actual sources. The concept of AHA by Kent C Dobbs, of Angular fame says:

There's another concept that people have referred to as WET programming which stands for "Write Everything Twice." That's similarly dogmatic and over prescriptive. Conlin Durbin has defined this as [...]

https://kentcdodds.com/blog/aha-programming

He then goes on to link to the article/blog I mentioned where Durbin states:

Instead, I propose WET programming.

And he goes on to explain this new concept of Write Everything Twice.

If you actually interested in discussion about the debate of DRY/WET/AHA, I'm all for it. But don't misinterpret or try to change what is already well-written.

Also, don't throw accusations at people who provide you documentation and proof and then contest while providing absolutely none yourself. That doesn't sound like any earnest interest in discussion.

About 8 years ago now I ditched .NET, Java (Android), and Objective-C (iOS) to JS in frontend and backend with NodeJS and PWAs and couldn't be happier for a dev perspective.

All frontend is just one code. Sure, you have to manage browsers compatibility, but it's not a major issue. Mobile users and desktop use the same application. I didn't know Firefox dropped PWA on Desktop, though most of my desktop users were using Edge or Chrome. I can only think of one client that used Firefox and it worked fine, except for Firefox has some out of spec EventSource bugs. Safari has gotten better (especially after 16.4) now where I would Firefox as the leading source of browser issues when developing. Also, Safari 17 looks to finally treat PWAs with some legitimacy. We even have Push notifications now!

I don't understand Firefox's decision, but Firefox on Android still supports PWAs on Android. But if they no longer care about desktop PWAs then I'll give Firefox less importance for desktop environments. Probably doesn't mean much in testing, but that means if I find a Firefox exclusive bug related to desktop (eg: mouse), I might just ignore it.

I would highly recommend PWA over Electron. There's nothing better than getting clients to transition to your software from a competitor with just a simple PWA with no install. I also support as far back as Chrome 88, which means any EOL ChromeOS device is still supported.

You might need newer APIs depending on usage, but I haven't found anything that I need to tap into some sort of native runtime for core usage. Maybe WebRTC runs better on newer Chrome, but nothing really requires native code. It's just easier to maintain one single codebase without locking out potential clients because of OS (desktop or mobile).

Free frogurt with your choice of toppings.

WET is not what you think it is, or at least not originally. It's not some alternative to DRY. It didn't stand for Write Everything Twice. It stands for Write Every Time. It's supposed to be a negative way to describe code that isn't DRY. It's also abbreviated as "Waste Everyone's Time".

Much, much, much later somebody tried to reuse the term for "Write Everything Twice" but talking specifically about the benefits of singular, repeated templating because the abstraction needed to refactor code into "Write-Once" can make things harder to understand. In other words, it creates a chain of pre-required knowledge of how the abstraction works well before you can even work with it.

The irony here is that DRY is not really about code duplication. It's actually about system knowledge (structures and processes) being clear and unambiguous. Or, applied, you, as a person, not having to repeat yourself when it comes to sharing knowledge. It lends to simpler constructs that don't need much explanation. The example given of Write Everything Twice is actually being DRY, but they don't realize it.

Bill Venners: What's the DRY principle?

Dave Thomas: Don't Repeat Yourself (or DRY) is probably one of the most misunderstood parts of the book.

Bill Venners: How is DRY misunderstood and what is the correct way to understand it?

Dave Thomas: Most people take DRY to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that.

DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

https://www.artima.com/articles/orthogonality-and-the-dry-principle

The article/interview explains more about how DRY is meant to work and even talks about the pitfalls of code generators, which the WET article complains about (React).

The misunderstanding since DRY's coining is probably because, like natural language, we change meanings we with our environment. DRY became a term people use to blast too much abstraction. But noisy abstractions are not DRY. In response we have a new term card AHA (Avoid Hasty Abstractions), which exists as a counter to what people think DRY is.

The TL;DR is DRY is meant to mean your code should be unambiguous, not some sort of mantra to deduplify your code. Apply its original principles, and follow AHA which should be a clearer safeguard to avoid your abstractions not following DRY.

With Gas? Too Spurious.

It feels very overpriced considering it's just a streaming device and doesn't have OLED.

A hacked Switch with PS Remote Play makes more sense. Heck even a PS Vita has OLED and already supports Remote Play from a PS5.

Or having a few screws loose / not all there.

It appears he did not do it all for the nookie.

maurymeme.png

Make an iPad Mini competitor with stylus support.

I don't need a tablet as big as my laptop, but with less features.

It kinda annoys me that the lowercase L glyph is taller than capital A. I don't mind there being a difference, but cap-height should be taller than lowercase letters.

Illuminati

Essentially, when summer hits, US is hotter than Europe. Canada has the same temperature in summer.

New Super Mario Bros. U Deluxe has Toadette and Peachette.

Super Mario 3D World has Peach / Cat Peach.

My daughter beat them both at 5 years old. There's also Mario Kart 8 which also has Peach. You may be noticing a theme here.

There's also the Lego games where you get to choose your character and she always picks the girls.

Miitopia is great because you create your own characters. She makes the entire team girls.

My Friend Peppa is kinda entertaining, but she didn't really care for it all that much.

Kirby is pretty great and both games Return to Dreamland and Forgotten Land are accessible, though both ramp up difficulty later. (Kirby is gender neutral)

There are more games out there, like Kena, Metroid, Celeste, Shantae, but not for her age yet.