Hacker News Reader

> Anyway, after about a day of doing the above I'm ready to program

And you know all of this. I, as a lowly backend dev + operations guy have tried to get into these stacks for a few times over the years and honestly, in many cases, I just failed. Or I got some tool chain going, but I felt like I had zero control over it and the slightest wobble of anything would just cause it to fall apart and I wouldn't be able to fix it.

I dunno, I just recently made the decision to consider most if not all of this JS stack as a blocker for what I want to do. Then I setup some flask application with jinja2-based server side rendering like back in the day. It doesn't look as modern or shiny (and currently rather ugly due to a lack of any CSS, but I've been told I should stick with pure modern CSS, so let's do that :) ). But it is a blast how much functionality you can get done quickly in that stack.

Fwiw, I think a lot of that is familiarity. I'm trying to create a Python backend right now, and it's something I've done before, but still every time it feels like a pain - what are the best practices for dependencies now and how do I install everything, how do I set up a server, how do I get it to work with SSL/TLS, where should I be putting my assets and my templates, how do I get them to link together, how do I get this into a container, etc, etc.

But I think that's just a familiarity thing. I know what I'm doing when it comes to frontend development, so it's not an issue to get a new project off the ground, but backend development - and particularly backend development in Python - is something that I only touch occasionally, and therefore have to futz around with every time.

I would agree partially. My python experience wasn't even as actual web applications until 3-4 weeks ago and mostly used python for scripting and such. But sure, this means that I know things like dependency management, deployment and similar topics around the language.

But this is also where I'd disagree partially: The backend world moves a lot slower and feels a lot more settled to me. Sure, I'm relying on experiences as a sysadmin and a python developer, but: (i) If you need a VPS, you still have the 4-5 choices you had for years, Hetzner (Cloud by now), Digital Ocean, Linode, AWS Free Tier. (ii) SSL-Fronting had the same answer for I think 10 - 15 years by now. Front it with an Apache or Nginx proxy with Lets Encrypt. LE was the biggest change there. (iii) The ancient good old python3 -m venv + activate + pip is still very much valid and recommended. I'm currently trying out poetry, but even that uses venvs and pip in the background. (iv) And then assets, templates, and even production deployment guidelines are mentioned e.g. in the wonderful quickstart of Flask [1]. And there are several really solid and stable development tools around there for linting, formatting, typecheckind. VSCode for example recommends them quickly.

Most of this has been stable for years while being carefully improved. On a similar page, I haven't been working as an active java developer in like 6 years. I can still readily understand pretty much all java builds in the company because the tooling is just stable.

The 2-3 tries I had to get into the JS ecosystem meant I had to reset most of my knowledge because all of the frameworks, toolings had been deprecated, replaced, rewritten and anything else.

1: https://flask.palletsprojects.com/en/2.3.x/quickstart/

I'm not sure the backend world moves all that more slowly, it's just if you're in it, you know which new parts to accept, and which to ignore. To take Python as an example, my impression as a newcomer is that Flask is pretty outdated at this point — why not use async/await and FastAPI instead? And are you sure you should be using pip/venv/requirements.txt still? Poetry and PDM both have lockfiles — surely that's better?* And yes, there's lots of recommendations for linting and formatting, but which should I actually be using? Is Black best? Or Yapf? Ruff seems to be the new hotness, is that the recommendation now?

I'm sure the answers to you are fairly obvious (and in fairness, a lot of them are fairly obvious to me), but that's often the same feeling I get when people ask similar questions about the frontend ecosystem. Like, if you're not worried about doing anything complicated, pretty much all the libraries that I use on a daily basis also provide a `.min.js` download on the GitHub page, and you can just pack those into a folder and get started writing your code. If you need a bundler, just install NodeJS, and then run `npx vite` in a folder with some HTML files in it, and you'll be up and running in no time.

* My point here is to be sarcastic, but this is one of those things that genuinely surprises me about the Python ecosystem every time I have to interact with it: the default way of installing dependencies is completely insufficient for creating at least halfway consistent builds, and every alternative seems only designed to deal with the happy path.

All of them have little command line programs. You have to run specific commands, in a specific order. Each one does... things. Many things, grabbing stuff from all over the Internet. You have no idea what any of these other things are, but there sure are a lot of them. Do you need them? Dunno, guess so, but where do they come from? Your directory tree starts growing many leaves and branches. But wait, you made a small change, you have to run something else to make it pick up the change and re-something the whozit or your application throws inscrutable errors. You start to despair, so you begin reading documentation. All of the documentation is cheery and bright, telling you how wonderful this or that package or tool is, so now you feel like a moron because you simply don't understand what's happening.

