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

I would say the even bigger problem is that the pieces you stitch together to make a web app will rot rather quickly.

He mentions supabase and vercel. It will only take so long, until the supabase code or the vercel service will have a breaking change. And those breaking changes add up throughout the stack. Making the cost of running a web app much higher than it would have to be.



This leads to an obvious question: why not do it old-school?

What's the actual value-add of all this stuff?

People have been pushing back against JS frameworks with vanilla, what about vanilla-everything-else?


Because eventually you end up rewriting a more brittle version of an established framework. Plus someone else may have to maintain it. Working out how your vanilla code works is worse than learning a framework because there's no help.

I lived this with an app made in 2012 that was all custom JS.

Plus how far do you want to take it? Write your own security modules? Create your own anti SQL injection code? The benefit of frameworks is you get free hardened code tested by millions.

But yes, I get it, gluing together Frameworks is depressing too. It just isn't fun.


JavaScript, HTML, and CSS have changed a lot since 2012.

I think the problem is folks tend to think like engineers with all their widgets (e.g desktop development in the browser). Even Microsoft is going full TypeScript mode.

Web development is DESIGN first. Think of it like a design project and suddenly the entire workflow changes.

The CSS spec today makes all this stuff super easy people just don’t spend the time actually learning.

In my opinion the Laravel and Rails developers get this right.


It also leads to the irony that eventually, you’ll build libraries that then have breaking changes and you’re managing both the library and all its versions and the applications that use it.


I think it is a balance. My current view on this is:

For the frontend, everything but plain HTML, CSS, JS is too much.

For the backend, an opinionated framework like Django is too much.

Even a less opinionated framework like Flask is too much.

Using modules that Flask uses - like Jinja templates - is the right choice for me. This way, I don't have the overhead of a full framework, but also don't have to write basics like a template engine myself. And I have the benefit that other developers (and AI) easily understand my code, as it has many similarities to a Flask project.

So instead of going for Flask when I need templates, all I do is

    import jinja2

    env = jinja2.Environment(
        loader=jinja2.FileSystemLoader('templates'),
        autoescape=jinja2.select_autoescape(['html', 'xml'])
    )

    def template_data(template, data):
        tmpl = env.from_string(template)
        return tmpl.render(data)
And I have a function I can use to template my data.




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

Search: