131–140 of 292 posts
I feel your pain. My career happiness peaked around 2014 or 2015, when I was writing Rails monoliths. I felt like I could focus 100% of my energy on business logic since the framework was so opinionated and the stack was simple. Things went rapidly downhill after that, once microservices, SPAs, node.js, NoSQL, and serverless computing started becoming popular. Everything just felt like a step backward. Microservices…
Spot on. Rails just let you get shit done. All we needed was a Rails for Node.js.
>I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore I agree, but the only path forward is to change the specifications for HTML/CSS/JavaScript. As an industry we need to accept that these technologies get used to build web pages as well as software and adjust. This will remove a ton of the tooling. I think there are 3 basic things we could do to solve th…
Not sure what this means exactly
> 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier.
Something like AlpineJS built-in?
> 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.
ARIA roles kind of already do this.
When you return to vanilla JS you have the freedom to dramatically reduce your code size and increase performance.
See this comment upvoted 27 times: https://news.ycombinator.com/item?id=32914694
Earlier quoted context omitted.
But you can already write amazingly complex queries in sql, and structure them as objects directly using pdo. If there are hundreds of developers working against the same codebase then that codebase is too large. If you need to query hundreds of tables in one go you need to consider denormalisation or using a document storage.
The ORM code will be 10x smaller than the generated SQL, especially for structured data and composing queries. Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs. I didn't even get into entity tracking which is a whole othe…
Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.
I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.
Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.
Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.
This stems from the fact that many in web dev are not really engineers. There’s a lot of reinventing the wheel and cult like following of various tech influencers. Instead of extending existing libraries people just fork repositories, add minor changes, and advertise them as new. A lot of architectural patterns are just a soup of concepts thrown around without proper planning or understanding of dry or solid.
>I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore I agree, but the only path forward is to change the specifications for HTML/CSS/JavaScript. As an industry we need to accept that these technologies get used to build web pages as well as software and adjust. This will remove a ton of the tooling. I think there are 3 basic things we could do to solve th…
Number 3 is the ARIA spec right? You should be using that already if you’re writing accessible applications. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Like take this for example: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Did we just give up on using semantic elements? People barely know how to write regular HTML anymore, and the ARIA spec is confusing. I'm glad it exists, but to me it fits into the same category as "Web components" - a bad idea that isn't widely adopted because it sucks.
Earlier quoted context omitted.
The ORM code will be 10x smaller than the generated SQL, especially for structured data and composing queries. Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs. I didn't even get into entity tracking which is a whole othe…
Can you show me an example of the 10x less code?
var results = db.myTable
.where(x => x.value > 6)
.where(mySpecialConditionalLogicFunction)
.select(x => {
thing = x.relation.relation.relation.value,
thingList2 = x.relation.relations
.groupby(y => y.value)
.select(g => g.count)
.orderby(y => y.value)
.take(5),
thing3 = x.relations
.where(z => z.relation1.value z.relation.value)
.max(),
thing4 = myReusableSelectDTOfunction,
etc..