This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
What are “native data structures”?
Whatever data types are available in the programming language of choice here; Rust.
SvelteKit, Serverless, Backendless.com SvelteKit[1] is a framework for SvelteJS (like Next.js is a framework for ReactJS). I've tried both Svelte and React. Svelte seems to be more elegant and lets me implement my ideas faster with less code. Svelte is very flexible; SvelteKit adds some opinions on how to do things like routing. SvelteKit also embraces the serverless paradigm[2] (AKA JAMstack[3]). Although a node.js…
This whole thing feels like layers upon layers of complexity. Not to mention, the brittle aspects of any javascript project - immature, lack of robustness and dependability. Your stuff is working on Node v12? Good luck with Node v14 - both LTS versions. It is a shitshow. Let's keep Javascript inside the browser IMO. SveltKit is literally 2 months old.
"What novel tools are you using to write web sites/apps?" ??? is that not the prompt
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
What kinds of things have you made with your setup?
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
> I just keep everything in memory in native data structures and flush to disk periodically;
Can you expand on what you mean by this? I am interpreting that to mean that you are actually writing to a file and reading from a file rather than using SQL?
Semantic HTML, CSS, Vanilla JS, and JAMStack. Semantic: embed data directly in HTML. If I have a list of wines with categories, each wine's "class" attribute has a class for each category. HTML: can be generated by anything and consumed by anyone. Great SEO. CSS: These websites were all made with the same HTML, only CSS changing. http://www.csszengarden.com/ Let's imagine we have a checkbox, that when checked, should…
What happens when your wine types are dynamic? How do you typically bridge the gap?
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
No SQL database is the one thing I disagree with. What if you want to write a SQL query/report? Do you have transactions? As the app gets bigger you might want that.
Adding in a service like a SQL database because "you might want that" in the future is not a good idea. Apps should do what they need to do and no more. "Future proofing" is almost always a waste of time - even if you definitely want the feature in the future it's usually better to add it in when it's needed than adding it early and have to support something that adds no value yet.
As for reports and transactions specifically, noSQL databases support both.
This partially might be more of a what's old is new again, but here's what I use: - 100% server side rendered - Progressively enhanced (fully works without JS, but having JS enabled makes it nicer) - In select places where I need SPA-like snappiness I use a ~100 line long DOM diffing algorithm (I request full HTML through AJAX and diff it into the current page; if the user has no JS enabled then the page just refresh…
> I just keep everything in memory in native data structures and flush to disk periodically; Can you expand on what you mean by this? I am interpreting that to mean that you are actually writing to a file and reading from a file rather than using SQL?
They're storing their data in native Rust objects and read or write them in server application RAM. In case data becomes larger than available RAM, they have set up a large swap, which is a file or a disk partition that the OS uses when no more real RAM is available, while acting like nothing is happening (and everything gets 1000x slower). They periodically serialize these in-memory objects to a file on disk, and presumably (they didn't specify, but I feel it's implied) they're reading this file and deserialize it during initialization/startup phase.
react-three-fiber with the new three-stdlib library. It's an approach that enables much smaller WebGL apps through tree-shaking, and the dev experience is really good (Typescript, fast refresh, no bundling step, etc).