Hacker News new | past | comments | ask | show | jobs | submit | pbreit's comments login

The biggest, easiest to implement underutilization is:

"Using specific type attribute values, such as "email", "number", or "url""

These can significantly improve user experience on mobile by triggering the optimal keyboard.


I avoid the use of `type=number` and use `type=text inputmode=numeric` instead. It doesn't come with these arrow buttons which most users don't need anyway for entering numbers. Also the keyboard is better on iOS.

But what's crazy is both of those still don't disallow non-numeric input unless you use JS to reject keystrokes and intercept paste. HTML form validation is so incomplete and limited, every time I look at it I want to scream cause wtf there's so many just totally obvious things we need that don't exist by default and we need to reinvent the wheel. Native date and time inputs are still garbage so every UI framework has to build their own solution.

I used to write those fancy textboxes that reformatted your input as a phone number as you type, and intercept paste, and all that.

But then it turns out that you really do want a free-form text input. Let people paste text in, edit their text freely, then let it validate afterwards. When it validates, then reformat it.

For example, text boxes with length limits. These are awful. It messes with your ability to paste something in, then edit it down to the correct length.


Very much this. Live re-structuring runs afoul of tons of things you can't predict.

You can validate roughly anywhere, but at the absolute earliest, only re-format on blur. Never earlier. You have no idea what the user might be doing in the meantime.

And even then, I'd strongly suggest not changing what they entered. Change it to a display-only element with nice formatting if you want, but don't screw with their input.


Nah. Users are too stupid to fix their own inputs in many cases. Seen inputs with zero-width spaces that are invisible which fail validation. User doesn't understand why, complains. Enforcing a character set for certain kinds of inputs is a very good thing.

In 26 years of web dev, mostly as a frontend person, I've only seen zero width spaces in three situations

- pasting from Word

- QA testers being through

- devs pranking each other

The third one is by far the most common. Word is much better these days and I've not seen that happen in a long time. I wish I saw QA test this stuff more often. The idea that it's common enough that you'd break your UX to handle it baffling to me.


I see weird spaces every time I copy-paste from some pdf pretty much, especially if it's a digitised or 10+ years one. Hardly an irrelevant use case

I'll be one of those guys. I see the invisible whitespace from pasting ALL the time. I've literally dealt with user complaints caused by it three times in the last two weeks! (Usually customer issues don't make it to me unless our support team can't figure it out or suspects a bug)

To be fair, it's not usually that frequent. Just a funny coincidence that I've JUST dealt with it more recently.


Add to that pasting from MS Teams.

"Break your UX" is a vast exaggeration. I'm not talking about phone number fields, to be clear. I'm talking about like numeric amounts, with maybe a negative or decimal point. It's literally just [0-9\.-] but that still requires JS to limit inputs to that.

What's wrong with

<input type="text" pattern="[0-9.-]*">

though?


It doesn't prevent the bad input, it only validates it on submission. Therefore it's on the user to fix it, and if it's from a zero-width space, it's literally invisible. Non-technical users will have no idea what to look for to fix it (i.e. use your arrow keys cursor to see at which character the arrow key doesn't shift visually, and there's the ZWSP). It happens way too often.

Try copying any string from any e-mail.

The problem here is that sometimes users and copy pasting from another document and that comes in arbitrary formatting, not the one enforced by the input element.

For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc

It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.


> For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc > > It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.

How is that more pleasant than a textbox which automatically removes the extra characters?


What if I copy something but accidentally get another couple words one of which is a number. For example copying from a chat app and get the date with the message. Then my "Sep 24th 416-555-1234" input which, would have been very easy to fix, becomes 244-165-5512 34. It will take me a few seconds to realize what has happened, identify where the intended phone number starts and remove the accidentally pasted digits.

