wyqydsyq's comments

Another great resource for learning about multiplayer game networking is this guide from Mikola Lysenko: https://0fps.net/2014/02/10/replication-in-networked-games-o...

I've only had a quick glance but this book looks fantastic, saved for later reading and will definitely consider buying the ebook.

I've been teaching myself 3D/CG programming in my spare time using free web resources, I've been trying to learn it "the hard way" by doing everything relatively from scratch, instead of using a high-level engine I'm using low-level libraries writing my own shaders and implementing my own scene graph etc. This book really seems right up my alley and looks like it'll teach me a lot.

For anyone else similarly interested in learning to do CG from scratch (particularly on the web), some other great resources I've found are: https://thebookofshaders.com/ https://webglfundamentals.org/

This paradigm reminds me a lot of my favourite JS/TS framework at the moment: Cycle.JS https://cycle.js.org/

I think most PWAs are essentially front-end clients to a SaaS, so revenue typically comes from user subscriptions.

Other than that like another user mentioned there's any monetization methods on the web at your disposal (advertising, microtransactions, donations etc) it really comes down to what business model you want to operate on and what seems most natural for users of your product.

As far as a "buy it, you own the copy" model like with traditional media software and games go I don't think there is anything universal to use, most developers would implement their own licensing in their billing/accounts layer and expose a serial key or something that local data gets encrypted with as a rudimentary DRM, so the app can only be used later by having the right serial key (whether from LocalStorage/cache/a fresh login) for that paid user to decrypt and use their local data.

It would be interesting if some service like PWA Store were to offer some kind of universal DRM to developers wanting to sell offline PWAs on a one-off sale format that they can easily wrap their app bundle in

How has the web been tainted with ads?

Many sites people have put on the web based on their business decisions are, sure.

But that doesn't mean the core technology has been fundamentally tainted, any business not operating on a model of generating revenue from passive views generally doesn't display ads on their sites/in their products.

Yeah it's a trade-off and button links what this person would be experiencing.

General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.

> Isn’t this exactly the time our tax-funded government should step in and prop up successful companies, small, medium, and large.

Yes but that doesn't mean they should rescue companies that were a house of cards waiting to collapse before all of this started

Would have been even more embarrassing if the Redis site was down with a MySQL error

Man I would absolutely LOVE to see IBM suing the pants off of Oracle and sending those muppets into insolvency. I don't think there is a single company in the software industry more widely hated than Oracle today, it seems to me they have devolved into mere patent trolls because they couldn't figure out a way to adapt their business model.

