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’ve always relied heavily on Maps review but for me trust was broken few weeks ago. I went in a restaurant with thousands of reviews averaging 4.6. Food was good but not amazing, service was super kind and proactive but nothing special to deserve a 4.6 in Paris. We understood the trick at the end of the meal. Waiters kindly ask to scan a QR to make a review. You end up on a third-party landing page and if you select 4 or 5 stars you were redirected to Maps, otherwise they simply take your random-internet stars and buried them forever in this landing page. Clever.
So a few months ago, after a buggy change to a stock update sent to the channel manager (external system for updating pricing and availability of hotel rooms) we lost 21.000 EUR in just 2 hours of the bug being deployed. We exported low season rates (today’s rates) for the higher seasons.
Luckily a human saw the error, when he saw a big flow of reservation coming in at anomalous peace.
From there on, I’m too scared to make changes to the 20-line function that produces the updates to be sent.
We had not a chance to cancel the reservations made through the channels (websites were you book the reservations).
> From there on, I’m too scared to make changes to the 20-line function that produces the updates to be sent.
Given enough regression testing coverage, any load-bearing function can be changed.
This sounds to me like your project had insufficient or non-existent software quality practices to let this slip through. Hopefully your team has done a post-mortem analysis to make this a learning experience.
You need much better testing. And probably that 20 line function needs better documentation and may even benefit from being further broken out. I hope that it at least is a function that is 'pure', in other words that it does not reference any globals.
Part of fossils's reasoning is that they *DO* understand git's logic but they disagree with it.
See most of the points labelled with links to 2.5
plus the comment about showing what you actually did I no rewriting and lying about history, tyhe errors you made are often just as important as the correct way of doing things.
I don’t think that’s true. I think the hive mind is that it’s good, or many “haha sucks but I use it all the time.”
I work sort of near “data science” and there’s lots of no code/low code people wanting to do data science (or at least bill for it). And I’d say the hive mind in non-coders is that fit is bad. But I think that’s more related to all coding is bad and git is like step 1 to coding so it’s the first hard step they hit.
In any reasonable law, you would prove that your procedures require consent before you start sending the emails. If you have to prove things about a specific user, you are already on unreasonable land.
(But then, I have no idea what places have reasonable rules. I have never seen any with this specific failure for email, but IANAL and I haven't looked much.)
They almost certainly keep a copy of that specific version of the UA. They also very likely keep a log of you agreeing to it. And probably none of those would matter in a court (what you actually say on your site and how reasonable the document is certainly matter a lot more).
Anyway, UA acceptance does not require and does not imply in opt-in to your marketing emails.
Watch out, if you get a HTTP GET request on the approve link, it could be the mail provider scanning for malware, not the user. You may need triple opt in :-)
The CLI interface of git is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). This allows for the user to draw an accurate user-model in his understanding of the system.
Adding an “undo” command would be convenient, but it would hide the underlying potential away. This is something that should belong to a GUI client, and I still would want to know what is it actually doing.
Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API.
Not even the multiple GUIs built on top of Git, adventure themselves into hiding or dumbing down the abstractions that allow you to do quite complex things with the code and its history.
> Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API.
But that’s simply not true. Git is just inconsistent in how it does things.
Sometimes it wants you to deal with its inner state (typically the undo where you just need to move HEAD to a previous commit which might be only visible in the reflog). Sometimes it introduces complex concepts which would be simpler if they were just exposed for what they are (stashes are just temporary commits).
Honestly Git is a mess. It works but the UX has always been awful.
> The CLI interface of git is very good at enforcing you to be aware of the underlying model (local state and the repo’s history).
Awareness of state is sometimes important, sometimes you just need awareness of operations. And awareness of git's data structure does not necessarily map 1:1 with understanding the state of the code base. Not saying you’re wrong, just saying that this may or may not be a good thing. I’m personally leaning towards this could be improved.
Really good advanced tools should work well for common use cases, so you can master it incrementally. Git is extremely frictionous for certain simple tasks, which is evident if you look at stack overflow. If a user wants to do something very simple in human terms (like fix a typo), and you get a lecture about merkle trees and reflogs, then I think there is room for improvement.
The truly important question though, is whether the UI can be improved enough without changing the data model (ie can replace the UI without replacing your repos).
Trello boards export to JSON, would you consider it open? OneNote notebooks are also an open and well-documented specification, as well as local first and backed by a very reliable company, which makes them just as open as Obsidian by those standards.
The Canvas JSON is not an export format, it is the file that the app actually reads and edits. Being explicitly MIT licensed also gives permission to other people/companies to build their own tools using that format.
OneNote and this canvas format might be equally open and interoperable, but it's a hard claim to justify that onenote notebooks are as open as a folder of mostly standard markdown (the two exceptions being wikilinks and embeds)
I peeked at the onenote format standard [1] and the obsidian canvas standard. The difference is hilarious. The onenote standard is painfully complex, provided as a .pdf, and binary to boot. Compare to an example obsidian canvas - this is obvious, text-based (I could read it with notepad++) and easy to understand just by reading it:
{
"nodes":[
{"id":"6c711bf8c24c4f5b","x":-226,"y":-62,"width":400,"height":400,"type":"file","file":"testin/2022-10-14.md"},
{"id":"4dd7d04cdd0b379c","x":-530,"y":-209,"width":250,"height":60,"type":"text","text":"this is a note"}
],
"edges":[
{"id":"0c589a4d6bbb06aa","fromNode":"4dd7d04cdd0b379c","fromSide":"bottom","toNode":"6c711bf8c24c4f5b","toSide":"left"},
{"id":"eda9f3edb3ec232a","fromNode":"6c711bf8c24c4f5b","fromSide":"top","toNode":"4dd7d04cdd0b379c","toSide":"right"},
{"id":"abf404722ba48c3b","fromNode":"4dd7d04cdd0b379c","fromSide":"top","toNode":"6c711bf8c24c4f5b","toSide":"right"}
]
}
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.
We need better native controls for the web.