You give up and become a pea farmer.

You have two linters. This is insane. This alone is insane. Everything else is admittedly way worse, but even the smallest bit of the javascript ecosystem tooling choices is full of pain.

Rome for the win! It’s a thousand time faster than eslint and it does formatting too.

It doesn’t have as many rules, but you wanted to get rid of all the cruft anyway, so that’s a feature, not a bug.

What Rome tried to do it, is being all in one tool, linting, formatter, bundler, test runner, etc, but they got only the first two before running out of funding, now it's community maintained.

I want to migrate a project I have, but I fear that it will get abandoned and in the future I will need to migrate away from it again.

Wut? When did they run out of funding? The last half year has seen two major updates. If this is the pace they set when run by the community I can totally live with it.

I have no idea how true this is, but the source of the claim seems to come from here:

https://github.com/rome/tools/discussions/4302

"But in short, the company Rome Tools ran out of funding, so the core team of last year are no longer working on the project."

Of course this also seems to be second-hand information, as there is an "Anyone feel free to correct me" disclaimer at the end of the message above.

I've head about Rome, but I've never tried it. My main fear there is that it dies like so many other dev tools with low adoption do.

This is why I no longer develop for the front end. It’s too much.

He may have 3 bundlers. Webpack as a direct dependency, then esbuild and Rollup, because Vitest uses both IIRC.

I think you're misreading that - the poster used to use webpack via create-react-app, and now they typically use Vite. And while yes, Vite does wrap other tools, it does so fairly opaquely - you shouldn't need to dive into the details unless you're writing your own plugins.

Is it? Prettier isn't so much a linter as a formatter, and I think most language ecosystems separate out formatting from linting - e.g. Rust's Clippy vs rust-fmt.

This is how your comment sounds:

I’ve heard Java teams use SonarCube/SonarLint, checkstyle, findbugs, and PDM in various combinations together. I guess the Java ecosystem is insane and full of pain.

I hear Go programmers use gofmt and go vet. I guess the Go ecosystem is insane and full of pain.

I hear Rust programmers use clippy and rustfmt. I guess the Rust ecosystem is insane and full of pain.

I hear Python programmers use flake8 and black. I guess the Python ecosystem is insane and full of pain.

If you're unfamiliar with Prettier, this gives an overview of why you should use it with eslint: https://prettier.io/docs/en/comparison.html

I just copy my TypeScript starter directory over, and change the name in package.json, although admittedly I'm only ever doing back-end stuff -- couldn't you set something up like that for yourself?

This. The whole comment feels like self-inflicted damage. We have a special repository for various template projects and when we need to create a new project we copy one from there. Sure, it's not bleeding edge, but also not legacy as we bump dependencies from time to time and sometimes replace tools with newer ones.

I admit, it would be nice to have something like Maven Archetype to have things a bit more formalized, but for most of the time a good old copy-paste works well enough.

If you wanted something extra fancy you could even set up a Yeoman generator that accepts input parameters and builds out the starter project based on those.

That’s interesting, might give that a whirl, thanks

I love watching people reinvent Visual Studio or IntelliJ IDEA, badly.

What does this comment mean?

Proper IDEs will set up a lot of the "new project" boilerplate for you, wire up compilers, linters, etc...

People still using text editors like EMACS or VI need to do this themselves, often through some random mish-mash of unique and special text templates, scripts, and copy-pasting from previous projects.

Then unironically they'll proudly proclaim to be productive because of all the tooling they've successfully set up over many days of effort.

The boilerplate is nice for “a vue project” but it starts to fail when you want “a vue+ts project that includes our internal components library, auth, terraform, uses tailwind, etc.” It doesn’t take long to set this up by hand, but automating it makes it less prone to human error - which would be harder to catch in CR because the changes will typically be massive.

But if you CR the Yeoman generator, every project’s initial commit can start from a known-good state since all you need to do is provide it the project name and location.

doesn't npm create do this for you?

Like I can do `npm create vue` and I get a relatively nice and functioning Vue setup with most of the config already done. I agree it's a lot of boilerplate and random shenanigans, but also the apps we make for the web are more than they were. And you can absolutely write JS without all the tools, even with ESModules. But we don't do that much because turns out those tools actually do something. Do they do it in the cleanest way? No. Things could always be better. But they do it.

It does to some extent, and it's much better than it was a few years ago. In Vite's case, it'll create a nice template project with your framework of choice, optionally TypeScript, a linter, and I think also unit tests.

You still need to do additional configuration for your linter, and in my case (I did this last weekend) a lot of configuration for styled-component and twin.macro.