The nice thing about the native input is that it is very simple, predictable and flexible. It may be easier to make a better UX on the happy cases but it is very difficult to not add some suboptimal and confusing UX on the less happy cases. Often times it is best just to keep it simple so that the user can easily complete their task rather than adding some "magic" which may backfire and confuse users.

It is surprisingly often that I need to open a text-editor or clipboard-editor to format values before pasting them into apps or websites because they have broken an input field by trying to be magic and failing to consider anything but the happy cases and maybe one or two bad paths.


I was talking about numerical amount fields, not phone numbers or dates or credit card numbers. Those are different things entirely.

FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere.


The exact same problem applies. If I copy "Sep 24 $2412.45" out of a message and you quickly "clean" it to 242 412.45 I may not notice and even if I do it will take a second for me to realize what happened and clean up the value to be the intended amount. If I see the original text in the field it is much more obvious what happened and quicker for me to understand what I need to do to fix it.

> FWIW if you're copying text on Android, you can tap the clipboard popup to edit the clipboard item before pasting it elsewhere.

I never noticed that after 13 years of Android. I checked that now and I could not find a way to do it. Samsung's keyboard has a way to look at the clipboard but I could not edit them. Swiftkey does not. Maybe Google's keyboard? It's not on my phone. I looked at a couple of videos but they don't look anywhere like my phone. Not a feature to invest much time on it. If I have to edit the clipboard and I can't do it where I want to paste it, I open an editor and paste it there.


I'm using stock Android, Pixel 8 Pro. Highlight text then tap "Copy". See a toast in the bottom left. Tap on it (not the X) and a little text editor applet opens up. Here you can edit the text and save it, updating the value in the clipboard. Then using Gboard, it has clipboard history so you can see and paste the specific recent item from the past hour that you want. (Unfortunately it can't be edited after initially copying although you can long press them in the Gboard menu to pin for longer or delete them).

Because you don't know what your user wants to do and eventually you'll annoy someone

In most cases when you are accepting a numeric value it is best to just strip anything that isn't 0-9 then run validation on just the digits. There are some exceptions like phone numbers which may need + prefixes and similar but you can adjust these rules.

