Something similar happened to me between Essen and Dortmund while trying to get to the airport. The train stoped around 50 minutes between stations without a chance of getting off the train. I lost my flight as a result.
I have also been left in remote villages when the last train of the day broke for some reason at 12:30 am. All travellers and myself had to look for Ubers, which the government also tries to suppress.
I agree with some comenters that German companies seem to prefer to stuck with Bureaucracy other than finding what could be confortable or even human solutions.
Chat offers a far better experience than using Google—no more searching through spam-filled results, clicking between sponsored links, accepting endless cookie banners, and trying to read a tiny bit of useful content buried among ads and clutter.
It has the potential to bridge the gap between pure conversation and the functionality of a full website.
I agree. But Google has gone in that direction long ago: ads are now harder to distinguish from genuine search results. In many cases, the organic results are buried so deep that they don’t even appear in the first visible section of the page anymore.
Google could also have allowed invisible pay-for-placement without marking it as an ad. Presumably they didn't do that because undermining the perceived trustworthiness of their search results would have been a net loss. I wonder if chat will go in that same direction or not.
Pretty sure it's illegal to present advertisement and not label it as such in some form.
But as with everything, as new technologies emerge, you can devise legal loopholes that don't totally apply to you and probably need regulation before it's decided that "yeah, actually, that does apply to me".
Why does it not make sense? If I was involved in a robbery at age 18, as a dumb kid, should I still be called "robber xyz" for the rest of my life? Especially if I turned my life around?
I agree that we should be forgiving, give people second chances etc, but that doesn't change the meaning of words. "Defamation" is when you damage someone's reputation by saying things about them that aren't true. If you were convicted of a crime long ago and someone draws attention to that fact, they're not defaming you. The truth isn't defamation, by definition.
Words can have multiple similar definitions with small variations. If I look up "defamation" I get:
> Defamation is a legal term that refers to any statement made by a person, whether verbal or printed, that causes harm to another person’s reputation or character. --- https://legaldictionary.net/defamation/
> Defamation is a communication that injures a third party's reputation and causes a legally redressable injury. The precise legal definition of defamation varies from country to country. It is not necessarily restricted to making assertions that are falsifiable, and can extend to concepts that are more abstract than reputation – like dignity and honour. --- https://en.wikipedia.org/wiki/Defamation
Truth (in English law) is merely a defence to an accusation of libel or slander, and it is not an absolute defence. If you say or print true things about a person, that lowers their reputation in the eyes of an ordinary person, and you are motivated by malice, then you have still committed the crime of defamation.
English libel law is an evolution of the former English law known as scandalum magnatum -- "scandalizing the mighty". Basically, if you say bad things about powerful people, those powerful people will crush you with the law.
As an example, Robert Maxwell embezzled millions from his company's pension fund, and also used that money to sue anyone who slighted him - including anyone who said he was embezzling from his company's pension fund. He was never prosecuted for embezzling millions from his company's pension fund.
Calling someone a robber means they are currently a robber. It can be inaccurate and untrue in the same way that calling someone a bartender would be inaccurate and untrue if they are a lawyer who hasn't tended a bar in 20 years.
I don't like the idea of prosecuting people for this, but I don't think it's illogical.
Honestly I don't know, I think it would depend on how long ago the crime was and if there's a credible reason to believe they won't do it again. I do think there's a meaningful difference between "they murdered someone" and "they're a murderer", and in general I do prefer to describe people's actions as opposed to using "they're a ___" labels.
The problem is that getting those things right is 4x more difficult in a SPA app than a legacy, server rendered, app.
- No native back and forward button implementation. Now you must listen to an API and emulate the legacy behaviour.
- The concept of links, its also emulated via onClick events. This means that anything can be a link, so in many cases rows become links and their content is not really selectable as text. Legacy HTML has clear limitations for this not to happen.
- Same with buttons. There are no native buttons anymore. Anything can be a button, including any DIV with an event listener. Good luck tabbing through every DIV to get you to a button, that's also another difficult implementation.
Again, none of this is down to SPA frameworks (other than back/forward history APIs, lot of people break this unfortunately, though I've never understood how they manage to as I've never had this problem on projects I worked on). What often happens also is that people embed a bunch of iframes, and history within iframes can act very weirdly.
Links in Vue Router at least are just regular <a> tags. Yes the framework handles navigation when clicking these, but nothing prevents anyone from wrapping anything they want in an <a> tag even with no JS. You could make an entire table be clickable as a link if you wanted to, framework or not. "Legacy" HTML will render these just fine and browsers will make it a regular link, even though HTML validators will fail it.
Literally the first element anyone makes in frameworks will be a generic Button element that is simply a <button> with some styling. People abuse divs as buttons with or without frameworks because again, nothing prevents you from making any arbitrary element in your DOM have an onclick handler and act as a button. Tabbing through can even work with the correct ARIA attributes, and can even be broken on regular plain <button>s if abused hard enough.
I would seriously suggest people try out Vue or especially Svelte, they're about as simple as you can possibly get (especially Svelte 4) while giving you a lot of power and flexibility. I've worked with plenty of server-rendered apps in the past, and trust me, people would butcher things just as badly and easily there.
I wholehartly disagree - all of the mentioned problems are problems created by the developer. All these things work with the common SPA frameworks - developer just tend to forget what an anchor or a button is and use a span or div for it.
Having the proper tool and using the tool properly are two different things - and the web is a place where people forgot to do things the proper way.
I love Rails, its been my to-go framework for reference. But I could never get as confortable with Ruby as writing JS or PHP. I do not know the reason.
If debugging is hard to you in Ruby because of monkey patching, it's an issue of not knowing the debugging tools. Attach pry or Ruby debug, and show the source location of a method, or log them. This isn't surprising - debugging Ruby is different to debugging most static languages, and more tutorials on how to do this well would be nice...
Also the use of monkey patching in Ruby peaked something like a decade and half ago. Outside of Rails, it's generally frowned on and introducing new methods is usually addressed by opting in by including modules these days.
Can you give an example of where monkey patching made debugging hard? I have a decade of Ruby experience and can't think of a single time it was an issue
This is one of those things that sounds like it'd be a problem but it really isn't
One of the many reasons of why frameworks like React are used so extensively is because they provide a bridge for the lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs.
Now what we see around the web as "controls" are just a group of <div>s with hidden JS behaviour, lacking both accessibility and deeper integration. With hundreds, if not thousands, of implementations for things like calendar pickers, search selectors, etc.
> lack of modern HTML implementation of basic control elements, like multi-selectors, search selectors, calendar pickers, and autofill inputs
It was about the spot where CSS popped up then everyone decided native controls was not useful. Every framework since then has basically reinvented them. They had to as the browsers and standards didnt help. Plus the fact that for awhile the junk would just not render correctly at all or weird between the different browsers.
> We need better native controls for the web.
The reality is people want all of these controls with a nice simple way to skin them. But the browsers made it very 'interesting' to do. There is no real reason at this point other than 'i just want to' for these controls being recreated yet again (and they will be with the next framework).
Totally. It is like the browser venders just kinda stopped iterating on them. When the reality is people just want the controls and the ability to skin them. Also with all of the events that all of the newer controls have.
Actually, compare everything they have to native elements. If the project can afford it (in terms of bundle size, etc — it's fine for intranet), I don't even bother with native controls anymore.
I'm on a sub-optimal connection, so the Ant Design one took me about a minute to be responsive, while the native one worked in seconds.
I also am confused by this Ant demo page. Is every single date item supposed to be selected in a different element?
In this comparison, I vastly preferred the native date picker over the Ant ones. But I am probably misunderstanding the demo page. Or maybe it's just giving you "too many" options? I just need to pick a date and this seems like overkill, at best.
I really like my native pickers and UI compared to those examples. I can start with the fact that those are not usable on iOS 18, and they took almost a minute to load.
This goes back to the jQuery and MooTools days, back when Microsoft was holding back web standards. Then when the web started pushing forwards again, some developers didn't want to learn new things and went out of their way to teach new developers not to learn the standards.
That's how we ended up with developers who reach for frameworks instead of just using a simple html element or attribute.
Now we have an entire industry of bootstapping con-artists who are just teaching people to just search for a react thing that does what you want and if that doesn't work use an LLM
They're not actually being taught how to program.
---
Now it's true that some commonly requested features (e.g. date pickers) don't have what everyone needs. But most people also don't realise that a date picker is one of those few specific features where everyone wants it to do things differently. Even when you think you want what everyone else wants, you'll eventually hit a corner case where you realise you need one extra thing changed. There's no way to get everything right in a standard so you'll need to create your own or reach for a 3rd-party implementation.
But just because you may want to use non-standard code for a date picker, doesn't mean you shouldn't learn about (and use) things like <dialog>, <details>, <hgroup>, <menu>, <slot>, etc...
What we'll probably end up with in a few years is the generic standard datepicker, but it'll become extensible, so you can add/remove alter that one extra thing you need. (kind of like <select>'s new ::picker psuedoelement)
I just rebuilt a custom Select/Combobox component in react for a Business, and I promise you I had no intention of differentiating. I wish I could have used more native browser behaviour.
Businesses differentiate to create revenue. Standardization and commoditization are important strategies as well. “Commoditize your complementary goods” and all that.
A web design shop may want to visually differentiate and therefore not use openui. But a restaurant that just wants to have a simple website probably doesn’t want either 1) a crappy looking website, or 2) to invest heavily in web design
Businesses differentiate when there's a good reason or no common solution. Nobody creates a new calendar picker or database or... "just because" but because there's no easy alternative. Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.
> Yeah, there will be exceptions, but if you're paid to create something, your manager will usually not be impressed by "but the wheel I reinvented is slightly different!", unless you justify it with a specific requirement.
Depends on the org. Some places incentivize wheel reinvention by having rubrics that basically resolve to “if you want to level up, you need ‘org wide impact’”, which translates into “all the existing databases suck (for …reasons…) so I need to write our own”.
The company might not actually want this behavior but if the people in charge don’t see how important it is to make sure incentives align with expected behavior, the wrong behavior will always happen. So while it makes absolutely no sense to write your own database and Calendar Picker Platform (Now With a Fully Staffed Team!), unless the rubric incentivizes the right thing that is all people are gonna do.
I get where you're coming from and we all know Google as the bad example here, but looking at it industry-wide, I'm not sure it holds. Like in a lot of cases, "you're not Google" applies and the similar incentives will not be there for a large majority of companies. Software is a cost centre for almost everyone.
Most business just adopt something existing, we saw this with Bootstrap, then with Material UI. Now things are a bit more diverse but still.
I feel like the pressure to differentiate is coming from internal design departments rather than business itself in 90% of cases. It's just people generating extra work for other people.
No one prevents businesses from using their custom implementations if they so wish. Just as nothing prevents them from doing so on literally every platform from desktop OSes to mobile OSes
This leads newer devs to "learn React" instead of learning web dev, so even after the web catches up, they still reach for React components when a simple html element would do.
The problem is, you're coming from paper for these PDFs, and this is the step where you add that data.
While the world became much more digitized (for example, for any sale, I get a PDF and an XML version of my receipt, which is great), but not everything is coming from computers and made for humans.
We have hand written notes, printed documents, etc., and OCR has to solve this. On the other hand, desktop OCR applications like Prizmo and latest versions of macOS already have much better output quality when compared to these models. Also there are specialized free applications to extract tables from PDF files (PDF files are bunch of fonts and pixels, they have no information about layout, tables, etc.).
We have these tools, and they work well. Even there's venerable Tessaract, built to OCR scanned papers and have neural network layer for years. Yet, we still try to throw LLMs to everyhting and we cheer like 5 year olds when it does 20% of these systems, and act like this technology doesn't exist, for two decades.
The funny thing is that sometimes we need to machine-read documents produced by humans on machines, but the actual source is almost always machine-readable data.
> The funny thing is that sometimes we need to machine-read documents produced by humans on machines, but the actual source is almost always machine-readable data.
Yes, but it's not possible to connect all systems' backends with each other without some big ramifications, so here we are. :)
A lot of times you are OCRing documents from people who do not care about how easy it is for the reader to extract data. A common example is regulatory filings - the goal is to comply with the law, not help people read your data. Or perhaps it's from a source that sells the data or has copyright and doesn't want to make it easy for other people to use in ways besides their intention. etc.
I have also been left in remote villages when the last train of the day broke for some reason at 12:30 am. All travellers and myself had to look for Ubers, which the government also tries to suppress.
I agree with some comenters that German companies seem to prefer to stuck with Bureaucracy other than finding what could be confortable or even human solutions.
reply