Live data from Hacker News

Four ways to build web apps

tomhummel.com

81–90 of 181 posts

Re: Four ways to build web apps

#81
post #22

Earlier quoted context omitted.

I wouldn't recommend PHP to anyone who isn't already invested/emerged in the language. Wordpress for blogs or websites on a shared host with automatic updates and a few select plugins? Yes. Laravel or Symphony for applications? Ok. But just PHP has way too many footguns and doesn't provide nearly enough affordances to make them worth it IMO. Plus it's a language that breaks backwards compatibility way too often, stop…

Gotta disagree with you here. Modern PHP is quite great, especially when paired with Laravel or Symphony. They had to introduce breaking changes to move the language forward, but I don't recall anything huge after 7.0 or so. There's a huge ecosystem of packages to do just about anything web-related, and the documentation and community resources are way better than anything I've seen with say, Java/Spring. Laravel is…

We’re not disagreeing though. I was contrasting using something like Laravel with just PHP. And it’s not just documentation and ecosystem. You also get a stable, nice foundation with a clear upgrade path that protects you from a wonky foundation.

Re: Four ways to build web apps

#82
post #79
post #22

Earlier quoted context omitted.

I wouldn't recommend PHP to anyone who isn't already invested/emerged in the language. Wordpress for blogs or websites on a shared host with automatic updates and a few select plugins? Yes. Laravel or Symphony for applications? Ok. But just PHP has way too many footguns and doesn't provide nearly enough affordances to make them worth it IMO. Plus it's a language that breaks backwards compatibility way too often, stop…

I'm sorry but this is a really ill informed comment, and nothing said here is actually true. You're going to need to spend some substantial time to back up what you've said.

I did in another comment. This is not unsubstantiated hate, but using PHP in anger in many projects and being responsible for maintenance, automation, testing, modernizing, refactoring, solving performance issues and so on.

Re: Four ways to build web apps

#83
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…

For what it’s worth, there isn’t much to learn with cloudflare pages. You grant it Oauth access to a particular repo, it builds master and serves the output directory. Only thing you specify is the build command and the output directory. For example “hugo build”/“npm run build” and directory “out/“.

I use it for a few reasons. I like that it’s free and the hosting of the static content is at the edge. They also take care of some things automatically, like compressing the assets once at build time and serving them with the right headers.

I don’t think this is unique. I believe netlify and others have similar offerings. These providers are excellent for the use case of serving static content at low latency and low cost.

Re: Four ways to build web apps

#84
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…

That's the "Linux Server Singleton" pattern from the FA, isn't it? I find it surprising that it's in 3rd position. While SSG looks simple enough to merit the first position, going with the Cloudflare serverless proposition as the next step for beginners feels strange to me. I think you would be able to "graduate" to serverless-edge functions after you grok the traditional web client/server approach, not before.

Re: Four ways to build web apps

#85
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…

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 an extremely outdated stack: https://www.youtube.com/live/hWjT_OOBdOc?feature=share.

Re: Four ways to build web apps

#86
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…

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…

> The "underlying technologies" are constantly changing, unless you are using an extremely outdated stack

So will also constantly change their behaviour in the edge cases. Thank you for giving me another reason for not using that crap. I'll stick with my extremely outdated stack.

Re: Four ways to build web apps

#87
post #37
post #27

Earlier quoted context omitted.

> Plus it's a language that breaks backwards compatibility way too often Do you have examples of such compatibility breakages? I noticed Nextcloud and WordPress both seem to lag behind the last version of PHP a bit. But on the other hand I also see such thing in the Java World where people are stuck on Java 8 or 11, when backward compatibility is one of the strength of the language. I also have PHP scripts I wrote fo…

> 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 add the attribute for this class #[AllowDynamicProperties] .

> There was a somewhat recent article that talked about changes for a string template literals cleanup for the next major version that will break a whole bunch of code as well.

Next major version comes in several years until then you get deprecate warnings, if you can't fix problems that will occur in 2-3 years you should think about your software development skills.

> But what about many projects? What about transitive dependencies?

If you have many projects but no manpower to maintain it thats a bigger problem for the projects itself, e.g. security. And you can use phpunit combined with rector for many projects.

> PHP is moving fast and makes no excuses. It's simply not a language that prioritizes stability.

PHP is stable if you write good code and on the same level as nodejs or python.

> There are so many little gotchas and weird behaviors. Thats the reason for the upcoming breaking things, if php would stick at php 5 it would be dead.

Re: Four ways to build web apps

#88

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…

> The "underlying technologies" are constantly changing, unless you are using an extremely outdated stack So will also constantly change their behaviour in the edge cases. Thank you for giving me another reason for not using that crap. I'll stick with my extremely outdated stack.

Uh, what? Your product Saltcorn uses Webpack, React, Express, Docker and probably many more modern technologies. Those were just the ones I found looking at the repo for 5min.

Cloud and serverless platforms are similarly modern tech, except for deployment and hosting. Do you really think that e.g. AWS and Cloudflare "constantly change their behaviour in the edge cases"?

Re: Four ways to build web apps

#90
A particular application of #2 which works well as an extension of #3 is to have your workers implement a lightweight backend-for-frontend layer in between your frontend and more traditional API

This approach works pretty well when you have a pre-existing API and need to, say, minimize # of round trips to fetch data without wanting to couple your frontend(s)backend too tightly.

Post reply on HN