641–650 of 715 posts
Earlier quoted context omitted.
It would have to be some kind of web of trust thing. But no, I don't have any specific suggestions to that effect (which is why I believe that HTTP should remain an option).
What about self-signed certificates? That's still better than plain HTTP.
Earlier quoted context omitted.
I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format . HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less…
Are you implying there exists a better way of making UIs that just hasn't taken over the world for some reason? I also don't like the state of the web.
Earlier quoted context omitted.
Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from: 1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to; 2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/r…
Right, I agree with all of this. My point was always that requirements vary and it's pointless to talk about frameworks-vs-no-frameworks unless you're clear up front what your requirements are. In this particular site's case, the requirements are met by WordPress, so "a WordPress blog" is a simple description of what it is. It wasn't meant to include a value judgement.
Earlier quoted context omitted.
Many years ago—2002!—Joel Spolsky wrote this: https://www.joelonsoftware.com/2002/05/06/five-worlds/ His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools. The worlds he quoted were Shrink-wrap; Internal; Embedded; G…
Shrink-wrap is still very much a thing, even if distribution is entirely digital in most cases. It's dominated by internal line-of-business apps, sure, but that was true back then also.
Of course, Shrink-wrap 2020-2025 is not exactly the same as Shrink-wrap 1995-2000. You mentioned digital distribution. Speaking from my lived experience... We shipped software on golden masters that were used to manufacture DVDs at scale.
At that time, the entire software industry worked on long release cycles because of the friction of shipping software on manufactured media. And in those days, people read physical dead tree computer magazines, which had long lead times for articles. This affected software development, because months before we were scheduled to "ship," we were sharing screen shots with journalists, doing interviews, and placing stories in magazines timed to drop when we released.
I remember a death march to get a product ready so that we'd have DVDs to give away at JavaOne in the Moscone Center, where our CTO was scheduled to give a talk. The way software was distributed in those days all strongly influenced the way companies attempted to manage software development.
I know I am in the VAST minority, or perhaps the only one, but I cannot stand frameworks. Sure, there may be a lot of power in them, but there is also a lot of bloat and complexity. IMHO, this "power" can easily be achieved with libraries instead of an IOC framework. After you learn a, typically terse and confusing, framework language, you have to know that framework language along with the base language (Java, C#, J…
I've built a library to make vanilla webcomponents reactive via a manual render() call that updates only changed nodes: https://vorticode.github.io/solarite/ I was planning to improve performance more before announcing it. But even as is it beats React and approaches Lit.js on the JS framework benchmarks.
I've done something similar to this for my own internal applications, making use of snabbdom to handle the DOM updates. Snabbdom is tiny, robust, proven, and unopinionated; so I didn't see any particular need to reinvent that wheel.
Earlier quoted context omitted.
Except this is pure fantasy and AI is uniquely unreliable and error prone.
> Except this is pure fantasy and AI is uniquely unreliable and error prone. Is this perhaps why Microsoft is in a uniquely good spot to take advantage of AI for customer facing software? If customer expectation of your software is already that it's horribly unreliable and error prone, AI bringing more of the same may not really hurt...
I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?". I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. A vast majority of the hours I've spent building web sites & applications has been devoted to admini…
I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one? I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to. There are so many way to do commerce both on and offline…
Earlier quoted context omitted.
Yes. I’m happy to do whatever makes the most sense in any given situation. I have never in my life thought to myself “I could easily help solve this problem and make everyone better off, but I will refuse because problem-solving is work and work is only for employees.”
> I’m happy to do whatever makes the most sense in any given situation What makes the most sense in this situation: you walk to the nearest pizza place, you buy your pizza, done. To an able-bodied person it shouldn't take more than 5 minutes. Bonus points: you know the way back to your home. > because problem-solving is work You know who made someone else's problem a problem=solving problem? You. The delivery guy wil…