3 ms·

As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework: JavaScript is eventuall

As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework: JavaScript is eventually needed for any non-trivial app. JS without a build system/dependency management is a maintenance nightmare. JS without linting, TypeScript, module syntax and unit tests is a maintenance nightmare. Reuse of components is much easier and more testable with framework abstractions (compare a react/vue/svelte component to e.g. a laravel blade component). Strict separation of CSS, HTML and JS means things like class names drift. With a JS build system you can easily introduce tooling to combat this (auto-removal of unused styles, enforcing that all classes are used, linting for CSS code, etc). I just can't imagine building an app of more than a few thousand lines without a framework and frontend build tooling. I would end up needing to reinvent these tools myself to ensure code quality as the project grows. I'm not saying it's impossible to add these features into, say, a Django or Rails app, just that it's more work for a worse outcome.

thex10 3y ago
Many apps with moderate interactivity don’t need thousands of lines of JavaScript. And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such.
- muspimerol 3y ago
  > Many apps with moderate interactivity don’t need thousands of lines of JavaScript. I mean, maybe? Depends what you mean by "many". I'm certainly not advocating for adding JS & frameworks where interactivity is not needed, and as I mentioned, for less than a couple thousand lines, an SPA framework is almost definitely the wrong choice. But my experience in the last 10 years is that very few projects do not grow to the point of requiring quite a bit of JS for interactivity. Async requests, complex client-side form validation, comboboxes, dynamic modals/content previews, showing/hiding long content, 3rd party integrations... these sorts of requirements are in nearly every app these days. And the HTML/CSS only solutions are just not good enough yet, unfortunately. > And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such. Sure, but at this point, why are you avoiding introducing a JS framework? All that stuff is built in to most JS frameworks (but not backend frameworks). You could piece it together yourself... but for what benefit?

thex10 3y ago

Many apps with moderate interactivity don’t need thousands of lines of JavaScript. And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such.

muspimerol 3y ago
> Many apps with moderate interactivity don’t need thousands of lines of JavaScript. I mean, maybe? Depends what you mean by "many". I'm certainly not advocating for adding JS & frameworks where interactivity is not needed, and as I mentioned, for less than a couple thousand lines, an SPA framework is almost definitely the wrong choice. But my experience in the last 10 years is that very few projects do not grow to the point of requiring quite a bit of JS for interactivity. Async requests, complex client-side form validation, comboboxes, dynamic modals/content previews, showing/hiding long content, 3rd party integrations... these sorts of requirements are in nearly every app these days. And the HTML/CSS only solutions are just not good enough yet, unfortunately. > And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such. Sure, but at this point, why are you avoiding introducing a JS framework? All that stuff is built in to most JS frameworks (but not backend frameworks). You could piece it together yourself... but for what benefit?