Yeah fair call and it's more the combination of PHP + jQuery I'm referring to as being non-deterministic rather than either on their own - you can definitely write deterministic PHP and jQuery code, but the implicit integration between them (PHP rendering HTML which becomes a DOM which jQuery imperatively operates on) is what I'm saying makes it non-deterministic. I'm mostly talking about the part you mentioned in managing client-side state using a non-declarative paradigm, where you either end up with a stupid amount of unnecessary complexity (conditions checking the prior state of literally any and everything you touch, I've never really seen this in a production project) or making naive assumptions about the DOM which means non-deterministic and potentially unexpected behaviour.

> If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!

Fair point but there's also a flip-side to this though. You can write a client-side PWA with all your async state and data persistence magically handled by a service like Firebase Cloud Firestore, so just writing the UI declaratively and not having to worry at all about servers or databases, which generally requires a lot more upfront planning (figuring out models/schemas to represent your data, service architecture etc) than just slapping a UI together and wiring inputs up to a production-ready persistence layer API in front of a schemaless NoSQL DB like Firebase.

> If you don’t know how your code will work, that’s an issue with the quality of the code.

No, it's a fundamental difference between declarative and imperative programming. With imperative programming (e.g. PHP + jQuery) you cannot know what's in the DOM resulting from PHP-generated HTML you are working with, you need to either make naive assumptions about the DOM or litter your code with conditions checking the state of the DOM before operating on it. With declarative programming you declare the structure you want, so you know exactly what you have, because it's what you've declared. There's no need to check that the PHP backend rendered some element to the DOM to enhance with JS functionality, because I already declared that element is in the DOM in my JS directly.

> With a language like PHP, if you call a function twice with the same input, why would the function return 2 different outputs?

Again, this has nothing to do with languages and is purely about programming paradigms. What you're referring to is one of the possible "islands of functionally pure, declarative code" I previously mentioned. Pure functions in PHP can be deterministic, and pure functions in JS can be deterministic, but the overall application behaviour of how your front-end (jQuery) handles the output of your back-end (PHP) results in the application being non-deterministic. For example, say you have some form that submits data and on the posted page, displays a green thankyou message in a div. Say you want to animate this div message with jQuery. You cannot safely make any assumptions about the presence or prior presentation of the div, because from the context of jQuery you don't even know if the form has been submitted and the div rendered by PHP. You need to either: - Imperatively check the current state of anything you wish to change prior to changing it. - Naively make assumptions about prior state resulting in non-deterministic behaviour.

jQuery makes this easier by solving that problem on node "existence" with their selector-based API which simply doesn't run your function if the targeted nodes aren't found, but the problem still remains for general state, any jQuery code needs to either explicitly check the state of everything it touches (brittle code, hard to reason about and maintain) or make naive assumptions and be non-deterministic (which seems to have been the norm).

> The output of this is deterministic. Given jQuery works, the element will resize and change color.

False, it is non-deterministic because the ultimate outcome (what you see) depends on implicit state from side effects. For example if you toggle the resize control, the resulting display is based not only on your action (input) but also whether the colour change button was already pressed (an unrelated side-effect not a concern of the logic for resizing), or if PHP initially rendered it in a different size/colour, or maybe PHP decided to not render it at all because the user's session ended? From the context of jQuery you can't determine any of this, the only way you could come close to deterministic behaviour is by explicitly checking every single bit of stateful DOM before working on them, which I've never seen done in a large project (and would be hell to maintain).

> If something is deterministic is dependent on the algorithm it has.

Yes and any algorithm which has its outcome impacted by side-effects or unmanaged state (i.e. pre-rendered HTML/DOM from PHP, changes to DOM from other side-effect causing callbacks) is inherently non-deterministic. For an algorithm to be deterministic it needs to take every single thing that could affect it's outcome into consideration as input, and I have yet to see any jQuery apps which parse the entire DOM and use it as input to achieve deterministic behaviour

> The assumption here is that declarative is deterministic and anything else isn’t and that’s just not true.

No my point isn't declarative being inherently deterministic, rather that imperative is almost always inherently non-deterministic. By the nature of imperative programming you are making assumptions about your environment (i.e. there's DOM nodes to work with) which makes it intrinsically non-deterministic (those DOM nodes could not even be there)

I can't see JavaScript SEO ever being a thing, especially when most people these days just add SSR to their stack and call it a day

It isn't. I elaborated a bit in my later comment: https://news.ycombinator.com/item?id=22523344

> How is that not the definition of a function or a method?

It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out.

> Deterministic in what sense? It’s output? It’s input?

What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output. PWAs are generally deterministic because they're just functions that take an input and give you back a DOM. Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input, it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.

> Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.

This has nothing to do with languages, it's about project architecture and programming paradigms. The classic webserver+jQuery type architecture is inherently imperative. Of course it can have little islands of functionally pure, declarative code, but the overall software architecture is still imperative.

In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.

To word it more technically, building an SPA allows you to build applications as declarative composable functions which are deterministic, as opposed to the spaghetti code commonly seen in the days of jQuery and PHP which is harder to read, reason about, debug and maintain due to their imperative and nondeterministic nature.

I too despise the "kitchen sink" approach seen in Gmail's UI where they are trying to cram every unwanted and unnecessary feature into your view and RAM at once.

If you used "Inbox for Gmail" before Google abandoned it and miss the much cleaner and focused UI, this Chrome extension upgrades Gmail to have the same styles:

https://chrome.google.com/webstore/detail/simplify-gmail/pbm...

> Svelte components compile to vanilla javascript plus a small runtime

Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library.

The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without having to learn yet-another-completely-arbitrary-templating-language to no benefit.

If it's a web-based user interface as this tax app sounds to be, it is arguably improved purely by being an SPA. Requiring full page reloads just to submit or change some tiny bit of data in a page is objectively bad UX.

Language barriers aren't relevant when the country you're outsourcing to has the same primary language. TZ differences are a non-issue for distributed companies already using JIRA and Slack for everything. Those two things would only even be a concern for the tiniest minority of companies.

I'm a software engineer based in Brisbane, Australia, I've worked for two US-based startups who were specifically growing their offices in Australia because it's cheaper to hire for the same roles here than in the US.

Does this mean I can sue Facebook because, despite my (unreasonable) demands they stop showing me fake news and ads for crypto-mining mobile games that pretend to be affiliated with legitimate news sources or the games they're knocking off, they haven't stopped?

I think that's a pretty comparable analogy because in both cases, a party is being unreasonably expected to police third-party content provided through their platform/business, or else be sued for failing to do something completely infeasible.