Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.


Bad coding is infinitely worse than a “bad” language.

I don’t know how many of you are musicians, but many people are surprised to find that the tone quality of a guitar has way more to do with the person playing it than the way it was built.


Bad languages, more than anything else, frustrate your expectations and encourage developers to do things that are difficult to maintain. Sure, a great basketball player can dribble with gloves on his hands, but he’s making the task harder on himself, and anyone who’s less than great is less likely to be able to hold on to the ball at all in that case.


A great player can make a Squire sound like a Studio Strat. Indeed. The type of strings make a difference too.


What do you mean "the type of strings"? In pretty much every programming language, String is one of the most fundamental types. There's no "different types of string".

(yes, this is a joke, a bad one at that. badum tish)


When I worked at Google, they had their own string type in place of std::string for various reasons.

Python has byte strings, Unicode strings, format strings, regular expression strings, and probably a few others!

Rust has str and String, depending on ownership.


honestly the difference between basic types like String in different contexts in different languages and dbs is enough to give me ptsd lol


> Rust has str and String, depending on ownership.

Why I hate Rust


C++ has string and string_view. Python has memoryview. It seems like a necessary evil if you don't want folk working in raw pointers?


In some languages it's two or more of the fundamental types. Obviously you haven't been using the big brained languages like Rust, Haskell, or Elixir.

(Also a bad joke.)


Obviously you haven't seen the Substring [1] type of Swift.

[1] https://developer.apple.com/documentation/swift/substring


But this is a slice. So technically a []char?


Not really. It's only a reference to the original string, a start index, and an end index. It doesn't store a second (partial) copy of the string.


there's String, string, std::string, and the satanic *char. Just like there's Slinky, Super Slinky, Extra Slinky, Heavy, and Pro. Nickel-wound (ref counted), steel wound (raw array), and classical nylon (a fucking pointer).


What are gut strings then? Indexed addressing?


lol, those would be raw pointers as well but at the asm level with registers. Joking aside, gut strings are extremely rare outside professionals. I’m not surprised to see it mentioned with this crowd. Cheers for tickling this music nerds interests.


Meh, "text" is where it's at. "varchar()" is so Oracle. :p


Surprising! Will look into


Can confirm. judyrecords is built on a near framework-less monolith in PHP + 2 search servers. Searches complete within 100 milliseconds and SRPs return in less than 15 milliseconds on average. Runs a trimmed down version of CodeIgniter 2 (released in 2012) updated to run on PHP 8.2. Still got the CI 2 profiler.

https://postimg.cc/TLbvvSzm

https://news.ycombinator.com/item?id=30481230


I wonder how many people did their own CodeIgniter updates. I’ve also almost completely transformed the thing, but the base is still CodeIgniter.


Curious, if you don't mind sharing, what site/app!?


Questions for every 100 dynamic websites. How many can truly outgrow PHP + sqlite + jquery ?


I get your point on PHP and jquery, but why sqlite over Postgres or MySQL? Is sqlite just easier to get set up?


Also entirely self-contained and doesn't require a separate daemon


Yes, I recently built a small PHP example project for educational purposes and I intentionally avoided all external dependencies for demonstrating how you would solve things without a framework or library. You can do almost everything you need with plain PHP without too much effort except a few exceptions that you shouldn't waste your time on, most of them are tooling however and not for the application itself, like unit testing, error tracking and logging, database migration, but for that you of course use libraries.


Sure, but framework-less PHP incentivizes poor architecture (hey we can do everything in 1 file to KISS x 100 endpoints = microservice hell). Requires an expert and disciplined engineer to execute well.


Sure you could, but it would take a much longer time and you'd miss lots of functionality. How long would it take you to build user registration / verification / password recovery / 2fa / sso / profile editing / spam registration prevention / etc. ? How long would it take instead to include some Laravel module which does all of that? If you're building a service with some purpose, do you really want to spend days writing the first option instead?


How many hours spent on battling Laravel to do what you want? How many hours spent on upgrading Laravel versions?

Framework solves a general problem, but we try to solve a specific problem, thus it will always be a mismatch, frameworks usually solves that with a combination of magic and opaque abstraction layers.

Frameworks works best for short running projects, long running projects tend to outgrow the framework.

Prefer libraries over frameworks.


That works for some things better then others. For example user management is hard to do as a library, because now you need to hook up all those actions / pass the data to them manually. Then make sure you handle all the headers correctly. Then handle the sessions/invalidation yourself. Potentially implement your custom authz as well because that's also happening throughout your app. There's still a lot of glue code that would be involved here - it may be worth trading it for the occasional Laravel upgrade.


Kind of depends what you’re building.


100%; we do that (see profile).


PDO databases are pretty nice.


Now that PHP has lost its massive deployment advantage, step up to Rails or Python.


Rails and python aren't a step up from PHP for webservers. Both are massive steps down in terms of real world performance. https://www.techempower.com/benchmarks/#section=data-r21

Personally if I was "stepping up" from PHP and wasn't going to use something powerful (or didn't need all that power) I'd be stepping up into javascript and nextjs and stuff like that.


But PHP is blazing fast compared to either of those (hot code ready to accept traffic in all scenarios so we can ignore warm-up times)


I hear about Python all the time. Rarely hear about Rails now. I think the world picked one over the other.


I was at RailsConf 2022 and it was packed, even considering the strict covid rules. There were lots of people there from teams transitioning from React+Go to Rails.


GitHub & Shopify both run substantially on Rails.




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

Search: