Been there. Nagged the city of Seattle for nearly two years about fixing their insecure digital wallets, and in return they just acted weird to me and never really fixed the problem. Wouldn't tell me anything not even the vendor so I could communicate to them that this issue could exist elsewhere. The goal of these tactics is to delay long enough that you give up on publishing. So publish. Just be ethical and stay within the bounds of the law on what you access and release.
> I think that this comment is a great example of the total disconnect these conversations always have.
If we're being fair, the same could be said of this comment, which goes on to make some assumptions. One guy giving an anecdote that is not a web app does not prove much. I've built award winning web apps with progressive enhancement. It takes less code, less time, the performance is better, and they can be just as interactive. We need to stop looking for the weaknesses in each other's arguments and look for their strengths. I'm guilty of this as well.
yeah idk either I didn't read it carefully enough or it was edited at roughly the same time, because I thought I was responding to something very different.
Listen, if you're losing track of the date in your date picker as implied previously, then I don't know what to tell you man. Not a problem I've ever seen with progressive enhancement, and I've worked on more complex user interfaces than most. I have witnessed people struggle to solve state-related issues in SPAs for even relatively simple problems though, where the solution would be trivial in vanilla js. If it's not for the performance, and it's not cutting down development time, then what is the endless framework churn really accomplishing? Because that js date picker from twenty years ago still works.
This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vanilla JS is superior to React in terms of performance.
Maybe I'll write a blog post on it someday. It depends on the exact method you use to build the calendar my man. You could just change classes and attributes. Or you could use a variable within the scope of where you initialize the component. I wouldn't re-render the whole thing to apply changes, but that's up to you. The nice thing about using vanilla APIs is you don't typically have to worry about thrashing the DOM with unnecessary renders because that's rarely (perhaps never?) the easiest way to patch changes to it, unlike in React where useMemo is prevalent.
State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.
Building for scale is something that should usually be done incrementally. For systems where the speed at which workers pick up jobs isn't super important, let's be real, almost anything durable can work. Simple queues are easy enough to swap out in my experience that making the sub-optimal choice at first is probably fine, so long as you remain flexible to the idea of switching to something else later. Peace of mind comes from observability. The one thing I would caution is that it is a lot more difficult to evolve complex systems into simpler ones (e.g., going from a tool meant for event streaming to one just focused on queuing).
The only way for China to lose influence in this fight is by playing ball. They can simply continue to trade with the rest of the world and be totally fine when it is US consumers paying the bill.
The MIT license does not seem to dictate the exact location of inclusion. Logically, I would think you would want to associate it with the specific parts of code that you are copying. In the past, I've listed licenses together in the root license file for forks, and other times when the included code was a minor part of the overall project placed forked licenses within impacted files.
I used to freelance full-time. Having freelancers on full-time indefinitely is usually just bad management, but the economics make a lot more sense for temporary and part-time work. If you only need someone for a few months of labor out of the year, then hiring them full-time is going to be way more expensive than contracting-even with a substantially higher hourly rate. Also, at least in the US, freelancers need to charge more to just break even with full-time employment rates due to taxation and benefits.
This is something I've been wanting for a while. You could probably build an extension to accomplish that. One hard challenge would be extracting content and then displaying it in a way that retains its semantics across the web, including navigation, sidebars, etc. Another would be form handling.
Yeah the playbook for serverless is to target developers that don't know anything about infrastructure, lock them in with proprietary APIs, and then hit them with a huge bill once they have any real traffic.
For a public website? Well if you don't have thousands of pages, then the solution would be as simple as installing Varnish, which is good practice anyways. If you actually have enough unique paths for an unauthenticated botnet to saturate, well that's a bit more complicated.
Hah yeah I don't necessarily believe it's all a generational thing, because I see it in the older folks as well. And every generation has had its masculinity grifters. This one is obsessed with porn. The biggest generational differences I've noticed are that women seem to need men less, people are losing shape at earlier ages, and a lot of people have become very outspoken about distrusting members of the other sex. Just from those factors I think it would be natural to see increased competition for the people who have everything together.
It is a natural human tendency to shift blame to external boogeymen, but to speak frankly, I think there's something deeper going on with the loneliness epidemic than nudey videos on the internet. A seemingly large chunk of both sexes have major personality issues that prevent them from getting along with each other.
I seriously doubt that people are petitioning their secretary of states to keep online documentation terrible. If I had to guess, the explanation is probably something much more boring, like their employees not being incentivized to do the work.
Would like to second the turbo rec. I've had good results with it for nontrivial use cases. Would like to hear from people if they have different experiences. Also, praying that everything gets cached first load and hand waving that view transitions will eventually work is not a position I want to hear from an engineer in a commercial context. Really happy to see the author bring more attention to how good vanilla web technologies have gotten though.
Either that or misconfiguration with the benchmark setup. A quick google search indicates this can happen with some setups. Maybe try looking at other Caddy benchmark code.
The common issue I run into with all LLMs is that they don't seem to be able to complete the same coding tasks where googling around also fails to provide working solutions. In particular, they seem to struggle with libraries/APIs that are less mainstream.