Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Four ways to build web apps

tomhummel.com

Post reply on HN
Print view View original

121–130 of 181 posts

Re: Four ways to build web apps

#121

Post by dgb23 »

0x073 wrote: post #87
dgb23 wrote: post #37

Earlier quoted context omitted.

> Do you have examples of such compatibility breakages? The wordpress integration test suite broke with PHP 8.0. They seem to be lagging behind for 8.1 and 8.2 as well. Remember new keywords were introduced and code just breaks in weird ways since these versions if you have conflicting names or depend on any library that has conflicting names. There was a somewhat recent article that talked about changes for a string…

> The wordpress integration test suite broke with PHP 8.0. Wordpress was since it creation a bad coded software and as a result they have issues with keeping up with the php release cycle. > In the near future you won't be able to assign new properties on instantiated objects anymore. Wrong, the stdClass that json_decode uses still works and will work, if you need dynamic properties without define it in your class ad…

> Next major version comes in several years until then you get deprecate warnings, (...)

AKA churn. Breakage is not OK.

PHP breaking every couple of years and showering you with deprecation warnings doesn't fix that.

It's like saying: "In a month I will punch your face, you better make sure to wear a helmet!". Just because you said that doesn't make punching people's faces OK.

There are languages and tools that don't break within that time frame and there are languages and tools that _never_ break.

There are also better ways of breaking changes: If you do break then give me a canonical, reliable, automatic upgrade path that also rewrites vendored dependencies.

> (...) if you can't fix problems that will occur in 2-3 years you should think about your software development skills.

It's not that we can't fix them. It's that we have better things to do but _must_ fix them.

Many of those changes are not critical or security related. They are just changes for the sake of change without consideration for stability. Everyone hop into the hype and churn train!

The baseline expectation is that my fundamental tools are backwards compatible and stable. People also have dependencies, transitive dependencies and so on. Dependency management is already hard enough without breakage.

Without stability there must be some _major_ advantage that we cannot get anywhere else. Stability ensures that fundamental libraries and tools can be _done_ outside of voluntary optimization and extension. It means you don't have fix code in multiple places and multiple projects without a compelling reason.

That's what I was getting at.

---

Note: There are good things about PHP and parts of it's ecosystem that I'm not talking about in this comment. This is a rant based on unnecessarily inflicted pain.

Re: Four ways to build web apps

#123

Post by jefurii »

nicbou wrote: post #101
arsome wrote: post #70

Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…

Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield. I agree with you in principle, but in practice mthese services replace dozens of hours of banging your head against software that's one misstep from blowing your legs clean off. Sometimes, you have better things to do than tweaking nginx configs using the average of a dozen tutorials and docs that might as well be written…

> Nginx is not relatively simple.

Sure it is, if your needs are simple and you follow a tutorial and don't just randomly spam stuff into your config files. Nginx can get really really complicated but it doesn't have to.

> mthese services replace dozens of hours of banging your head against software that's one misstep from blowing your legs clean off.

Yes, you can definitely spend hours figuring out Nginx, but you can shoot your foot off with a PAAS just as easily and at least Nginx is a technology that you can use in many different situations. It's definitely worth learning a tool like that, versus a commercial service where you play in a sandbox and they can jack up the price or change the rules at any time.

This is written as a long-time web developer and sysadmin. A lot of comments like the above seem to be written to try to scare younger devs away from standard tools and into the arms of PAAS vendors.

Re: Four ways to build web apps

#124

Post by jefurii »

sebazzz wrote: post #112
ZephyrBlu wrote: post #85

Earlier quoted context omitted.

1) Almost all of these services have generous free tiers. Even if you're running a relatively high traffic site your bill will be practically $0. 2) These technologies are stable and usually not that complicated. You are missing out on a lot of productivity by not looking into them. Understanding the "real underlying technologies" is a myth. The "underlying technologies" are constantly changing, unless you are using…

> Almost all of these services have generous free tiers. Even if you're running a relatively high traffic site your bill will be practically $0. That is what gets you hooked.

Yep. The first one is always free.

Re: Four ways to build web apps

#125

Post by adammarples »

arsome wrote: post #70

Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…

Disagree. Fargate is very simple and as far as I know has not changed much in years. Give it a docker image, watch it go. Want to leave? It's literally a dockerfile, take it and run it elsewhere.

Re: Four ways to build web apps

#127

Post by selcuka »

arsome wrote: post #70

Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need. It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I'll have very limited con…

> It'll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly.

First, Fargate and CloudFlare Pages are completely different things. Fargate is "serverless" Kubernetes while Pages is just static hosting (if you don't count workers).

While you have a point about the former, you can't beat CF Pages (or Netlify, or Vercel, or any other modern static hosting system) in simplicity. You just push your changes to your own Github repo and it gets automagically deployed. It is also free up to the point your cheap dedicated can handle. Try it and you will be pleasantly surprised.

Re: Four ways to build web apps

#128

Post by heliodor »

omnibrain wrote: post #106
nicbou wrote: post #101

Earlier quoted context omitted.

Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield. I agree with you in principle, but in practice mthese services replace dozens of hours of banging your head against software that's one misstep from blowing your legs clean off. Sometimes, you have better things to do than tweaking nginx configs using the average of a dozen tutorials and docs that might as well be written…

> Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield. And that's why I use Caddy.

The original point comparing nginx with services makes sense if you replace "nginx" with "caddy". Nginx is a disaster from a usability point of view.

Re: Four ways to build web apps

#129

Post by tphummel »

whartung wrote: post #53
linux2647 wrote: post #9

Earlier quoted context omitted.

Example: you don’t need AWS keys to write to SQS because the EC2 instance has an identity (“principal”) applied to it, and SQS has been configured trust requests from said identity for some set of queues. It’s typically cloud-specific in the implementation and the resources being requested

Do you know how they make this work?

my understanding is that the major public clouds operate Public Key Infrastructure on end users' behalf. It feels like magic because there are large teams of very smart and capable people making it feel like magic.

Re: Four ways to build web apps

#130

Post by DangitBobby »

2h wrote: post #99
DangitBobby wrote: post #76

Earlier quoted context omitted.

Consider creating a tunnel with Cloudflare Argo (think more sophisticated ngrok). I just finished deploying a toy app from a local machine about 15 minutes ago.

I read this entire page, and it doesn't offer what I am wanting at all. I have a localhost server, that I want to deploy so it's publicly accessible, like option 3 in the original article. https://www.cloudflare.com/products/argo-smart-routing/

Maybe the branding is a bit opaque, you might have more luck searching for Cloudflare Tunnels since they've changed some names. That's probably my bad for not using the word "Tunnel" in my original comment. Here's a blog post describing the product [1], and here's a link right into the middle of CLI docs to a command where they publish a site from localhost, and here's [3] a link to my crappy "blog" post that summarizes the process.

Like I said, I literally just deployed apps from localhost yesterday and today.

1. https://blog.cloudflare.com/argo-tunnel/

2. https://developers.cloudflare.com/cloudflare-one/connections...

3. https://blog.jorissen.xyz/posts/self-hosting-with-cloudflare...

Post reply on HN