> The fact that they are canceling pending applications is simply evil.
Where have you seen this documented? I haven't, and the only government statement I've seen about this was fairly clear that the change is for new applications.
I am genuinely asking. I have friends who are going through the process.
It’s a shame that I had to scroll past pages of invective and name-calling to get to your comment, which is the first one to substantively deal with the policy change.
Like you, I tend to think this is a ham-handed move, but like one of the sibling comments, I also have to acknowledge that it’s common for other nations to require change-of-status applications happen outside the country. For example, Japan requires this for some (but not all!) visa modifications.
Also, I’ve seen otherwise reliable sources making unsupported claims about this (e.g. “Existing applicants will lose their ability to apply again if they leave the country”) that aren’t clear from the minuscule amount of information that has been released so far.
As usual with these debates, the content is far more heat than light.
Japan only requires leaving for converting a tourist/digital nomad visa and some Working Holiday Visas to a normal working/spouse visa. And WHV to normal status is really dependent on the partner country. For example Australians don't need to leave, but Canadians and Brits do, and I've heard that immigration will sometimes just grant the change of status anyways. So that seems to indicate that Japan doesn't really care.
Needing to leave to convert a normal working/spouse status to PR is not the norm anywhere.
> Additionally, Japan has a very clear and straightforward process to convert HSP Visa (Highly skilled visa) to a permanent residency.
I mean, that's true as far as it goes, but HSP is one special visa amongst many, and they're not all so easy. Also, Japan is currently in the middle of its own dramatic restructuring of the immigration system related to HSP, including a number of new requirements that would drive critics of the US system to apoplexy (i.e. language fluency requirements).
Overall, the Japanese system looks a lot more conservative than the US one, though the sanity and consistency level is far higher.
> HSP is one special visa amongst many, and they're not all so easy.
Japan has a selective immigration system where the profiles JP gov considers as "necessary" are made easy to immigrate, and the others not so much.
One can disagree with the method, but at least it is consistent.
Near that, half of the American tech (and associated GDP) is constructed highly qualified immigrated engineers on H1B visas, and still the US gov openly shit on them.
> US system to apoplexy (i.e. language fluency requirements)
JP mainly just put some Japanese language level requirement on the HSP visas related to roles with communication. That honestly does not shock me.
We agree that the Japanese system is far more consistent. I think it's better!
But let's not kid ourselves: if the US instituted a CEFR B2 language requirement [1] for anyone on an H1B visa to gain residency, it would be an absolute shitshow.
[1] This is the new Japanese language requirement.
Assuming English is the language, CEFR B2 is roughly 75 in TOEFL, such a low standard that community colleges would think twice before admitting such internationals students. In reality H1B tech workers easily blows 100+.
Right, it's obviously your assumption, but you stated the resulting shitshow as an obvious fact—"let's not kid ourselves".
I doubt H-1Bs would oppose taking that test. Many already took English proficiency exams by the time they apply for the visa.
I assume Americans in general would favor this extra requirement too.
And companies, if we decide we care about what they want, really have no reason to oppose the test. There's a large enough number of applicants that they can easily pick from the ones that do speak English fluently.
So to conclude it would be a shitshow because of the politics is likely incorrect, certainly defeatist, and gives up on the actual thing we should strive for, which is to make the H-1B visa better.
I think one of the primary divergences of thought happening here is whether H1B is indeed a temporary visa or whether it was meant to be a stepping stone to a green card.
H1B is only 36 years old. The Immigration Act of 1990 always meant it to be a temporary status, which is why it is so easily imperiled.
Yes, it's temporary, but the 1990 act explicitly established dual-intent, which clearly made the visa eligible for adjustment of status under INA 245. Nobody is really debating that fact, but the announcement memo is also not clear about what they're going to try to do in terms of actual administrative process.
Part of the noise around this topic is that the administration just announced something vague with no detailed guidance, which leaves the door open for bad-faith interpretations by everyone.
It's also necessary for media to exist as an industry. The objective of nearly all news articles is clicks, comments, and sharing. Bad-faith interpretation is by far the best way to increase the count of all of those things regardless of how detailed the guidance might be.
The adjustment of status process is written into law for all non-immigrant visa categories (except for a couple weird ones, like the visas for crew of ships and aircraft).
If you mean that there is a general law related to change-of-status that was passed in the 70s (or whatever), then yes. But I'm referring to specific wording in the dual-status visa categories (and perhaps some others?) that explicitly prevent the administration from applying this change of interpretation to those categories.
Can you point to the actual statute you're talking about? To my knowledge "dual-intent" only means that the requirement in INA 214(b) that they are presumed to be immigrants until they demonstrate otherwise does not apply. I'm unaware of anything in the adjustment of status process that is different for those on dual-intent visas.
With the caveat that I'm absolutely not an expert in this area and have no clear idea what changes have been made since, it's still highly informative to read this section and the carve-outs that were made at the time.
My current understanding is that the creation of "dual-status" visas (immigration act of 1990) paved the way for using the adjustment-of-status process established 8 USC 1255 for those particular visas (like H1B), and thus makes those visas less vulnerable to a change of interpretation by the executive branch. Contrast to, say, a regular tourist visa.
Yes, I'm asking what carveout for dual-intent visas you're aware of in the Immigration and Nationality Act. The section on adjustment of status, INA 245, doesn't mention dual-intent at all.
Dual intent didn't exist when INA 245 (= 8 USC 1255) was drafted.
My current understanding is that the "carveout", as it were, is the creation of the notion of dual-status itself, in the 1990 immigration act. This made H1b visas both immigrant and non-immigrant visas, and thus eligible for INA 245.
For example, a law firm's opinion:
> However, the USCIS memo suggests the new policy may be less applicable to dual-intent nonimmigrant categories (e.g., H-1B, L-1 and their H-4 and L-2 dependents), where applying for adjustment of status is not inconsistent with maintaining status as a temporary visa holder. Dual intent means that a person can legally intend to reside temporarily in the United States for purposes of their temporary H-1B or L-1 work visa and simultaneously intend to apply for a future permanent residence status. Dual intent is a well-established concept in business immigration law, with many decades of support in federal law and regulation. The USCIS policy memo does caution that maintaining H-1B or L-1 dual-intent status alone is not sufficient, on its own, to warrant a favorable exercise of discretion. The USCIS officer must still weigh whether or not to exercise discretion in approving the adjustment application, but adjustment applications have always been discretionary.
Yeah, that's a wild leap to conclusions. The "accrual of unlawful presence" is when you overstay a visa, or otherwise stay in the USA illegally. Here's the definition:
> Asylees and asylum applicants: Generally, time while a bona fide asylum application is pending is not counted as unlawful presence.
So unless there's currently a huge backlog of people staying here illegally who are somehow eligible for green cards in spite of this fact, the government changing it's policies to require new applicants do so from overseas is not itself causing these applicants to violate immigration law.
The note is not “grossly wrong”. It’s from the USCIS website. It’s consistent with many other independent legal sources that you can find with a trivial web search.
> ICE was/is putting them in jail while they appear for immigration hearing at courts.
You’re talking about a completely different set of events.
This policy change was just announced, and it has nothing to do with things that happened months ago.
As someone who has suffered from hay fever for my entire life, and also lived in many different locations, almost every move came with a 2-3 year reprieve from my symptoms while my body "discovered" the fun new local allergens.
While reading this thread, I literally just caught an agent putting in the following CSS selector in a rule:
> .row > div > div, .alert
This is fairly simple CSS, not multi-threaded systems development. A bar low enough that you could trip over it. I catch this kind of stuff all the time (literally every run), but only because I read every line. Most of it wouldn't be the end of the world for any particular task, but would eventually result in a complete mess.
I think the people doing the heaviest breathing around the elimination of programmers either aren't very good at programming, or they're not paying close attention. Or they're hyping their book.
That's interesting. As I said I haven't tried using LLMs at this level, although I'm about to embark on some this week.
What I've found helps (at least at the other layers) is to have principles documents and standards documents for the AI to reference when it's modifying code. Principles documents describe the why, and standards documents describe the how.
So for example a few parts from my initial CSS-standards.md (still needs a lot of revision):
## Utility-first discipline
**Raw utilities everywhere by default. Never `@apply` for "components."** `@apply` exists only for
true low-level primitives that can't live in a template (e.g., `prose` overrides, embedded
third-party widget shells).
Wathan's stated position: extract only on "worrisome duplication." The Tailwind team explicitly
describes `@apply` as a tool you reach for after first reaching for templates. **Premature CSS
abstraction is the failure mode.**
## Spacing
Use only the default scale (`0, 0.5, 1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24…`). **Never `p-[13px]`.** If
you need a value, change the scale in `@theme`:
```css
@theme {
--spacing: 0.25rem;
}
```
v4 uses a single `--spacing` multiplier; everything derives from it.
## Anti-patterns (banned)
- **`!` important prefix** (`!bg-red-500`). Fix specificity properly.
- **Arbitrary values for colour** (`bg-[#1da1f2]`). Define in `@theme`.
- **Arbitrary pixel offsets** as default (`top-[3px]`). Use the spacing scale. Tolerated only as
rare one-offs.
- **Nested custom CSS more than one level deep.**
- **`@apply` for any class that wraps fewer than ~5 utilities** or appears in fewer than ~3
templates.
- **Dynamic class string interpolation** (`text-${level}-500`) — purger can't see these.
- **Custom breakpoints in v1.**
- **Inline `<style>` blocks.** All CSS goes through `assets/css/app.css`.
Yeah, I have those, but it's still pretty hit and miss, and obviously, it ends up being a game of whack-a-mole for everything I find.
I don't mean to over-state the importance of these little errors, just to say that agents do plenty of dumb stuff, even today, and the people who say otherwise are selling something or (hot take incoming) some combination of stupid, lazy and/or delusional.
Just IME, the quality of the prompt often significantly affects whether it does bad stuff like your example. It's not easy by any stretch and I'm still getting there, but I'm up to a couple dozen or so "Agent Instructions" in my CLAUDE.md files for various projects that have to say things like: "when doing TDD, don't write tests to verify bug fixes in tests" because the agent is really good at following things literally. I am sure it will continue to improve, but until then every project needs some bandaid things like that.
> I think the people doing the heaviest breathing around the elimination of programmers either aren't very good at programming, or they're not paying close attention.
Yeah, absolutely. People think you're picking on, like, code formatting and no, dawg, your code doesn't do what you think it does, or it only handles the happiest of happy paths.
I do find it funny when people get mad about you critiquing their AI project. You didn't even write it, dude.
Specifically for CSS, these bots really want to just barf out tailwind-style crap. If you deviate even slightly from the standards and practices of the modal front-end developer, you quickly see how these things are brittle, and no amount of prompting and cajoling will truly affect their behavior. In this case, you're kind of seeing the downstream affects of saying "no, do NOT do tailwind, make actual CSS with actual semantic class names please and thank you."
Perhaps ironically, this results in the quality of output I might expect if I had prompted a right-out-of-bootcamp coder to do the same. (But at least it doesn't whine about it!)
> these bots really want to just barf out tailwind-style crap.
I get it. The LLMs struggle most with state. They don’t have a real fix for that yet. People generally compensate by shoving everything into context, and making the context window as large as possible, which half-works.
Tailwind happens to be “stateless” CSS framework. Nothing uses anything else, nothing is shared, nothing is reused, nothing stacks. It’s super easy to write, since you don’t have to worry about anything else, and the styles are all duplicated dynamically and ‘compiled’ — to the point you can copy-and-paste a HTML block with tailwindcss classes from anywhere into your site, and it mostly ‘works’).
—-
Tailwind is uniquely suited for LLM use, because the problem Tailwind solves is the problem juniors (and now, LLMs) struggle with most. An LLM can happily write up a bunch of styles, without knowing any of the rest of the project state, and if it’s tailwind, it will mostly sort-of work.
It just also happens to be bad practice, this style of development is the exact thing we told everyone not to do for two decades. (“Inline styles are bad! Duplicate styles everywhere is bad! It’s bloated, it’s inefficient. It’s the mark of inexperienced front end. Don’t inline styles. Unless it’s a tailwindcss class, you can inline those styles, they get a pass I guess”).
We used to measure our JS and CSS in kilobytes, by 2011 standards this would be “far too bloated for production use”. For the old-timers, it can be hard to grapple with the idea that we’re just purposefully doing ‘worse’ front-end intentionally now. The calculation changes when half your content/styles/front-end is LLM-generated, and therefore completely disposable. Very “they don’t make them like they used to” vibes.
Maybe you're right, but honestly, I think they're just barfing out the median content related to UI development that you find on reddit and stackoverflow and github.
For better or worse, web UI development has descended down a dark rabbit hole of bad code over the last decade, and so that is what LLMs were trained on. GIGO.
Yeah, it quickly becomes a "which came first, the chicken or the egg?" thing between junior devs and LLMs.
I will say, if you use a Mistral model, and if you insist your CSS framework is Bulma (tell it, 'no tailwind', 'no preprocessor'), it does okay at staying away from Tailwind. (Not perfect, not great, but okay).
No LLM I've used can handle raw CSS well (yet). If you are carefully curating your own classes and styles, you might just be on your own for a bit.
Tailwind produces CSS bundles that are smaller than without in pretty much every possible use case. This is obvious if you think about how the generated stylesheet looks and how it would compress. HTML gets slightly bigger but not nearly enough for the combined bundle to not be smaller.
There’s absolutely no tension between locality of behavior and separation of concerns in CSS: you’re putting styles on the elements in the document. The styles are defined elsewhere.
It’s like arguing that all of your source code should go in one big file because one file is less than two files, which means greater localization.
Its arguing that that source code that affects the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse.
Its not so much about same file, as reducing distance to understanding, whether visually or by some sort of easily traceable path.
Like you would want to init a variable closer to its usage, Or that having a 100 wrapper functions is less understandable than inlining for a single statement, or global mutations are harder to trace then local, and that sometimes its easier to inline a single sql statement then split it out into a different file just because its 2 different languages.
Also, to be clear its possible to write CSS that exhibits less or more LoB. The file thing is more that I don't think HTML, CSS, JS "must" be written as separate files which is what the prevailing best practice used to be, justified as SoC. I just think splitting along the scope/behaviour lines rather than file type is more understandable.
> the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse.
This is why I'm not that big of a fan of Tailwind and similar frameworks. To me it feels like they introduce yet another language into the mix. It adds all sorts of classes directly to the html, but now I need to understand what all of those mean. If I write my own CSS, I generally just have to look in one place to understand the styling of an element.
I think I feel kind of like that about overuse of annotations in Java. (Simple/obvious ones are fine, but not all are simple and obvious.)
It's worse than that; the common arguments for Tailwind literally derive from total ignorance of how CSS is made to work, and a disposal of guidelines that developers would worship in any other context (i.e. Don't Repeat Yourself).
It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might be useful in the context of a stylesheet.
Tailwind, JS-in-CSS, and the like have become popular because they work well with the modern corporate UX workflow. A Figma component has a certain set of styles, you apply those same styles to the corresponding React component.
And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.
> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component.
This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.
> And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component.
Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!
> There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.
That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt?
> Sure, sure. except for the inline styles everywhere.
There are no inline styles when using Tailwind. There are references to variables from the design system.
> And the fact that everything is literally being repeated all over the place.
If you find yourself repeating the same sequence of classes, it's time to create a component in your frontend framework if you use one, or a Tailwind utility class. And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.
> That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt?
Of course. It's obviously better to have 10,000 different names that are all loosely, but not exactly the same as the CSS property they're trying to represent.
It undoubtedly is! I'd much rather learn 10,000 different names that follow a clear naming scheme and stay consistent between different projects and teams, than 1,000 different names that aren't guaranteed to have clear names or any consistency (even inside a single team).
But I'd also like to push back on the "10,000 different names" - the overwhelming majority of those names are merely variations of the value they assign, so using any class teaches you dozens to hundreds of those 10,000 names. So realistically, the comparison is closer to "1,000 project-specific and potentially inconsistent names" vs. "1,000 consistent names valid in any project using TW".
Tailwind doesn't solve technical problems really, it solves social ones. In a perfect world we all write vanilla CSS. But, in my experience, it becomes extremely messy and hard to reason about in huge codebases with lots of developers. Which sucks but isn't surprising to me.
Additionally, I do not think, that copy pasting a CSS class name everywhere is a realistic sane use-case. Usually, one would render some template and that template lives only in one place in some file, not all over the codebase. If we go smaller than a template, to use jinja language, we have macros as reusable parts, also not having them all over the codebase. It rings like a gigantic strawman to me.
Premature optimisation doesn’t even fully express how absolutely ridiculously futile it is to try and make your website faster by having fewer CSS selectors.
It’s like my grandparents worrying about immediately switching off their LED ceiling lamps when they leave a room - meant well, but utterly meaningless.
If you're using components, it's the same as Tailwind, just put your CSS module files next to the component, or use compile time CSS in TS frameworks like PandaCSS to have them in the code itself. For shared conventions that is the purview of the design system and you'd have CSS tokens for various colors etc. Anything you can do in Tailwind you can of course do in CSS modules because it's CSS at the end of the day.
I for one do not understand what is so difficult about making a team internal decision about how some "component" (here in quotes, as I am actually thinking of an HTML subtree with specific purpose somewhere on an HTML page) is going to be named, and then give it that name as CSS class. Are people never talking with each other? Are people unable to grep a code base, before making up a new name? And how many similar but not same purpose things do you have on your pages, that this becomes a serious problem? Or is it just a discipline problem? People can name hundreds of useless OOP abstraction classes, but cannot be bothered to think of a good name for a "component" on a web page?
I mean, come on, there is usually tons of context and team internal language for the new thing to build and to talk about it, distinguishing it from the old thing that was already built.
And if that's too hard, then allow the design department to name the things they design and notify them about any clashes. They must have a design language anyway.
Again, this isn't really about difficulty—you can solve problems of arbitrary complexity by establishing a process, guidelines, rules, and documentation. But unless your goal is maximising the number of meetings you need to communicate arbitrary naming conventions, having a framework that takes these decisions from you is an efficiency boost. There will always be new invariants, combinations, or elements to style.
Say you have a .button class for clickable button elements. One day a junior engineer realises they need two of them next to each other, while one is more important. Predictably, as they don't want to bother one of the seniors with this, they are going to introduce a .secondary variant. A few days later, someone else gets tasked with introducing a variant prop for <div class="card">, so the upsell banner can be styled differently easily. "Oh!", they think, "Neat! there's a secondary class that sets all the same props I need!"—and just like that, coupling was introduced.
Sure, this is a contrived example. The junior could have scoped the class to buttons; or added an explanatory comment; or written a note to the team; or asked a senior; someone could have seen it in code review; or a heap of other mitigations. But all of these happen to fail sometimes, and compound over time. This isn't even really about CSS, but entropy at the end.
So to me, this is the benefit Tailwind brings to the table: By providing a styling language that doesn't require making up rules as you go, that scales to arbitrary project sizes, and most importantly doesn't need additional communication, you get optimized, side-effect free CSS that you will immediately be productive in, even as a new joiner or when you return after a long time.
> but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.
Yes. And as 30 years of CSS show, it's not enough.
> Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place.
It's not repeated all over the place, because in your codebase you have a single place where component A is defined. A single place where component B is defined etc.
I don't see you complaining about having to repeat the same CSS properties (padding, margin, display etc. + responsive styles + hover/disabled etc.) for half of the components when writing vanilla classes.
There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few.
Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there.
> Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!
Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
> Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
Erm...what now? That's so off-the-wall that I can't even wrap my head around your meaning.
Are you trying to argue that because, say, a conventional CSS file has "border:1px" in multiple places, this is somehow equivalent to the Tailwind approach of making a "b1p" class that captures the same thing [1], and plastering it across your templates?
Because a non-abusive application of CSS would actually just put that border property in a semantic class like ".widget" or something, and sure, you'd have multiple "border:1px" declarations across all of your CSS files, but that's irrelevant, because you're not trying to reconstitute every style inline from pseudo-properties.
[1] I am making this example up for illustrative purposes.
Yes, that's exactly what I'm saying. You don't end up needing a semantic class like .widget since you likely already have a Widget component in your codebase. Essentially:
In any real application you will have far fewer semantic class names than combinations of style properties. Working with concepts is vastly easier than trying to remember the specific property differences between concept A and concept B.
Obviously, a real application will have more than one css property. Also, your widgets will share styles, usually in a fairly obvious hierarchical way. And your designers will want them all to be consistent.
In this world, it’s far easier to remember that a widget is “.widget”, and that “.rounded-widget” is for the round version of that”, than it is to remember that the former concept is “.b1p .m5 .ib .xyz .pdq .foo” while the latter is “.b1p .m5 .p2 .br10 .xyz .bar”
The common arguments against Tailwind usually derive from total ignorance of working with CSS on large scale projects with many team members.
And when this is pointed out you’ll usually get replies that just hand wave it away as not a problem, as if things like BEM were invented for no reason.
> Sure it's possible, but is it possible for everyone on your team? Including the new hire, the interns, or the now-vibecoding managers?
Why aren't we asking this about any of the things that are actually hard? Like any programming language, or databases, or caching... CSS is the easiest part of the web stack.
> Why aren't we asking this about any of the things that are actually hard?
We do. That's what countless abstraction layers, linters, frameworks, style guides, and CI checks are for.
> CSS is the easiest part of the web stack.
…and because programmers keep thinking that, they stay ignorant about CSS and structuring the styles properly - leading to the problems I described above.
And the cascading thing is a nightmare even after years.
Whenever i have written CSS/TailwindCSS which was unproblematic to extend it was when i literally switch thinking to use least amount of properties and let the page flow.
Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.
DRY can be implemented using tailwind if you know how to. You can abuse tailwind and have no structure which I've seen even seniors do.
I've worked with CSS since 2001. Understood the CSS rendering engine in Mozilla like the matrix and written an absolute ton of cascading CSS using various methods and frameworks. All my stuff is now tailwind and it's pure bliss.
I'm fine with just the "cascading styles" part of CSS. The thing is it's also sizing and placement of elements in the webpage. Sometimes that's easy, other times there are 10 different ways to accomplish something that all feel hacky.
So? You’re trying to engage in tu quoque without saying it explicitly. If you think the argument is wrong, make a counter-argument. Don’t just say that the arguer hangs out with people you don’t like.
Cliff in an expert, he worked in the Obama administration on climate, and unsurprisingly, he is being cited for having opinions the support the thesis of the article.
ah.. a fallacy guy. there should be a named fallacy for mischaracterizing remarks so they fit the form of a fallacy, in order to clothe one's argument in an illusory erudition.
anyway if anything it would probably be poisoning the well. really though it's just pointing out that cliff isn't a garden variety climate scientist and comes with something like a warning label.
...and AWS does it too. I can go right into an account and see an estimated cost per hour, and even pre-pay at a fixed discount for longer terms if I want to. They tell me right there what it will cost. They do this for everything that is reasonably a "fixed cost", like CPU time.
They cannot predict what my bandwidth consumption will be, or other such variable costs. For those, they tell you rates.
No it's pretty bad. They show you the cost after all the resources are set up. Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table. It would take no space to just put the price per hour in the drop-down as you're picking an instance. But no, they obscure it on purpose.
That's just for ec2. Everything is like this. Super awesome when you're being brought onto a new project and trying to estimate costs for your client. And let's not forget the little tiny things that should cost nothing. A NAT gateway with no redundancy is $30/mo. That's a fun surprise.
> Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table
For the record, my original complaint that ec2 did not have pricing in the dropdown seems to be untrue right now, which is great! For the sake of UX discussion, I want to talk about your picture as if that were the only way to get this info. So let me explain why that's bad.
The main reason is this is only true for ec2 and every other resource has its own slightly different way of getting the cost, making it really easy to miss things like this. But here are the steps we take to get to your image.
- First you click compare instance types, and you're brought to a completely different page with a table.
- By default, there is no column for pricing, but two columns for "storage space" even though most of the instance types have these blank.
- There's nothing that says you can add columns to this page. You eventually figure out it's the gear icon.
- Then you click the gear on the top right to look at column names. You try searching the 44 column names for "price" or "cost" but both of those turn up blank, because there's no fuzzy searching.
- So rather than use the search box, you manually scroll through all 44 column names and find pricing at the bottom of the list.
This is the definition of out of the way. It's hard to imagine why you would default to showing two different storage columns over the pricing column, when half the instances are blank on storage.
Now do FSx, which has no pricing information at all, or any links to pricing information. They have an info tab telling you your backups are incremental, which would make you think they are fairly inexpensive. Not more expensive than the filesystem itself!
This is simply because AWS UI is not made by one team. Each individual team makes their own UI/UX decisions, and things like pricing info just get forgotten and/or scheduled "for later".
So they just added a default table widget, and they didn't even bother with customizing it. You can enable the context menu for the table's rows, which works and is empty.
I worked at AWS around 6 years ago, and we had a great win with just getting access to a service that provided the full list of available instance types and base prices.
This kind of disjointness is both good and bad. It's good in the sense that individual services stay within reasonable complexity, and usually all the functionality is available through the public APIs because the UI console is just another consumer of these APIs. AWS is also very careful with permissions, internal services try to avoid escalating privileges and try to perform everything using the user-visible access policies.
But it's bad because integration just sucks, and the UI layer is the ultimate example of this. AWS console _is_ really messy.
And to add to this: AWS teams were also quite focused on avoiding surprise bills for customers. Because surprise bills led to customer support interactions, Sev2/3 tickets that needed investigation, etc.
Where have you seen this documented? I haven't, and the only government statement I've seen about this was fairly clear that the change is for new applications.
I am genuinely asking. I have friends who are going through the process.
reply