Even though it's easy to create projects, it does nothing for maintaining them. Updating all of these dependencies _can_ be painful. eslint rules are not very easy to configure, there are a lot of helpful rulesets out there which ideally would be bundled with the library they pertain to. For example, it would be nice if eslint saw I was using React and automatically applied recommended React rules, and the same for other libraries.

Maybe create a stub project with all the above you like and check it into github.

When you start a new project, clone it and rename some bits and you should be set.

FWIW, I have a side project, confgen https://github.com/erikpukinskis/confgen, which tries to help with this.

Assuming it’s an app (and not a library) to get what you are describing you would run:

    npx confgen@latest @app vite dist:app typescript eslint prettier react

Unlike create-react-app the idea is you can keep running that command, adding other runtimes and presets, and it will keep working. That’s the sense in which it’s “idempotent”.

It’s somewhat opinionated (vite, react only) for now. But I’d be happy to see pull requests for other stacks so long as things don’t get too complex.

It’s also pre-1.0 but I’ve used it on dozens of projects and it’s somewhat stable.

There are tons of those tools, you were just too busy doing all this work yourself to step back and search for them :)

Do you have any examples? I'd love to take a look!

Angular kinda does this; typescript+eslint+testing+framework are set up out of the box. I think sveltekit as well.

This is why I use Next.js for everything I do, even if I don't need SSR. All of this is set up, with options, when creating a new project.

I've also looked into asp.net lately, and it seems to have just as many moving parts, only difference is that most of it is first party.

I mean, it sounds like you're just trying to create complicated applications. That's not a bad thing, my day job is also about trying to build complicated applications, so I also install a very similar set of tools. But that's worth doing, because there is added value in each of these tools.

If I were trying to do something less complicated, I'd just install less stuff. For example, I don't normally setup devcontainers or Google Fonts, and if I need icons, I might later on install some generic icon SVG library. And if it's just a small project, I probably won't add ESLint or testing. I often skip tailwind as well if I can - it's not bad, but CSS (+SCSS) is built into Vite so it's just less stuff to configure.

But each of those choices has a good reason, otherwise you wouldn't be using it. Tailwind makes writing CSS a lot quicker, linters help us catch more mistakes, devcontainers make it easier to get everyone on the same page, Typescript is incredible for so many reasons, and bundlers handle a lot of the minutiae of getting the right source code into the right destination.

And a big part of a software developer's job is looking at a list of things like that and knowing why each component is there in the list, and whether the value it adds is worth the complexity it adds. For example, in your list, I'd probably drop styled components and the macro toolchain, because tailwind on its own is good enough, and it's pretty easy to write your own components if you need to encapsulate styles somewhere. But you might be doing that a lot, so it might be a different tradeoff for you.

Which comes back to your question: why isn't there something that does everything? Well, because everything for the two of us will look different. You're using React and possibly Svelte, I'm mostly using SolidJS. You're using devcontainers, I'm not. You're using tailwind and styled components, I'm using tailwind and CSS/SCSS modules. A lot of people don't use tailwind at all.

The alternative is something more like Ruby on Rails where everything is preconfigured, but there are no choices any more - you use the tools and architecture as provided, and can't opt in or out of any parts. You don't get to try out Typescript until the framework authors have allowed it, for example. There are a lot of benefits to that style of framework, but it has issues as soon as you try to step off the beaten track. Like with anything, it's a tradeoff.

I think the other reason it's not that popular is that the current state of affairs isn't that complicated. You give a big list of things, but how hard is it to configure them? For a lot of stuff, the defaults will be good enough (for Typescript, I pretty much always just use the result of `tsc --init` but with isolated modules turned on). And the rest you've already configured - you can just copy the configuration from a previous project over. If you wanted to formalise that, you could create a template repo (and potentially publish it and get it to work with `npm init`), but that presumably depends on how often you're creating new projects.

This is a great comment!

I _love_ all of the tools that I mentioned. Like you said, I use them because they add value. I also use them because I want to learn them -- I like trying out new tools/libraries with personal projects, since I don't do much front-end at work.

> And a big part of a software developer's job is looking at a list of things like that and knowing why each component is there in the list, and whether the value it adds is worth the complexity it adds.

This is a great piece of insight. It's something I'll have to think about.

> I think the other reason it's not that popular is that the current state of affairs isn't that complicated

I do think that most not in the front-end space would disagree, especially considering how fast the ecosystem hops on something new.

The setup can be automated with bash script or "npm init <template-name>" or unzip from a template archive

https://github.com/vitejs/awesome-vite#react

There kinda is?

$ npm init vite