351–360 of 456 posts
Earlier quoted context omitted.
For what it's worth, the same happens in my Chrome. (Maybe you're logged in and don't get the behavior because of that?)
Should be fixed now if you want to try again :)
[1] https://99percentinvisible.org/episode/the-next-billion-user...
Earlier quoted context omitted.
I genuinely understood nothing to that comment. Are you talking about frames? Please develop.
I'm definitely not a mindless CTO. ;) Micro front-ends is the concept of breaking apart a front-end monolith. SPA's are usually built in one framework like Angular or React. Over time, this can get very convoluted and turn into a bad monolith (there are good ones). The second part is that instead of building screens, you design features (like invoices or customers or catalog) and develop the set of views that encapsu…
Based on this comment you do kind of sound like one. Could you elaborate on what you think 'Domain Driven Design' is, and what you think 'boundaries' are in the context of development? It would help dispel the impression I get that you're a clueless CTO who knows enough to be dangerous.
(apologies for being a bit rude perhaps; consider it a comment slightly in bad faith, but very curious to hear you prove me wrong)
Earlier quoted context omitted.
Just tried the app and immediately found the typical SPA bugs and quirks: - tried to add a recipe and nothing happened for so long (3-5 seconds) that I thought it was broken. Then suddenly the add recipe form finally appeared. Blazing fast! On your dev laptop maybe. - click payee, nothing happens. URL changes though. God I hate SPAs - adding an item to your shopping list causes a 'item added' popup to appear. Over th…
Thank you for the feedback! We'll take a look at these, especially the recipe form. For the shopping list alert issue, you should be able to dismiss the alert but I see where you're coming from. Regarding the colors, you can set whatever color scheme you want under your account settings. The images have always given us trouble, they should be cached but the painting seems like it occurs after load for some reason (I…
HTMX https://htmx.org/ LiteDOM https://litedom.js.org/ Stimulus https://stimulusjs.org/ Turbolinks https://github.com/turbolinks/turbolinks
I am quite a fan of HTMX and am using it for multiple projects now. I hope it continues to gain traction.
I've settled on Alpine instead for the time being because it has some data management built in. I'm thinking I'm going to have to switch to Vue on my current project because I feel so much less productive with Alpine.
Our app ( https://domestica.app/login ) is a pretty good (IMO) example of a blazing fast SPA. It uses Mithril and copious amounts of chunking to make the bundle size extremely small.
Was your comment just an attempt at some growth hacking?
Earlier quoted context omitted.
Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS. He used Puppet and remarked that you would only ever need what he was using for managing massive fleets of servers. Then Kubernetes and Docker arrived, which were intended for even bigger deployments in data centres. Before you knew it, just as with SPA's, Kub…
Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.
Earlier quoted context omitted.
This is one of the worst SPAs I've ever seen, simply because it causes an infinite redirect loop when clicking the back button and/or tampers with the browser history to make using the back button impossible.
Just tried the app and immediately found the typical SPA bugs and quirks: - tried to add a recipe and nothing happened for so long (3-5 seconds) that I thought it was broken. Then suddenly the add recipe form finally appeared. Blazing fast! On your dev laptop maybe. - click payee, nothing happens. URL changes though. God I hate SPAs - adding an item to your shopping list causes a 'item added' popup to appear. Over th…
Earlier quoted context omitted.
What most people have in mind as "idiomatic JS" isn't that. It's usually meant to refer to some patterns that appeared and started getting popular around 8 years ago. And often, code written in this not-idiomatic way works _against_ the language and/or the underpinnings of the Web in general. It's just that the circles promoting the pseudo-idioms have outsized and seemingly inescapable influence.
This is very vague. Can you give some examples?
Look at JS that's written for serious applications today, identify the stuff that you'd label as "idiomatic", and then look at code that was written 10 years ago for serious applications, and see if it matches what your conception of "idiomatic JS" is. Good references for the way JS was written for high-quality applications without the negative influence of the new idioms (because they didn't exist yet): the JS implementing Firefox and the JS implementing the Safari Web Inspector.
Examples of how "idiomatic JS" is often written by people who are working against the language instead of with it:
- insistence on overusing triple equals despite the problems that come with it
- similarly, the lengths people go to to treat null and undefined as if they're synonymous
- config parameter hacks and hacks to approximate multiple return values
- `require`, NodeJS modules, and every bundler (a la webpack) written, ever
- `let self = this` and all the effort people go through not to understand `this` in general (and on that note, not strictly pure JS, but notice how often the `self` hack is used for DOM event handlers because people refuse to understand the DOM EventListener interface)
- every time people end up with bloated GC graphs with thousands of unique objects, because they're creating bespoke methods tightly coupled via closure to the objects that they're meant for because lol what are prototypes
These "idioms" essentially all follow the same "maturation" period: 1. A problem is encountered by someone who doesn't have a solid foundation 2. They cross-check notes with other people in the same boat, and the problem is deemed to have occurred because of a problem in the language 3. A pattern is adopted that "solves" this "problem" 4. Now you have N problems
People think of this stuff as "idiomatic JS" because pretty much any package that ends up on NPM is written this way, since they're all created by people who were at the time trying to write code like someone else who was trying to write code like the NodeJS influencers who are considered heroes within that particular cultural bubble, so it ends up being monkey-see-monkey-do almost all the way down.