Hacker News Reader

You want to build your own ORM, sockets, SPA, Queue handler, Scheduler, Container, Auth etc? That seems like a massive waste reinventing the wheel

Is it reinventing the wheel, or is it making a new wheel that exactly fits the design requirements?

A framework with all the bells and whistles isn't that great when I want a framework with a piano.

If you're making a wheel that exactly fits the design requirements you'll have a hard time when does requirements inevitably changes. Making rigid designs instead of plyable is a terrible idea if you're working with web

Nah. Changing your own code is easy. I dare say it also might be the most fun aspect of programming.

Changing someone else's (meaning an external third-party) code can be as easy and fun with the right tooling, but the tooling around supporting that tends to be really bad in most ecosystems. There is a common assumption found around dependencies that their code is theirs and shouldn't be touched except by the hand of the original author.

Not impossible to overcome, of course, but with enough friction that you have to seriously consider if it beats simply writing your own. A little copying is better than a little dependency, but a where there is a lot of copying...

ORM: don't need, I can write SQL. Prepared statements sufficient to prevent SQL injection. Both PHP and Go have good database abstraction libraries.

Sockets: Don't use but if I did I wouldn't need a framework.

SPA: I don't write apps that way. Server-side, which is why we're talking specifically about PHP and Go.

Queue handler, scheduler: Can easily do in the database or with Redis.

Container: What? Do you mean something like Docker? That has nothing to do with the web app development language or framework.

Auth: OAuth2 and SAML not a big deal, but maybe worth introducing a dependency depending on requirements. Regular username/password/MFA auth easy to implement, certainly no framework needed for that.

Likewise with routing, "MVC" structure, etc. Frameworks can save some time beginning but eventually you have to debug them, or run into limitations to work around. And one day the framework gets updated and you have to deal with breaking changes.

That stuff you find easy isnt easy for developers who use frameworks.

Because they only know how to program with a framework. Take off the training wheels and learn the language and libraries.

I know several languages, and in none of them is it preferable to ignore using the correct tooling.

Right, that’s my point. We only disagree about what “correct tooling” means. Since PHP and Go have everything needed I prefer not adding more abstractions and dependencies, for less code, fewer black boxes, and fewer external dependencies.

Programmers comfortable writing in PHP and Go with their comprehensive standard libraries can also work with frameworks if necessary, but those who can’t get stuck as Laravel developers, baffled by the much larger number of projects and existing code that doesn’t use their “correct tooling.”

You're more productive when you don't have to reinvent the wheel, as I already stated.

You know of a way to quantify and measure “productivity” of programmers? Of code?

Programmers make claims about productivity and throw the word around, like we all understand what it means.

I highly doubt the technical debt and inevitable vulnerabilities weigh up any perceived time saved. Also when you use a framework like laravel you're sort of forced into building applications in similar styles making it easier for other developers to cooperate instead of having to figure out some weird homemade framework.

If you know the language and libraries you can figure out any framework code, whether Laravel or some "weird homemade" thing. If you only know a framework then you have limited your options and job opportunities. And you stay in the shallow end with all of the other semi-skilled programmers.

> semi-skilled programmers

Elitism is not welcome here. Are you a "semi-skilled" programmer if you are a web dev and don't know C++ and pointers? Are you a "semi-skilled" programmer if you are an embedded developer and don't know JavaScript?

> If you only know a framework

This makes the assumption that by knowing a framework, you will be unable to learn how to use the language at large. This is not necessarily true - a person who has learned Laravel will probably figure out CakePHP or CodeIgniter in a weekend. They just prefer Laravel for their jobs, and that's a legitimate choice. They've also made the decision that, even though Laravel makes breaking changes over time, the productivity boosts are greater than the downtime.

Which is also a legitimate choice when Laravel upgrades have been automated for years for $29. https://laravelshift.com/

Semi-skilled means knowing a framework to some degree, but struggling with the language the framework is written in. Nothing to do with C++ or embedded -- I clearly contrasted Laravel et al. with PHP, and Goravel with Go.

Anyone who prefers Laravel or any other framework can use it. I wrote that neither PHP nor Go need a framework because they have everything necessary to implement web applications.

If you don't want to get laid off because everyone and their mother, and now LLMs, can copy-paste Laravel sample code for $15/hr (see Upwork, for example) improve your skills. If you want to have more opportunities in the programming job market expand beyond frameworks and learn the underlying languages and libraries.

At this point you’re just making stuff up.

https://www.upwork.com/hire/laravel-developer/us/

You can figure it out, but likely with a lot of questions. Why did you do it this way vs that way? What were you thinking here? Why does it appear this was "hacked" in? Bring in a new developer that doesn't completely understand your thought process and the code just gets worse and worse over time. I think you're oversimplifying.

You should absolutely learn the language, but reinventing the wheel on every project is not the way. And if you're not reinventing the wheel, then all you've done is create your own framework that only you know the ins and outs of. Sounds more like you're looking out for your own job security than anything.

laravel has too much magic that really, really, really gets in the way as soon as you get to where things become interesting. too much magic. definitely not clean. and architecture wise… well… i have just never seen a project with controllers that is well designed. and if you even advocate to use a framework with bad design choices because many others do the same… it’s still bad design & it will come back and bite you.

you should always prefer a codebase optimized for the business, the purpose & the people who work on it everyday. if that requires more time to grasp it for newcomers, perfect. people make that weird argument all the time for going with a framework due to popularity & common ground. that’s so absurd. optimizing for onboarding time & quickest graspability, when that factor is usually irrelevant in most projects.

also, the best thing about modern PHP are the PSRs. They are not appreciated enough. Stick with them. Don’t be clever. Don’t use magic. Be explicit. Don’t don’t repeat yourself. Write code like your mom reads it. Et voilá, your homemade framework is gonna be just fine.

Especially compared to projects built around frameworks by devs who very rarely if ever look at the source code of the magic they use. debugging and fixing those issues took more of my lifetime than the hours i’ve put into updating my personal web app framework (latenight-php).

Also: Choosing which tire you want doesn’t equal reinventing it. And also: thank good people reinvented the wheel so many times… imagine EVs on rolling stones or wooden wheels.

Writing SQL is a miserable slog because it isn’t composable. I’ll take an ORM over raw SQL any day.

SQL is a declarative language for working with relational databases. The concept of composability doesn’t apply.

SQL does support code reuse and building layers of abstractions. If you only use SQL through an ORM you won’t get to use things like CTEs and views and user-defined functions, because ORMs by definition deform the relational model and SQL to fit OOP.

In 40+ years programming SQL expertise has paid the bills and kept me employed more reliably than any other language or tool I have mastered.

> SQL is a declarative language for working with relational databases.

No. First and foremost, SQL is for tablational databases. A relation and a table are similar, to be fair, but have some key differences:

- A relation is an unordered set of tuples. SQL opts for an ordered list of tuples (a table) instead.

- A relation has no concept of NULL. A table does.

- The implications of those differences also bring a whole bunch of other differences that further divide SQL from the relational model.

SQL's only association to relational databases is in its name, being originally SEQUEL which was a play on QUEL – a language actually for relational databases that was a direct adaptation of Alpha from Codd's original paper.

> The concept of composability doesn’t apply.

Of course it does. Why wouldn't it apply? Datalog, a declarative language for querying data, is in many ways similar to SQL and it supports composition just fine. Many of the compile-to-SQL languages also support composition just fine. SQL could be composable. It should be composable. It just, because it still desperately clings to its COBOL-era glory days, is too afraid to add support.

> In 40+ years programming SQL

40+ years of working with SQL and you are still this confused about it...?

Nothing you wrote has anything to do with ORMs, the actual point of this thread.

The shortcomings of SQL with respect to a pure relational model are well-known. For all practical purposes we have SQL. Almost everyone using a popular relational database engine — those that might have ORM support — uses SQL. The history of SQL and niche alternatives, while interesting, don’t have anything to do with using an ORM vs writing SQL.

I’m not confused about relational vs SQL. I just didn’t think the pedantry would add to the discussion.

Pointing out that SQL doesn’t implement the relational model correctly seems like pointing out that C++ doesn’t implement object oriented programming as Alan Kay defined it. True, but C++ got a lot of adoption and Smalltalk did not. Pointing out the OO shortcomings of C++ don’t help with using the language.

> Nothing you wrote has anything to do with ORMs, the actual point of this thread.

Incorrect again. ORMs[1] are within the set of compile-to-SQL languages. They were very much spoken to. They are also not magic, just other languages that ultimately express the exact same thing (and have to, since SQL is the compiler target!). But, notably, support composition –– Which means that SQL can support composition, and it would be quite relevant for it to.

Furthermore, you remain confused as the whole reason we're talking about composition in the first place is because it is the reason why people are reaching for ORMs[1]. If SQL supported composition, they wouldn't need to. They could use SQL itself, happily. It is not some kind of general aversion to SQL. The problem is that the SQL language lacks functionality sorrily needed for real-world use, so people feel a strong need to reach for a better language that does provide.

Which is unfortunate, as using SQL itself directly without obscuring behind another language brings many benefits. But until it adds native composition support, you're in for a world of hurt in any kind of practical setting where there is more than one or two queries.

> Pointing out that SQL doesn’t implement the relational model correctly

It is not that it doesn't implement the relational model correctly. It doesn't try to implement the relational model at all. It chooses the tablational model instead. Which is fine. Arguably tablational is better than relational, so to call it relational is nonsensical and perhaps even a little demeaning. What leads you to such nonsense after 40+ years of exposure?

[1] Yes, technically the discussion has been about what are more normally called query builders, not ORM. If you really want to be pedantic, ORM is only concerned with translation between collection of sets and trees and has nothing to do with query expression, but this isn't about pedantry, it's about your poor understanding of SQL and how that has lead you to incorrect conclusions about composition.

An opportunity to engage in a useful discussion derailed by ad hominem and conflating things.