What I have found to work well is when the user unfocuses the input field or on submit strip everything but expected values then validate. If you want you can format the value at this time too (and the formatting won't interfere with text input).

If you want to get really fancy you can strip and format as they type and be careful to keep the formatting "virtual" such that the user is only editing the raw digits but this is very tricky to get right on all platforms and support all expected native editing UX. But even in the best cases this can have bad edge cases. For example the user pastes some text but it happens to have multiple numbers in it, if you eagerly strip and format what is left for the user will be these two numbers mushed together with misplaced separators or similar. If you let them paste, remove the unintended stuff, then format on blur this just works and is understandable.


Why blame it on the user, instead of fixing it?

You could remove the zero-width spaces in validation (for eg a phone number).


Or, you know, prevent invalid characters from the get-go. Same thing as validation, but done up-front. (But as I said elsewhere, I'm not talking about phone numbers, I'm talking about amounts)

I would like to allow people to copy-and-paste text in, and then edit it. That could be a longer text that has the amount in it (but also some unrelated numbers).

Because this often makes the input feel broken to the user.

Instead of asserting that "users are too stupid" as you have done earlier, perhaps programmers should be less stupid and write more permissive parsers.

Accessible design is actually pretty hard, and most designers and programmers get this wrong. If you want some good design advice, you can start here: https://adamsilver.io/blog/the-problem-with-live-validation-...


I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users.

To clarify, we get _asked_ by our users to implement fields that limit input to help them avoid mistakes. Our QA and UX teams agree. This isn't a unilateral engineering decision.


Yes, you want to provide guidance, but without getting in the way.

That's why I was suggesting letting the user paste in these 'wrong' characters, but offering help in removing them.

Of course, that's a trade-off. And it's more annoying to design and implement than just forbidding those characters from entering the input field in the first place.


I’ve read some very user hostile things in my career, but this one is particularly acerbic. It’s a bad look.

If I ever grew to hate users this much, I would find a new career. You should consider that.


I'm not being user hostile. I'm being cognizant that the skill levels of users is extremely wide, and to best serve everyone from a UX standpoint, it's best to limit the characters accepted in the input. It protects the user, helps them avoid mistakes.

From reading your comments, you're extremely user hostile and I hope to not come across anything you work on because they are the very definition of antipatterns

It's a decimal number field. There's no reason to have any other characters than [0-9\.-]* You're overreacting. You're attacking me for no reason.

Except if one copied it and it has a space in the beginning and your amazing script won't let one paste it.

[flagged]


Not everyone who disagrees with you is lying. Accusing people is a bad look here on HN. "Assume good faith" is the standard.

You can say "You're wrong". "You're lying", though, is almost never appropriate, and is, in itself, quite hostile.


Again “users are too stupid”. That’s remarkably hostile to users and doesn’t belong.

Please read my other comments. I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users.

Fine. But "you're lying" is also hostile, and also doesn't belong.

(I see that you edited that bit out of your post, so thanks for listening...)


> what's crazy is both of those still don't disallow non-numeric input

Which is really nice for copy pasting. For example, I have a number with spaces in it, and when I paste I get nothing or only until the first space because someone decided I'm not allowed to have non-numericals in the input field at anytime.


You shouldn't reject keystrokes as that can lead to silent errors when the user thinks they entered something that was not allowed.

And final validation needs to happen on the server side anyway - anything before that is just a usability helper.


exactly. Silently refusing input is an anti-pattern

> these arrow buttons

A spinner control, that is.

Spinners always puzzled me, to be honest. There is obviously a need for a compact numeric input control that both displays the exact value and allows rough changes using the mouse. Witness knobs in DAWs—which don’t actually work the way you’d expect from their appearance, you’re supposed to grab and then drag in a linear fashion, possibly ending outside the knob’s screen bounds. Or consider the weird input thing Darktable uses—which at least doesn’t mislead you with false skeuomorphism, but takes a bit to figure out. Then there are the inputs used for color grading in DaVinci Resolve. And so on. And all of them are nonobvious. Spinners are obvious, but they are also needlessly fiddly to use with the mouse, and neither do they provide the at-a-glance readability of knobs et al.

I feel like humanity just hasn’t solved compact numeric inputs yet.


> Spinners are obvious, but they are also needlessly fiddly to use with the mouse

I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused.

An even better improvement would be having the `<input type='range'>` element actually display the value as it changed, and allow the user to set that value directly (say, by typing it in).

Right now, range is useless because the user cannot tell what is selected. The developer has to add in extra JS magic to let the user set range to an exact value, or to show the user the value they have chosen.

If `range` is improved in this way, then spinners are redundant and can be ignored.


> I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused.

Firefox did that for number inputs for a long time, until very recently. They switched it off in Firefox 130 because people kept inadvertently changing values in forms while scrolling through them [0]. Personally, I've set the about:config option to reenable it since I've found it useful in certain interfaces, though I can't imagine it's much longer for this world.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1741469


Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling.

I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.


That is how it worked, but people still found it problematic. E.g., from one of the comments on the issue:

> In step (3) here, if you do several mousewheel-spins while also subtly moving the mouse (just from placing your hand on it), it's quite easy/possible for the first spin to inadvertently change the value that you just entered (since step 1 had left the cursor hovering the input field, so that's where it starts), and then for the subsequent mousewheel-spins to successfully scroll the page. This can mean you change the number you just entered without noticing (and also without it being "in the middle of an existing scroll action", hence my note that this suggested mitigation wouldn't necessarily help).

The cause being that people don't look at where their cursor is before they start scrolling, and don't look at the value since they've finished entering it.


That's almost correct. I generally agree with hover == focus as a Window Manager level thing, but for document inputs within an application I still prefer required user interaction to set the focus location. E.G. a click, a tab, just move the line forward.

The correct context model is to not select an element for scrolling until it has been made the active element, and that UI element SHOULD have some sort of embellishment to make it obvious that's the focus.


Thanks for the tip wasn't aware of that.

I rarely want those arrow buttons for numbers


I think type=number is a mistake as it is too generic. It is difficult to get proper validation, UI and error messages.

It should be split into:

type=integer so the keyboard does not allow anything besides 0-9

type=decimal so the keyboard also allows decimal dot/comma and a fixed number of decimals!

type=float which allows for scientific notation, e.g. 1.2e42


And yet in both cases the browser insanely casts the data type to string when reading the value.

It’s amazing how many login forms are labeled “email” and then don’t have the correct type set.

From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

> Browsers automatically provide validation to ensure that only text that matches the standard format for Internet email addresses is entered into the input box. Browsers use an algorithm equivalent to the following regular expression:

> /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

Which doesn't even allow all valid email addresses :|

No support for quoted local parts. No support for punycode domains. Disappointing.

Use <input type="text" inputmode="email"> instead to just get the email-optimized keyboard on phones without the misguided validation.


It's not the fact that software engineering is broken saddens me as much as the extent.

Email is older than absolute majority of active developers and yet, it seems, simple knowledge like "what is email address" remains such an arcane knowledge that you are being looked at weird when present something a tiny little bit more correct than the status quo.

Where else can we assume that the common knowledge is flat out wrong?


>"what is email address"

Anything you can send an email to that is received, as far as I am concerned. I have my own domain, so why ahould I be forced to add an arbitrarily long string to it to be able to receive the mail? Or exclude <site>@myDomain.com from being input on <site>?

Or the worst of the worst: Disallow all but a few domains for emails.

At this point, not validating it cient side at all is IMO the correct approach, and instead send a verification email.


> Anything you can send an email to that is received, as far as I am concerned.

100% this.

The only acceptable hard validation is to check whether there is an @ between some characters. something like `.@.` in regex.

It makes sense to do sanity checking (soft validation) on client side. There is 99.9% chance that `muppet@gmial.com` is wrong, outright rejecting that is wrong, though.


> No support for punycode domains

Really? I tested with a punycode domain on regex101 and it worked fine, do you mean that it only works with ones already converted to punycode?


This is particularly annoying on mobile since on-screen keyboards won't adjust to an email input layout and autocorrect will screw up basically any email address as soon as a "." character triggers autocomplete to commit it's guess.

And password managers will not fill in the credentials correctly.

Get a better password manager? I use Bitwarden and it has never failed to fill out the login forms for me.

Bitwarden has failed me on some sites.

I think that in some cases this could be because the inputs accept usernames as well as emails. But not in all cases, which is annoying!

I found this very extended with "date" input. It seems that every single frontend library has its own date widgets, and lots of them look awful in small screens. You have to add a JS and CSS just for that widget, some depending on jQuery. True, some of them are very configurable, but with the tiny cost of "<input type='date'>" you have a widget that looks decent and native everywhere, probably cover your needs, and you can forget about it forever (e.g. no updates, no CDN).

A lot of those date and time pickers will fail WCAG testing as well.

In most cases, GDS now use just 3 text fields for day, month and year, but recommend pickers for dates close to today's date e.g. for booking an appointment, because a picker is easier if you don't know the exact date without reference to a calendar.

Sadly they don't currently have a recommended picker, but there's a useful discussion of what has been tried here:

https://github.com/alphagov/govuk-design-system/discussions/...


The native date input is terrible. Not the actual native control, which is usually okay, but the field itself. You can't even format the date! That's the number one reason I always use some datepicker library in combination with a regular text input.

IMO, you (the web developer) should not be formatting the date shown in the input widget. The input should be shown to the client following the system settings, so a US browser would show MMDDYYYY, while an European browser would show DDMMYYYY. And the field is correctly (IMO) normalizing all of them to ISO-8601 (YYYYMMDD) before sending it back.

And I have this opinion because I had to deal before with format configuration and normalization before saving to the database, when using a JS library. Now I just drop a "input type=date", and I know I'm going to get the ISO formatted date at the backend.


If my entire application used YYYY-MM-DD everywhere, it can be very confusing for users when the input suddenly uses something else. And often the locale or system settings are incorrect anyway. When I an working on a Dutch site with a Dutch locale and lang settings, then dates should be shown according to the Dutch locale, not according to whatever system of browser locale there is.

I always keep my OS and browser in English (makes searching for error messages sooo much easier) but I hate that I need to change my OS settings just to get Firefox to display the date in a proper way on some site.


If it works for you, I guess it's OK.

My apps usually deal with non-technical people (thus ISO in the browser input is out of the question), and sometimes spread at least between Europe and US (so people would enter MMDDYYYY and DDMMYYYY, and keep in mind that some dates work validate for both formats, namely every 12 first days for each month). Behind the scenes everything is ISO and UTC, but everyone gets their preferred format in the frontend.

I'm not getting your Dutch example. If I'm in the US and use MMDDYYYY almost always, and want to access some Dutch site, what date format would you show me in the input form? DDMMYYYY only because the backend is hosted in Europe? You will get wrong dates (e.g. 11/1/2024 for the first day of november, your system will store 11th of january) for at least half the US visitors.

Or maybe you are talking about "dates displayed" instead of "dates input", which is a different problem?


To be honest I would expect dates on a Dutch site to be shown in dutch format, just like I expect dates on American sites to be formatted in the US way.

Lets clarify a bit here. There are two different problems:

- Date display. I prefer to show it in the browser preferred format, but in the end what you say is also OK. It's a very minor issue.

- Date input. I would never force a format to the user, it there is any chance people from different locales can access the web. The correct way, IMO, is "input in the preferred browser format, send data as ISO". Any other combination would cause errors, e.g. "input in the preferred browser format, send data in that format" and you'll get wrong dates in the backend, or need to do a lot of gymnastics to avoid them. "input in server locale, send data in any format", and you'll get wrong dates from people used to any format that is not your server locale that happens to validate in multiple locales. "input in ISO, data send as ISO", you'll get users upset because "YYYY-MM-DD is stupid, use MY locale instead".


How do we know when a site is Dutch? Maybe check the URL to see if the TLD indicates?

I'm in agreement with showing/inputting dates in the users' regional setting.


<html lang="nl_NL"> of course

Unfortunately the number input is lacking and inconsistent. We’ve always fallen back to JavaScript validation.

https://jsfiddle.net/gaby_de_wilde/1qh4cax7/

I'm trying to picture a room full of <s>people</s> developers agreeing letters are numbers too!

Lets give the little people a slider but lets call it a range!

I really feel like they are trolling.

You start with a neat database table then you engage in an endless struggle trying to allow the user to edit a single row of it. It really feels like you are not suppose to do it. As if it was intended to be as annoying as possible.


They’d want 7 parallel lines, 1 red, 2 green, 2 transparent, 2 blue. Oh, and 1 of those lines should be perpendicular.

For the confused: This is a reference to "The Expert" sketch: https://www.youtube.com/watch?v=BKorP55Aqvg

`type=text inputmode=numeric` (from other comment)

Also, many things that look like numbers shouldn't be encoded as such, e.g. credit cards or phone numbers, are not.

E.g. any leading zeros get dropped out of phone number starting with a 0, very common.


I had to recently make sure that we do not use any of the more complex input elements, because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page.

And that means it's barely doable with normal inputs, the special ones support even less events.


> because we need to drive them from on-screen keyboard that for various reasons is also implemented in-page

There's your problem right there. Can you expand on the reasons? It seems like very bad practice for a website to provide it's own "keyboard" instead of using the system keyboard.


This is for a closed system that unfortunately sometimes is supposed to be available outside[1] - a touch screen panel UI for (big[2]) embedded system.

It's hard to impossible to properly guide OS outside the browser regarding what keyboard we want at different points in time unless we end up also implementing custom keyboard plus some way to talk with it from JS. Previously we used a Chromium extension that could bypass some of the issues because it had privileged access and thus could send "secure" events.

EDIT: For some extra context - for reasons of ease of use, we want the keyboard of appropriate type (numeric, qwerty, other specialized layouts) to show in position related to actual input field, not take entire lower part of the screen like typical on-screen keyboards. For dealing with possible edge cases or otherwise making it more accessible, we also provide for the keyboard to be draggable by user.

[1] Sometimes it's accessed externally instead of in-person, for various reasons this means we have both the ability to open the web interface and use VNC.

[2] By big I mean we have a complete PC running Linux there, with intel CPU/GPU and an SSD


Isn't this use case already solved by phone browsers? Layouts are controlled via the inputmode attribute. Positioning the keyboard should be something solved by the host environment.

1. inputmode is very, very limited

2. "Solved by host environment" in practice means "worse user experience" as pretty much all of them simply use lower portion of the screen.

In comparison, the current draggable on screen keyboard I spent significant amount of time getting working allows the worker to drag the keyboard around if it overlaps a piece of information they need, as well as takes comparatively little space on screen enabling workers to better see what they are manipulating.


That use case makes sense, especially if this is an internal tool.

They could improve user experience everywhere if browser vendors wanted. E.g. why doesn't my (desktop) browser auto-complete recently-visited / bookmarked URLs when it sees type=url?

Privacy?

It's possible to display something in a browser without leaking the data.

Seems strange that iMacs remain ~20% more expensive than MacBooks.

Macbooks don't have 24 inch screens with 4.5K resolution.

Premature by 17+ years? He was and remains completely wrong.


With all of the APIs _modern_ browsers are exposing these days, web apps are extremely capable and remain the best multi-platform solution.


No? Most modern apps these days _are_ just web apps. Why does it need the overhead architecture of running full standalone applications when a web clip works just as well? Plus there's no need for updating.

The problem at the time was multifaceted. The devices couldn't handle it, the network couldn't handle it, and webkit was still relatively limited. But it did work. https://9to5mac.com/2021/06/03/remembering-apples-sweet-solu...


I have never, ever used a web app that runs as well as the native app.


Oh, well I can provide an example. Music League’s PWA on iOS is quite a bit better than the app — partly because you can avoid the ads!

Performance isn’t incredible, but neither is the “native” app (95% sure it’s react native or similar), which frequently dips below 60fps.


If that's the case, then why does nearly every company have a native app in addition to their website? Surely, they could save a lot of time and money by just not building and maintaining the app.


Because it's a pain in the ass to distribute. And there's not much for support integrated into mobile operating systems for seamless browser windows.

MacOS is getting there kind of lately with safari being able to turn web pages into apps. But there isn't really built in mechanisms for that: https://www.macrumors.com/2023/06/14/how-web-apps-work-macos...


Web apps will always on paper be slower (not including badly made applications on both) than native apps, and also bring in additional security issues (since code is loaded remotely) than native applications.


apps built using the webview don't necessarily have to be loaded remotely. If you're building with capacitor, then nothing happens remotely until you choose.

The part about being slower is still true though.


The funny part is that it’s actually not a pain in the ass to distribute. On iOS, saving the current link to the homescreeen installs the PWA (if available). You don’t have to do anything other than tap a button in the share menu. iOS treats it like an app, showing it in the app switcher and search, etc.

People just don’t know it’s an option. And as you say, there are fewer native APIs available to it.


Native apps make more money, because of phone data. A lot of effort is now put into facilitating cross-platform builds, a wrapper/container around a glorified web app is among the easiest ways


There's no adblock for native apps. Also, they can keep running/monitoring-you in the background easier.


Most modern apps are just services. If you don’t mind you computer being a thin client to someone’s computer on the internet, go ahead. But the rest of us do use native software because the web is just a pale imitation.


Could someone suggest a good CRUD starter kit?


Are integers still a preferred method for working with and storing monetary amounts or can we go back to decimals now that most languages handle decimals decently? Monetary amounts pretty much always need to eventually be presented to humans so handling them as integers is quite a pain.


It isn't that common to need fractions though. Money is typically handled in integer amounts (we just divide the amounts by 100 or whatever to make it easier for humans to grok). Nobody's going to pay half a cent for a latte for example. If for some reason you do need to deal with 1/1000 of a dollar, or 1/10000 of a dollar, you can still use integers. You just need to know the scaling factor.

Your presentation layer is probably always going to need to do some manipulation of the number anyway (put a dollar sign on it, etc) so using a decimal amount just for presentation needs isn't a huge win. But it will work too.


A decimal type is sometimes orders of magnitude slower than integer do simple stuff like summing (at least in Postgres and Python).

This comes into play if you have to do aggregate functions across tens of thousands of rows and can kill performance compared to integers.


Seems strange the government can enforce such a thing on private organizations.

How would they even determine? Would need to prove that a legacy is clearly underwhelming.

If I ran an organization, I'd probably prefer the ability to accept family members and donors.


Is Apple TV+ at all necessary? Always seemed to me a lousy idea for Apple to pursue. There are plenty of good options that have already watered down all the efforts. The great unbundling has resulted in the great re-bundling. Apple should focus on the hardware & software needed to deliver and consume the content.

Edit: I guess this pullback is only from releasing theatrically to streaming.


ATV+ TV shows are on par with HBO in its greatest days, even the worst ones are good in their genre and the good ones are _excellent_.

Their movies though... Not so much. It seems that producing a high quality movie is a different skill set to doing the same in a serial format.


They want it all.


Bills that could kill major new industries need to be reactive, if at all. This was a terrible bill. Thank you, Governor.


If the new industry is inherently unsafe, it is better to be proactive.


Even if I agreed in general I would not be sure about this case.


Yeah, this specific law sounds like not great law.


https://thezvi.substack.com/p/newsom-vetoes-sb-1047

This link convinced me otherwise. I wasn't too sure before (I'm a little ashamed to admit I hadn't been following the development of SB 1047).

I will also specifically share this talk on YouTube: https://www.youtube.com/watch?v=xoVJKj8lcNQ

I think this passing this bill would have probably been a very good idea. Not perfect, but far, very far from broken.

Edit: I'm actually not sure if we as a community gave this topic enough attention leading in the months leading up to the announcement of this decision.


Maybe he did, but not recently.

He posted this several days ago: https://x.com/elonmusk/status/1837908705683059166


He also baked in an out for himself. Now, if Kamala Harris wins the Presidency, he can say that she prevented from totally doing the thing he said he was going to do.


Sending humans to mars is difficult.


I find it interesting that he thinks being nuked every two years is a benefit to being so far from an out of control Earth. I’ve seen BSG and know nukes can fly in space.


Stealth is hard in space. Not actually impossible when the opponent is a colony with the population of approximately Luxembourg, especially for a mostly-unpowered payload that doesn't need to be kept at 20 C the whole time, but it is hard.

Nukes can fly, but for that transit you get far more opportunity to shoot them down. Bigger issues are "why are they bothering to target Mars, there's not much there" and "oh wait, that was a great place to stick a second-strike capability, Outer Space Treaty LOL, so of course it's being targeted".


Seems like solar could easily supply?


Easily, assuming you have solar panels that could survive the temperatures of the lunar night.


You don't absolutely need to put your base somewhere it'll have a night. There's a large mountain chain on Moon's south pole that's in constant sunlight.


Yep and whoever controls that, controls the moon. It’s prime real estate.


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: