Privacy by design isn‘t enormous effort, as every European engineering manager will tell you. It‘s just another reasonable and straightforward set of requirements. Of course, if you want to have privacy-less features in jurisdictions permitting it, that‘s a different story and that‘s a choice.
DMA is about competition not privacy. Apple has privacy concerns with complying related to 3rd party access to customer data.
Another aspect here is that even if Apple tries theirto best to comply, the EU could decide they didn’t do a good enough job and fine them 10% of global revenue. Honestly Apple just might not want to take that risk.
Not quite.
It is up to Apple to design a system in which operators (even Apple) can't see your data. Apparently they designed it in a way that operator can see it (so it is cool if it is Apple, but not cool if it is someone else).
Any network service with 24x7 availability and millions of users requires constant maintenance. Hardware has some lifetime and needs to be maintained and replaced. OS needs patching. Dependencies need security updates and, time to time, migrations to next major LTS update. Sometimes new requirements come from regulatory, that need development of new features. The skill set needs to be maintained. Support requests need to be served. Law enforcement may ask for some data.
Add to this hard digital sovereignty requirements: continuity of service must be guaranteed for decades. All this requires quite a special setup in which commercial entities are rather tolerated than welcomed, but they may still make more sense than a government agency so constrained by budget process that they cannot hire any decent engineer.
Of course, I understand why some maintenance is required. I just don't get why there is apparently a big maintenance burden over something that is usually a single small feature of a service
Digital ID is in no way just a „single small feature of a service“, but even if it would be so, for every tiny thing there exist 10x more requirements that make it a product.
A dysfunctional organization will project its failures to everything it touches. I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process. Nowadays, I opt in for Atlassian because it works fine out of the box, I avoid heavy customization (which would mean tool lock-in), and Claude can move the tickets itself anyway - no scripting required.
“ I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process”
I work in medical devices and our Jira is a mess too. Seems a lot of people try to solve process problems by customizing Jira.
„Every organization thinks that they are unique, yet they all are doing the same thing“ (a quote I heard last time from an SAP consultant, which is probably a common knowledge or some named law).
This is the funniest thing about customization of enterprise products. They spent hundreds of years on user research and product development, so chances are high that their standard solution is sufficient for your problem, and you don‘t need anything else. Yet too many people are tripping on the hard problem of enterprise products: the custom fields, which they hardly even need.
Sounds… political. You have cross-functional teams interfacing via a tool. It would be reasonable to co-design this interface, so that all user goals are taken into account. When engineering owns the tool, do they approach the configuration of JIRA the same way as they build the product?
We approach tickets that match with our development strategy. A ticket is tied to and represents a branch of code. When that code is merged the ticket is done. It cannot be reopened, you open a new ticket and link it and there will be a new branch.
I know everything that is in our main branch by looking at jira.
Product mangers and executives often want a very different view or workflow and it is hard to bend jira to work for everyone. Jira would need to have things like parallel workflows on a ticket and that would just get confusing and complicated.
it is not, as long as focus is on goals rather than on solutions (applies to everything). Nobody needs a view or a workflow. Everybody has jobs to be done. That is the starting point in process design.
Government agencies can pool their resources to operate a shared data center. If you take just a tax office, they are operating at scale where they have sufficient demand to operate 2-3 data centers per country in half of Europe. As for the skills, a for-profit SOE or a non-profit can deal with this as a regulated primary contractor. IT is a special case where consolidation and moving ops in-house actually makes sense at that scale. US gov does not do that likely for political reasons.
I owned Salesforce setup with 4 engineers and 500+ licenses. I don‘t see how could I replace our SF setup with an in-house product on the same budget within reasonable timeline. We won local competition within a few years, because our sales could use good CRM from day 1 and our competitor, according to the rumors I heard, could not calculate properly sales agent commission. Vendor lock-in is not always a stupid thing. Sometimes it‘s the bet that wins you a market.
Zoom out a little though.
I've always felt the main reason
That most companies use Salesforce
Is that most companies use Salesforce.
I'll give you an example.
At a previous employer,
We used Google Analytics.
We paid for Google Analytics.
I feel positive that as a mid size company,
We shouldn't have paid for Google Analytics.
The free product with 50 events in GA4 should be plenty for us.
But why do we use Google Analytics in the first place?
Because everyone uses Google Analytics.
I agree that sometimes Salesforce might be a good idea. However, it should be a part of an overall strategy, not just because everyone does it. This kind of deliberate tooling strategy is difficult though because the way Google Analytics or Salesforce works from what I understand is make marketing folks feel they are specialized in Google Analytics or Salesforce so they feel like they have to keep using it or their skill will become useless.
It is like resume driven development but for the whole business.
>I've always felt the main reason That most companies use Salesforce Is that most companies use Salesforce.
It's like this for most software, but as a salaryman it's better for you if you use the common software. If you have an interview you can now say "I know how to use the thing that most people use" instead of "Actually we had an inhouse system so if you hire me I need to be onboarded for 3 months".
I got hired to my 2nd job in large part because I knew how to use Broadridge Paladyne (back then it was pretty good if you got over the pretty bad UI/UX, by today's standards it's not great).
I think it‘s kind of a common knowledge now that Salesforce is very expensive, so it is not a go-to choice for most startups/no-CRM-experience people. You are more likely to start with Hubspot today than with anything else, but those low-effort CRMs are also quite easy to migrate from. Google Analytics too, so it’s not exactly a „lock-in“. The lock-in happens when you struggle with your current setup or risks associated with it become unacceptable, but do not have the budget and a competent team or external partner to execute the migration.
„Everyone does that“ is definitely part of decision-making process almost everywhere, but I personally have not seen companies where it’s just a cargo cult rather than a reasonable strategic choice. The obvious benefits are that it’s easier to find implementation partners, the costs are predictable and your users may already know the system, so you won’t have unnecessary friction in your ops.
This is the only correct way to do it: choose infrastructure provider that can help you deliver. AWS is good, just not for everyone. It stands somewhere between services like Heroku and bare metal, abstracting a lot of maintenance, but offering some control over scaling architecture. Which means that as a cloud provider it helps to scale, not to build the cheapest and simplest setup possible. If you have VC money and pitch growth, AWS might be a safe choice - 2 years of startup credits they offer via accelerator programs help you not to bother too much about your infra budget and build first 18 months before you start optimizing spending (and then you know it, have good forecasting etc). If you are bootstrapped or indie developer, choose what you can afford and choose something simple. Hetzner, DO etc will work fine.
Technically, the kernel team is sufficiently competent to design and build bespoke tools for themselves. It‘s probably a question of risk assessment and priorities.
>A spotty connection hasn’t loaded the dependencies correctly - Either they load or they don't. How would the dependencies load "incorrectly"?
Let‘s say you have 5-7 dependencies to load, but 3 of them timed out because your train entered the tunnel. Your app ends up in incorrect state, fails silently and UX degrades unpredictably. This is where the conversion often drops visibly and the reason SSR is now a go-to solution for any marketing website.
Why am I loading dependencies from 5-7 places? Why is my website not using a bundler if it has so many varied dependencies? Why do we not expect the user to understand that they are in a tunnel without internet?
Regardless, this isn't really restricted to the usage of JavaScript. The website would likely have pretty bad UX if only half of the CSS loaded correctly, but no one programs defensively around it being absent.
Have you ever developed an enterprise scale frontend applications optimized for conversion targets? It feels like you have not. You may ship your own code in a bundle, yes. All integrations come on top of that. That chatbot, tracker, A/B testing logic etc - all are loaded separately from your service provider CDN.
An user opening a web page is not expecting a full-blown app with multi-second loading times. If that happens, they bounce, and you loose revenue. Web is supposed to have very short time to first content paint and very short time to interactive, the shorter, the better, less than 0.5s is the goal. It can deliver that, if built properly. Many SPAs, bulky JS apps are built this way for developer convenience, not for end users. The only real use case for SPA is when you deal with a lot of local data. A spreadsheet, document or image editor, a diagram tool (but then wasm is probably a better choice).
You may say, you are not building enterprise grade frontend. But if you are small enough, you don’t need SPA either.
Go on. How do I have no idea what I'm talking about? Why is it okay for a website to break simply because the analytics don't load? Why do you think that's good design? How is my personal, lived experience less valuable than yours?
Is it just that you're ashamed that you have made such poorly designed web apps that can't handle a few broken HTTP calls?
Is it just that you can't simply accept that JavaScript is a requirement for the modern web which is what this entire discussion is hinged upon?
You dismissed A/B testing as unnecessary. That is sufficient for this judgement. A/B tests mostly run on the happy path scenario of a customer: An A/B test breaks, the company is losing money at light speed.
The loading-related issues overall may eat 0,5-1% of the revenue. It is not something that should be an afterthought.
Lol, okay. I didn't know that every single customer was going to go through a tunnel as they loaded the page.
I didn't dismiss A/B testing. I'm just saying that, if the analytics don't load on the client, you should already have A loaded and ready to render. It's literally just a matter of a try/catch, and you shouldn't be waiting to load this stuff on the client-side anyways if this is truly supposed to be the "Happy Path".
Yes, I know that legacy software like Google Tag Manager requires client-side integration, but I would argue that is an orthogonal concern. You don't need to use that for your A/B testing. It's pretty easy to integrate this stuff into SSR-- especially if you stream in the HTML. This is why cookies exist.
And, again, none of this changes the central concept of this comment thread: JavaScript is necessary for the modern web experience.
Literally none of those things are necessary for a working website. If your site breaks when your analytics don't load, then that's just horrible design at any scale.
A normal person would immediately think "dang, page didn't load before I entered the tunnel. Guess I'll wait til I'm out again and refresh".
And if they're deliberately going somewhwre where there's no signal for an extended period of time, and really want it to work, they'll ensure they've loaded everything before doing so.
And I say this as someone who is developing a pwa that is for people with low end phones and very inconsistent and/or connections. I'm very cognizant and empathetic to their situation.
Anecdotal evidence does not beat statistics and user research. Bounce rate has inverse correlation to loading speed. People with low intent do not refresh, they simply don‘t come back and look elsewhere or just move on. Telling you this as someone who built first commercial website in 1999 and was a hyperscaler B2C startup CTO. Let‘s not measure the length of credentials.
To clarify, you're saying we should be jumping through convoluted hoops - full page navigation + js to rewrite history, all so that you can avoid a very minimal amount of js to show/hide a nav menu - for low intent people who are frequently entering tunnels?
Something like Datastar would enable this with like two html attributes, and only require 10kb of js (and would also allow for endless other things via declarative html).
reply