SQL and the relational model (two different things) predate OOP and the need for ORMs (object-relational mappers) by one to two decades. It was the widespread adoption of Java — everything an object — in the mid-1990s that led to ORMs, at a time when various commercial “relational” databases already dominated data management. Microsoft’s Active Record and then Ruby/Rails, among others, perpetuated the use of ORMs. Most programmers who entered the field after 2000 learned ORMs and their associated query builders before learning SQL or relational database concepts, if they ever learned those things at all.

ORMs can make some things simpler, including composing queries, but as you noted that means SQL can do the same thing. Some more recent additions to SQL, such as CTEs, and features such as named views and subqueries that ORMs discourage, make SQL more composable. If we could write in predicate calculus we wouldn’t have to deal with SQL’s shortcomings, but that battle got lost in the 1970s and now we have decades and billions of lines of SQL (most of it not generated by ORMs) that won’t go away.

Going back to my original point, way up this thread… PHP and Go, specifically, do not need add-in ORMs because the languages have built in support for mapping query results to native objects/structs. If someone uses a query builder with those languages most likely they do so out of habit, or because they can’t or don’t want to write SQL. But PHP and Go do not need an ORM or query builder, just like they don’t need add-on HTML templating.

> A relation is an unordered set of tuples. SQL opts for an ordered list of tuples (a table) instead.

SQL the language does not require or describe ordering in tables — that happens as a side-effect of the physical implementation. No one should rely on ordering of table rows.

> A relation has no concept of NULL. A table does.

Null values occur in relations as soon as you write outer joins. All modern RDBMSs also allow defining nullable columns in base tables, and SQL allows/supports NULLs in that context, but with a little work one can eliminate nullable columns in base tables (we’ve already left pure relational land talking about base tables). But you cannot eliminate nulls from query results if you use outer joins.

None of those sound like frameworks, just plain libraries that, if integrated properly, are easily swapped out if they become a liability later.

Both PHP and Go already provide the framework as part of the standard installation. Everything else you need should be pluggable libraries. If developers are pulling shenanigans with those libraries to try and make them frameworks, beware.

Speed? Familiarity for other developers? I don't think those should be underestimated, particularly for solo devs and small companies just getting started.

Frameworks do give some early traction, as I mentioned. And lots of PHP devs really only know Laravel, a shame because eventually they will have to debug it or work around limitations.

I meant to make the point that frameworks come with a cost, which may get deferred for a while. Maybe that doesn’t matter. For PHP and Go specifically I don’t see the point since the languages have everything you need out of the box.

Sorry, I'm going to have to disagree. For most projects, you have to draw the line somewhere, so why pick a point of abstraction where you're likely not to change anything the MVC framework provides? It sounds like you've been bitten by some opinionated frameworks and maintenance pita, also wanting to know as much as possible what code is doing? However, for most web projects it's just not realistic to recode routers, middleware, auth? Most good frameworks provide a solution with materials that are ready to use, quality controlled by hundreds of people, and many thousands of hours.

Bootstrap 3 is a perfect example of why you wouldn't pick a UI framework, if you have demands for pixel-perfect design or custom animations you'll be immediately battling the framework in those areas. That doesn't mean all frameworks are bad, like graphic designers rarely use MS Paint and draw each pixel because it would take forever, i.e. you're not being an efficient engineer. If you're building a house, why make bricks yourself, chop trees for wood, or forge custom roof tiles?

To me, PHP / Go are themselves abstractions of an enormous amount of complexity, so why stop there, why not go as high as you can imho, higher = less code?

This is also another winning point of the framework: Frameworks save you time, and allow you to write less code. By writing less code, it is much easier to understand what your program is doing, and change it as requirements change.

When you work without a framework, you invent your own framework. It won't be as well thought through - guaranteed. When changes come in, the sheer amount of code means mistakes will be made and your code will slowly turn into spaghetti. If this is a custom FFMPeg conversion service - totally worth it. If it's CRUD, like how 90% of apps are CRUD, then it's probably a mistake.

As I told another programmer, using a framework doesn't mean you are a "semi-skilled" programmer (what elitism). It means you know you aren't special, you aren't smarter than other programmers, you know your own limitations, and know that using a framework other people understand (and keeping the amount of code to a minimum) is the best for your company and the project.

Try to understand the difference between not using a framework and inventing your own framework. No one in this thread advocated writing their own framework. I originally pointed out that PHP and Go include everything you need to write web applications in the language and standard libraries. They don't need a framework at all.

Yes, frameworks have some advantages as you listed. And they have disadvantages. Before doing the same thing over again with Laravel, or Goravel (the original topic of this thread) think hard about the trade-offs. Frameworks impose limitations, on both the application and the programmer.

Having worked on several projects in the past where the clients had either their own frameworks, and or proprietary languages I think familiarity is highly overrated in most (but not all cases). If you're building something trivial or basically throwaway then familiarity does play a role, but if it's non-trivial all the other costs outweigh any initial learning.

In my experience, SvelteKit is an exception to this rule. It really gives you the absolute bare minimum for the backed.