The segmented type site that lets you see a bunch of different options reminded me of Posy's YouTube video where he investigates a bunch of weird options for these: https://youtu.be/RTB5XhjbgZA?si=y7npP6KfXlOGNoHZ
One person's front-running is another's reference implementation.
Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C.
Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers?
Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telling everyone it's supposed to be pronounced "exalt"). But it was such a disaster to actually write or read and no real debugging was possible, I had to use a LOT of conditional bgcolor=red to figure anything out. It didn't take very long to come to the conclusion that XPath was the only useful part.
If I need the markup of a page to not contain any structural errors, I often use XHTML for testing at least because, though it's a little more verbose, if there's a nesting error, for example, the browser will flat out refuse to render it and show some sort of stacktrace error page instead. So it's quite a good built-in "tool" for checking that your markup is clean.
With HTML, everything goes and the browser will happily render broken markup, which is probably the correct default for the web as a whole. After all, you surely don't want a page like Wikipedia to show an error message to its users because a developer forgot to close a tag somewhere.
Sure, if by SaaS you mean hooking together software that is essentially websites. Major industrial software that costs thousands per seat like Ansys or Dassault are not getting replaced by something that "AI" can cobble together.
The parts of SAP that's composable workflow stuff? Doubt it, because the types of ABAP workflows in SAP that might be "malleable" are the sort of stuff that often legally requires correctness and reproducibility - kinda the exact opposite of a good LLM use-case.
And as much as I'd like to actually own my software, SaaS is preferable for major corporations for lots of legal and accounting reasons like easier revenue recognition. They're going to keep pushing it because it makes all the parts of being a software company that don't include writing the actual software easier.
Oddly, my bank has no problem with non-US IPs, but my City's municipal payments site doesn't. I always think it's broken for a moment before realizing I have my VPN turned on.
I think the only thing here that I don't agree with is that internal users are just users. Yes, they may be more technical - or likely other programmers, but they're busy too. Often they're building their own thing and don't have the time or ability to deal with your API churning.
If at all possible, take your time and dog-food your API before opening it up to others. Once it's opened, you're stuck and need to respect the "never break userspace" contract.
I think versioning still helps solve this problem.
There’s a lot of things you can do with internal users to prevent causing a burden though - often the most helpful one is just collaborating on the spec and making the working copy available to stakeholders. Even if it’s a living document, letting them have a frame of reference can be very helpful (as long as your office politics prevent them from causing issues for you over parts in progress they do not like.)
With internal users, you likely have instrumentation that allows you to contact and have those users migrate. You can actually sunset api versions, making API versioning an attractive solution. I've both participated in API versioning and observed it employed in organizations that don't use it by default as a matter of utility.
A big difference is you can tell internal users to update or else. It’s not free and should be reserved for good business reasons, but it can happen on a shorter time frame as you have the internal organisation to enforce it.
It’s not really an option in the same way with end users or customers, as they aren’t part of your organisation, by definition.
This is more like people arguing over "proper" English, the point of language is to communicate ideas. I work for a German company and my German is not great but if I can make myself understood, that's all that's needed. Likewise, the point of an API is to allow programs, systems, and people to interoperate. If it accomplishes that goal, it's fine and not worth fighting over.
If my API is supposed to rely on content-type, how many different representations do I need? JSON is a given anymore, and maybe XML, but why not plain text, why not PDF? My job isn't an academic paper, good enough to get the job done is going to have to be good enough.
> This is more like people arguing over "proper" English, the point of language is to communicate ideas.
ur s0 rait, eye d0nt nnno wy ne1 b0dderz tu b3 "proppr"!!!!1!!
</sarcasm>
You are correct that communication is the point. Words do communicate a message. So too does disrespect for propriety: it communicates the message that the person who is ignorant or disrespectful of proper language is either uneducated or immature, and that in turn implies that such a person’s statements and opinions should be discounted if not ignored entirely.
Words and terms mean things. The term ‘REST’ was coined to mean something. I contend that the thing ‘REST’ originally denoted is a valuable thing to discuss, and a valuable thing to employ (I could be wrong, but how easy will it be for us to debate that if we can’t even agree on a term for the thing?).
It’s similar to the ironic use of the word ‘literally.’ The word has a useful meaning, there is already the word ‘figuratively’ which can be used to mean ‘not literally’ and a good replacement for the proper meaning of ‘literally’ doesn’t spring to mind: misusing it just decreases clarity and hinders communication.
> If my API is supposed to rely on content-type, how many different representations do I need? JSON is a given anymore, and maybe XML, but why not plain text, why not PDF?
Whether something is JSON or XML is independent of the representation — they are serialisations (or encodings) of a representation. E.g. {"type": "foo","id":1}, <foo id="1"/>, <foo><id>1</id></foo> and (foo (id 1)) all encode the same representation.
>misusing it just decreases clarity and hinders communication
There is no such thing as "misusing language". Language changes. It always does.
Maybe you grew up in an area of the world where it's really consistent everywhere, but in my experience I'm going to have a harder time understanding people even two to three villages away.
Because language always changes.
Words mean a particular thing at a point in time and space. At another one, they might mean something completely different. And that's fine.
You can like it or dislike it, that's up to you. However, I'd say every little bit of negative thoughts in that area only serve to make yourself miserable, since humanity and language at large just aren't consistent.
And that's ok. Be it REST, literally or even a normal word such as 'nice', which used to mean something like 'foolish'.
Again, language is inconsistent by default and meanings never stay the same for long - the more a terminus technicus gets adapted by the wider population, the more its meaning gets widened and/or changed.
One solution for this is to just say "REST in its original meaning" when referring to what is now the exception instead of the norm.
Pretty much everyone speaks English too, it's the official language of the company. Though we all try to be respectful; if I can't understand them then they tell me again in English. I try to respond as much as possible in German and switch to English if needed - there's also heavy use of deepl on my side which seems to be a lot more idiomatic than Google, MS, or Apple translate.
I'm brand new to MCP and agents but was able to read the extra docs to get VSCode set up with Mastra. Then what? I only figured out the "start Mastra Course" because of their tweet where they show someone typing that into co-pilot.
There really needs to be more hand holding to get someone to the point where the course actually starts. From there I've been able to follow along alright, but it was a real battle to get to this point.
I've climbed this mountain of madness trying to calculate working hours elapsed before. It was easily the project I messed up on more than any other in my career. I'm glad I did it, I'm glad I learned a lot, and I hope to never have to work on something like that again. I'd rather spend the rest of my career untangling double & triple encoded character set problems.
The biggest problem is that if even programmers - who know this is hard, and has a lot of corner cases - mess it up, expect your requirements to be very very wrong with regards to special cases.
Come up with a list of example cases and ask what the expected output should be; but not just the corner cases, the normal examples too. There's a good chance even basic requirements regarding timezone conversions have not been thought about, or are wrong. Like the earlier post said, humans really only think in local time and for short periods in the future or past. Any conversion whatsoever can end up being pretty unintuitive (even if it's right).
If it has to do with scheduling, BE EXPLICIT. Show both (or more) local times and dates and let the user pick a time for either location. Maps with pins can be a very helpful UI affordance
I don't disagree with the main points, but Alpha wasn't just focused on the small workstation market. Alpha for lots of us in the IT departments of SMBs was the go-to when your Exchange server couldn't handle the load anymore. DEC and by extension Alpha died as soon as Ken Olson was pushed out.
Safari vs. iOS Safari is a distinction that needs to be made and people need to keep in mind. Apple's a lot more likely to allow stuff in desktop that it won't even consider for iOS. I mean your own link for media source has it being fully supported since 2014 in desktop Safari.
