Hacker Newsnew | past | comments | ask | show | jobs | submit | sagolikasoppor's commentslogin

Yes I think so. Most big tech companies are American and very over-valued compared to what the profits are. The American stock exchange is worth about double that of the European. I think the American stocks and companies will see a downturn in valuation and European and Asian companies will see an increase.

Other sectors that people today find is boring will have an upswing.


Mozilla is a perfect example on how wokeness destroys everything it touches. I would never pay any money to the Mozilla corporation until they really prove themselves not to be the extreme leftist activists they have been since they kicked out Brendan. Worst business mistake I have ever seen.


I vibe coded parts of https://gisformat.com/ backend in Rust in order to learn about Rust. So I think you are wrong there.


I have had a lot of stomach issues, I have done 3 CT scans during my life and I am not even 40 years old. I worry already about the dosage I have gotten.

Though when I asked they said it was like a long flight trip to aroynd the globe. While I don't believe that, I do believe that they are much more effective than they were 10+ years ago. Also I wouldn't have got my stomach surgery without my first one.


My main gripe with this is how do you charge users? They can just put the browser in offline mode and continue to use the app forever.

Also it's very hard to follow up bugs or other errors if users are often offline. I giess you can queue up errors being sent and so on but still. Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others. How do you solve merge conflicts?

I really like offline first web apps, but it is way harder and more expensive to build I think. For a startup it means more time before you can deploy your app and where I live there is pretty much fast internet everywhere so it kinda is solving an issue that very few customers will face.


That's literally how all software development used to work. All of these, except merge conflicts, are solved by expiring licenses, collecting logs and uploading them when asked or when connectivity comes back and it doesn't matter if it doesn't, it's the user's choice.

Merge conflicts are truly the only unsolved issue and for good reasons. Notably offline IDEs work together with on-demand-online version control software to solve this problem, and also have been since forever. Hard part is getting non-text data to merge; you usually implement file-level checkout/checkin logic (see perforce, sharepoint, etc.)


Well, Yes. But users today are used to everything being saved remotely, especially on a website. I think customers would be very angry if suddenly their data were gone because a sync didn't go through and data were lost because they cleaned their cache on perhaps another site that then affected all sites.

People do have higher expectations on software than they used to have. There are also other issues with syncable states than the OP wrote about. Just imagine that you upgrade your api, you will have to be very backwards compatible for a long time or force users to update their web apps when they come online again.

It's easy to mess up service workers and it's possible to put stuff in a state which is almost unable to recover from unless the users affected clear their cache and then risk losing all of their data. Stuff like that can't happen with a normal web app.

While all of these things are certainly possible, I also do think that the development time is longer. You will have a hard time to compete with businesses that don't care about local first stuff since they can pump out features in a higher rate than you can because you have to care about states in a much deeper sense.

It makes sense for some apps to be local first, but not really for that many imho.


> But users today are used to everything being saved remotely, especially on a website.

That's just a matter of training. They were trained that way. 30 years ago users were trained to "save often".


Absolutely, but then you have to be the guy training users when everyone else is training them differently.


> While all of these things are certainly possible, I also do think that the development time is longer.

I agree, but I don't think dev time is longer due to some intrinsic reality that local-first is technically harder. Nearly 2 decades of work has been put towards tailoring building blocks for SaaS systems. Similar building blocks can be made for local-first.


"My main gripe with this is how do you charge users?

Sometimes, I feel so old. Recently, I read about a junior dev who did not understand that you can build websites that aren't SPAs and was confused when Chrome's debugger cleared itself on a page reload.

People have been charging users for offline apps since before "offline" was a concept that needed to exist because back then, everything* was offline.

* with exceptions.


> My main gripe with this is how do you charge users? They can just put the browser in offline mode and continue to use the app forever.

Let users pay a price to download the application, do some magic key activation (that could work offline too) like countless of professional software? Ableton, Spine2D and Cascadeur are some recent software I've purchased that works just like that.

> Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others.

Yeah, I think if you have an existing application/architecture/design and you try to shoehorn in local-first with sync in there, there will be some additional work. But if you design your data structures with that in mind, it gets a lot easier. So as always, way easier for greenfield projects than migrating existing ones.

> How do you solve merge conflicts?

Depends on your application. In many cases, CRDTs (just one example) can automatically resolve things based on however you set it up. And for when that doesn't work and you need manual solving, that gets easier too as you can easily see exactly where it doesn't merge, and it gets a lot easier to build the tooling you'd expose to the user to resolve it.


> They can just put the browser in offline mode and continue to use the app forever.

You are so optimistic about browser's garbage collector! What you have said is possible, but I need a whole computer devoted to use some web-browser software in such a way. Any another web-page can make the "system" to crash and bye-bye foreverness.

It was better 10 years ago when I could buy a 1-day trial to some expensive newspaper, then open all the long-reads and read everything effectively free. Now any web-page tries to be very much smarter than the user and I would rather never use any proprietary "app" for not even seeing what the vendor has prepared to such a digital scavenger.


People have figured that out for desktop applications years ago.


> My main gripe with this is how do you charge users? They can just put the browser in offline mode and continue to use the app forever.

Charge users to buy the product. Don't charge users to use the product. I know it's a revolutionary way to think.

> Also it's very hard to follow up bugs or other errors if users are often offline.

Yes, so?

> I giess you can queue up errors being sent and so on but still.

