On one hand I agree, one should approach issues as they come, but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies.
Even admitting one wants to go with bare bone web components authoring and maintaining them is expensive, requires lit or something.
Thus, what's the solution? Some sort of templating? Again, you're bringing on dependencies.
The problem isn't the tool or the dependency—it's the developer's temptation to over-engineer. We grab a framework because we lack the discipline to keep something simple. Is self-control in coding just a lost art now?
Not for me. But I am in the unique situation of sometimes having to spin up 12 projects a week only to come back to two of them 5 weeks later unpredictably.
This means I treat every project like a letter to my future self that needs to be 100% self explainatory and work even if the environment around the project changed. And this means as few moving parts as possible.
For me it's more like I bounce back and forth avoiding the pains from whatever the last project was using. Same with front-end frameworks vs vanilla JS etc.
For example, you work with ORMs and then you see all the problems with them as you maintain the project, so on your next app you create an app that is raw SQL. Then after maintaining that for awhile you start to see all the pitfalls of that approach and why people created ORMs in the first place. Then someone mentions the latest and greatest ORM that promises to be better this time and you use it, saving you from raw SQL you'd jumped to last time....ad infinitum.
We are good at not even getting that far. Have a platform team and spent a month setting up CI, github repo, onboarding, writing terraform and stuff and not even get around to doing a web site in the first place!
I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Where's the engineering?
I see it like this: with every line of code I write, I make an assumption about the final outcome. Making that assumption means that other possible outcomes aren’t possible.
The more code, the more assumptions.
Until eventually a fixed and very fragile outcome is reached. The so-called first release. Everything is well balanced and based on assumptions I have made based on the information I have been given along the way.
Turns out though my first assumption was wrong.
Now the engineering comes in. Make it look like my first assumption wasn’t wrong, but it was falsely communicated to me. Blame others for my own failings. It called human engineering and it’s great fun.
I host my blog using plain HTML and I have a compile step - a Python script that converts markdown to HTML, which minimizes the energy I spend on... wrapping everything in HTML tags?
The post feels more like a rant, like the author has a beef with some sort of a project or a client. Even a static blog is easier to manage with tools rather than writing it in pure HTML.
I have my personal website running on svelte. When I decided to have a blog, I quickly came up with a solution to use markdown to html converter and just added a couple of routes to existing setup and voila, the blog is up and running. I don't care that it depends on several packages. Publishing a post takes just a push to my repo.
I have a personal web app that I wrote in react 16 with babel set up by createReactApp directly from the react docs. it’s been stuck with a list of features I want to add in my spare time but all 3 of those have bitrotted out so that in my minor spare time over the last 2 years or so, instead of being able to add some feature, I spend 2 to 3 hours trying to update it to the latest, fail, and no progress is made.
my latest attempt was to see if one of the LLMs could do it. nope.
I’ve thought about starting from scratch but don’t have the time
I think you will have a much better time if you generate a new, empty React project with Vite and just drop your existing components into it. I almost suggested not updating at all and keeping your dependencies as they are, but createReactApp was too much of a bloated mess even in its heyday.
No it doesn’t. This post reads like someone tired of working in an industry run by extremely insecure people that just need a little help at absolutely every step of the journey. Other industries call that unqualified.
I was expecting more like, "translate it into many languages your website users won't keep updating and give them access to edit your site's design freely as they see fit..."
at the very least, if you are really writing lots of INSERTs by hand I bet you are either not quoting properly or you are writing queries with 15 placeholders and someday you'll put one in the wrong place.
ORMs and related toolkits have come a long way since they were called the "Vietnam of Computer Science". I am a big fan of JooQ in Java
Note both of these support both an object <-> SQL mapper (usually with generated objects) that covers the case of my code sample above, and a DSL for SQL inside the host language which is delightful if you want to do code generation to make query builders and stuff like that. I work on a very complex search interface which builds out joins, subqueries, recursive CTEs, you name it, and the code is pretty easy to maintain.
Object-relational mapping (ORM) is a key concept in the field of Database Management Systems (DBMS), addressing the bridge between the object-oriented programming approach and relational databases. ORM is critical in data interaction simplification, code optimization, and smooth blending of applications and databases. The purpose of this article is to explain ORM, covering its basic principles, benefits, and importance in modern software development.
The only time I've seen migrations randomly fail was when others were manually-creating views that prevented modifications to tables. Using the migrations yourself for local dev environments is a good mitigation, except for that.
Prisma has shown me that anything is possible with an ORM. I think they may have changed this now, but at least within the last year, distincts were done IN MEMORY.
They had a reason, an I'm sure it had some merit, but we found this out while tracking down an OOM. On the bright side, my co worker and I got a good joke to bring up on occasion out of it.
Weeks of handwriting SQL queries can save you hours of profiling and adding query hints.
If you want a maintainable system enforce that everything goes through the ORM. Migrations autogenerated from the ORM classes - have a check that the ORM representation and the deployed schema are in sync as part of your build. Block direct SQL access methods in your linter. Do that and maintainability is a breeze.
At the end of day its a trade off. It would be an exception if anyone can remember their own code/customization after 3 months. ORMs or frameworks are more or less conventions which are easier to remember cause you iterate on them multiple times. They are bloated for a good reason, to be able to server much larger population than specific use cases and yes that does brings its own problems.
Pro tip to get ahead and get all this and more for free: use nextjs and prisma. Guaranteed pain and misery; because they move fast and break things, you can look forward to weekly vunerabilities and breaking changes!
Depends on the context. I came from a ruby, nodejs, java, gawk background to Erlang (not elixir).
The first question I posed to the Erlang community was exactly that: what are the build tools, what are the unit testing frameworks and how is a project setup.
Not because I didn’t know what these tool/concepts did but because I wanted to know what is the state of the art in Erlang tooling.
I have my sea legs, including the wooden one, but just not yet in Erlang. Why Erlang? Because it’s completely different to everything else!
Isn’t using something like the Google closure compiler considered a good thing? This post seems to suggest tools like that in your pipeline should be avoided.
Honestly, I don't agree with the mindset that frameworks and build steps should be avoided at all costs. Of course, you shouldn't pull in unnecessary NPM dependencies—that's just common sense. But using a compilation step or a framework can save you a lot of time and effort. For example, if you use a framework like Astro, you get a lot of functionality out of the box. If you try to do everything by hand, you end up copy-pasting the same header and footer into every HTML file. Then, when you want to update something, you have to manually change every single page. Trust me I been in that hell many years ago.
Frameworks solve these problems efficiently. Sure, some frameworks can be overly complex (I'm personally not a fan of Next.js), but that's a problem with the specific framework, not the idea of using a framework at all. But many frameworks make things much simpler and let you avoid reinventing the wheel. You could write your own scripts (in practice a mini-framework) but eventually you'll hit limitations, especially as your project grows or you start working with others. At that point, you'll probably end up switching to an established framework anyway.
If you're already using something like PHP with server-side rendering and templates, that's fine too—you've just chosen a different kind of framework (it is still some kind of framework. Just not a client-side one). I just don't buy into the idea that avoiding all build steps and frameworks is somehow more "pure." It feels a bit like a hipster take: "I'm going to write everything from scratch and avoid all tools just to show that I can."
If you took this seriously you'd write everything in assembly to avoid dependancy on a language that will one day break. Picking a set of dependancies that are built on well reasoned, clean abstractions is a far better apporach than rolling your own solution to every problem you encounter.
68 comments
[ 4.2 ms ] story [ 76.7 ms ] threadEven admitting one wants to go with bare bone web components authoring and maintaining them is expensive, requires lit or something.
Thus, what's the solution? Some sort of templating? Again, you're bringing on dependencies.
This means I treat every project like a letter to my future self that needs to be 100% self explainatory and work even if the environment around the project changed. And this means as few moving parts as possible.
For example, you work with ORMs and then you see all the problems with them as you maintain the project, so on your next app you create an app that is raw SQL. Then after maintaining that for awhile you start to see all the pitfalls of that approach and why people created ORMs in the first place. Then someone mentions the latest and greatest ORM that promises to be better this time and you use it, saving you from raw SQL you'd jumped to last time....ad infinitum.
Finally we have our web 3.0!
...
The more code, the more assumptions.
Until eventually a fixed and very fragile outcome is reached. The so-called first release. Everything is well balanced and based on assumptions I have made based on the information I have been given along the way.
Turns out though my first assumption was wrong.
Now the engineering comes in. Make it look like my first assumption wasn’t wrong, but it was falsely communicated to me. Blame others for my own failings. It called human engineering and it’s great fun.
most of it from my observation is people justifying their own roles, where the real value they bring is arguable imo
I have my personal website running on svelte. When I decided to have a blog, I quickly came up with a solution to use markdown to html converter and just added a couple of routes to existing setup and voila, the blog is up and running. I don't care that it depends on several packages. Publishing a post takes just a push to my repo.
my latest attempt was to see if one of the LLMs could do it. nope.
I’ve thought about starting from scratch but don’t have the time
Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works.
ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.
ORMs and related toolkits have come a long way since they were called the "Vietnam of Computer Science". I am a big fan of JooQ in Java
https://www.jooq.org/
and SQLAlchemy in Python
https://www.sqlalchemy.org/
Note both of these support both an object <-> SQL mapper (usually with generated objects) that covers the case of my code sample above, and a DSL for SQL inside the host language which is delightful if you want to do code generation to make query builders and stuff like that. I work on a very complex search interface which builds out joins, subqueries, recursive CTEs, you name it, and the code is pretty easy to maintain.
Inspect the actual SQL query generated, and if needed modify ORM code or write a SQL query from scratch.
Object-relational mapping (ORM) is a key concept in the field of Database Management Systems (DBMS), addressing the bridge between the object-oriented programming approach and relational databases. ORM is critical in data interaction simplification, code optimization, and smooth blending of applications and databases. The purpose of this article is to explain ORM, covering its basic principles, benefits, and importance in modern software development.
They had a reason, an I'm sure it had some merit, but we found this out while tracking down an OOM. On the bright side, my co worker and I got a good joke to bring up on occasion out of it.
If you want a maintainable system enforce that everything goes through the ORM. Migrations autogenerated from the ORM classes - have a check that the ORM representation and the deployed schema are in sync as part of your build. Block direct SQL access methods in your linter. Do that and maintainability is a breeze.
Let's you do what you want here and now and then pay dearly for it afterwards :-)
In the hand of a good team, ORMs and migrations are an unbeatable productivity boost.
Django is best in class.
It's like asking "I'm new to driving, what brand of nitros should I be using"
Nah dude, get your sea legs first
The first question I posed to the Erlang community was exactly that: what are the build tools, what are the unit testing frameworks and how is a project setup.
Not because I didn’t know what these tool/concepts did but because I wanted to know what is the state of the art in Erlang tooling.
I have my sea legs, including the wooden one, but just not yet in Erlang. Why Erlang? Because it’s completely different to everything else!
Frameworks solve these problems efficiently. Sure, some frameworks can be overly complex (I'm personally not a fan of Next.js), but that's a problem with the specific framework, not the idea of using a framework at all. But many frameworks make things much simpler and let you avoid reinventing the wheel. You could write your own scripts (in practice a mini-framework) but eventually you'll hit limitations, especially as your project grows or you start working with others. At that point, you'll probably end up switching to an established framework anyway.
If you're already using something like PHP with server-side rendering and templates, that's fine too—you've just chosen a different kind of framework (it is still some kind of framework. Just not a client-side one). I just don't buy into the idea that avoiding all build steps and frameworks is somehow more "pure." It feels a bit like a hipster take: "I'm going to write everything from scratch and avoid all tools just to show that I can."
And from the linked post on the same website.
> if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs.
Very (very, very) few large projects use plain JS (instead of TS) these days. Let's stop acting like all these people don't know what they're doing.
This post is probably applicable to selected tiny and small projects. And for some of those, it may be better if there was no JS at all.