Have you asked the user if they want those errors, which often contain private information, to be sent?

> Syncing means that you probably have to have a complicated logic, especially if the data you are seeing can be modified by others. How do you solve merge conflicts?

There's tens, if not hundreds, of solutions to sync. Why don't you take a look at one of the existing solutions?

> I really like offline first web apps

Really? It sounded like you wanted to charge users and didn't like the idea of users going offline. Kind've hypocritical to then say you like offline-first.

> more expensive to build I think.

Not at all. You should be building and deploying in containers. Containers can and should be 100% local first. You download the dependencies (`FROM` statements) and then disconnect from wifi. If you can't build after that then you're doing it wrong.

> For a startup it means more time before you can deploy your app

Not if you're doing it right.

> where I live there is pretty much fast internet everywhere

I'm happy for you! Unfortunately you seem to be the type of person who wants to reduce cost. That means remote workers. Remote workers often live where their internet is very sub-par and/or metered. Local-first (and especially offline-first) will help reduce cost even more.

> it kinda is solving an issue that very few customers will face

I assume you're in the USA. You shouldn't take the FCC's connectivity reports at face value especially after certain people have gutted the FCC's ability to provide reliable connectivity data. You also shouldn't assume that every customer around you has access to fast internet because, unfortunately, last-mile internet service providers have a tendency of monopolistically abusing their customers.

If you're not in the USA... well I'd still be willing to bet that you're wrong unless your customers are exclusively in an urban environment.


The only issue with that is when you switch to Linux, alternatives to Azure is much more compelling. I would never use Azure services unless I'm on Windows.


Could you explain this a bit more? I happen to like Azure, probably because I understand it a lot better than the other cloud platforms. What’s the connection to Linux OS?


I use Azure every day at work and I’m honestly baffled anyone could have this opinion. The interface is slow to load, when it works at all. I’ve had my log tails just strait up crash not allowing me to debug for hours. The documentation it ok, but if you want to do anything that’s not c# it’s a fucking nightmare.

I was recently trying to integrate EasyAuth OIDC with a custom IdP and it was a terrible experience. No logs indicating why it wasn’t working. I had to dig down into the configuration xml schema to discover EasyAuth didn’t even support client_secret_basic auth method so we couldn’t use it in the end. Every product is like this. Great if you do everything MS wants you to do exactly, but if you have any requirements not blessed by Microsoft you’re SOL.


Well, I do. I still like Outlook, and it works good enough as a web app. Same for OneNote. Azure as the development platform is crazy, of course. But I also have a friend who I respect much, and who is probably a better engineer than me, who likes Azure and completely unproductive with AWS, so _maybe_ that's a matter of taste. Just like tabs and spaces. I prefer spaces, but whatever.


> I still like Outlook, and it works good enough as a web app. Same for OneNote.

This I find baffling. Outlook and One Note are some of the worst applications known to man. Clunky interfaces and confusing messes to navigate.


I prefer managing my own hardware and find both Azure and AWS very unproductive for anything else than huge, big traffic, projects. Not sure if that has to do anything with my OS choice.


I used Ember and it sucked. It was too complicated and the community was elitist and hostile. Then it got extremely woke and political and even shut down the docs which made me lol and really dislike the project and its authors.


Nothing woke as far as i can see.

Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days


I have used caddy for years as a reverse proxy for all my side projects. It is one of my favorite pieces of software.

So easy to setup and performs very well.


That is probably because you live in the states that you think that. The EU is so regulated its hard to do anything nowadays.


> The EU is so regulated its hard to do anything nowadays.

What are you referring to here, specifically? Something that is a net-positive for society, and that would be legal in the US but is illegal in Europe or EU?


Starting the next Google or OpenAI. Not illegal, just not possible.


Where is the next Google in the US?

And OpenAI just burns money, maybe we should wait if it will survive.


Thanks to what laws/regulations? Or was that just the meme "Europeans are lazy/slow" but tailored to HN readers?

AFAIK, things like specific the text and data mining (TDM) exceptions would allow you to even train on copyrighted materials without permission in certain cases, in the example of LLMs.

Mistral also seems to be making progress, and I'm not aware of any African, South American or Australian efforts that are further ahead, so while it might not be number 1, Europe is at least not last.


Oh, that's not a very high bar now, not being the last :)

Siemens, Bosch, Mercedes-Benz, etc. etc. were innovative startups once that defined their industries and they put the foundations of the high standard of living that you enjoy now. Where are the similar European innovations of today?


> Oh, that's not a very high bar now, not being the last :)

Well, your argument was that it wasn't possible, so at least we both agree now that you were wrong there.

> they put the foundations of the high standard of living that you enjoy now.

Again, the crux of the argument is that I believe our institutions and governments are the reason we have high standard of living, not because there was three German companies who were innovative ~100-200 years ago.

I don't even understand how the innovations of those companies are related to the quality of life in Sweden, for example, but I think we've lost the thread in this discussion a while ago so maybe better to not continue at all.


I gave those three just as examples from many possible. The swedish quality of life is due to the similar caliber swedish innovators of the past hundred years. At least we agree in ending the conversation :)


Well, Mistral is looking pretty promising for AI.


So when we have to use main instead of master everyone is fine with it but now it's bad to purge words?

I think this is great news. Well done Trump & co.


This is false equivalence. Not using the phrase master was meant to create a more inclusive environment.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: