5 ms·

Every time I start up a new JavaScript (well, TypeScript) project, I go through the usual routine. Usually it's a front-end project, so I'll pick my framework.

Every time I start up a new JavaScript (well, TypeScript) project, I go through the usual routine. Usually it's a front-end project, so I'll pick my framework. Usually React, although I've been wanting to try out Svelte. Next my bundler, which used to be create-react-app, or some other Webpack wrapper. Today, Vite is the best choice because it works pretty well without much configuration, and it supports all of the major frameworks which is quite nice. I'll be sure to install and configure the TypeScript compiler, which is usually copy-pasting from a template. I always make sure to target the latest well-supported version of JS and use ESM modules, because I like being on the bleeding edge. Next up I setup linters -- eslint + prettier. They do a good job. I have to configure eslint so that it plays nice with Prettier, and I also have to configure eslint for TypeScript and add any other plugins that the project might need, e.g. those for React. I usually like to setup some kind of pre-commit hook to run Prettier and eslint before committing, which saves time. Additionally, I always install my IDE extensions and try to create a .devcontainer file or add list of recommended extensions so that both myself and others can setup their IDEs in the future. I tend to not configure eslint much and just use off-the-shelf configurations because I don't care about the style, I just want consistency in the code and mistakes to be caught. Next up I setup my unit tests, usually jest or vitest or similar. Lots more configuration for TypeScript and whatever, and also usually a set of eslint rules. Then I want a CSS framework. I like tailwind, so I install that and styled-components and twin.macro so that it all works nicely with React. Fonts and icons are often needed too, so I install a plugin for Google Fonts and whatever font library. Anyway, after about a day of doing the above I'm ready to program. Why is it so much work? Why isn't there something that just works for 90% of the use cases? So many people are using Vite + TypeScript + [React|Vue|Svelte] + [eslint|prettier] + [tailwind|bootstrap] + [jest|vitest]. Why isn't there some non-configurable library that just does everything for me?

petesergeant 3y ago
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?
- szatkus 3y ago
  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.
- jackson1442 3y ago
  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.
  - petesergeant 3y ago
    That’s interesting, might give that a whirl, thanks
    - jiggawatts 3y ago
      I love watching people reinvent Visual Studio or IntelliJ IDEA, badly.
      - petesergeant 3y ago
        What does this comment mean?
        jiggawatts 3y ago
        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.
dsQTbR7Y5mRHnZv 3y ago
https://github.com/vitejs/awesome-vite#react https://github.com/vitejs/awesome-vite#react
freeone3000 3y ago
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.
- Aeolun 3y ago
  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.
  - norman784 3y ago
    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.
    - Aeolun 3y ago
      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.
      - whstl 3y ago
        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 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.
  - shepherdjerred 3y ago
    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.
MrJohz 3y ago
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.
makeworld 3y ago
There kinda is? $ npm init vite
Maphistow 3y ago
Angular kinda does this; typescript+eslint+testing+framework are set up out of the box. I think sveltekit as well.
tetha 3y ago
> 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.
- MrJohz 3y ago
  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.
  - tetha 3y ago
    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/ https://flask.palletsprojects.com/en/2.3.x/quickstart/
capttruckerdave 3y ago
There are tons of those tools, you were just too busy doing all this work yourself to step back and search for them :)
- shepherdjerred 3y ago
  Do you have any examples? I'd love to take a look!
ClawsOnPaws 3y ago
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.
- shepherdjerred 3y ago
  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.
o_m 3y ago
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.
vlod 3y ago
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.
erikpukinskis 3y ago
FWIW, I have a side project, confgen https://github.com/erikpukinskis/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.
aabbcc1241 3y ago
The setup can be automated with bash script or "npm init <template-name>" or unzip from a template archive

petesergeant 3y ago

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?

szatkus 3y ago
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.
jackson1442 3y ago
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.
- petesergeant 3y ago
  That’s interesting, might give that a whirl, thanks
  - jiggawatts 3y ago
    I love watching people reinvent Visual Studio or IntelliJ IDEA, badly.
    - petesergeant 3y ago
      What does this comment mean?
      - jiggawatts 3y ago
        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.

dsQTbR7Y5mRHnZv 3y ago

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

freeone3000 3y ago

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.

Aeolun 3y ago
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.
- norman784 3y ago
  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.
  - Aeolun 3y ago
    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.
    - whstl 3y ago
      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 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.
- shepherdjerred 3y ago
  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.

MrJohz 3y ago

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.

makeworld 3y ago

There kinda is? $ npm init vite

Maphistow 3y ago

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

tetha 3y ago

> 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.

MrJohz 3y ago
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.
- tetha 3y ago
  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/ https://flask.palletsprojects.com/en/2.3.x/quickstart/

capttruckerdave 3y ago

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

shepherdjerred 3y ago
Do you have any examples? I'd love to take a look!

ClawsOnPaws 3y ago

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.

shepherdjerred 3y ago
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.

o_m 3y ago

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.

vlod 3y ago

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.

erikpukinskis 3y ago

FWIW, I have a side project, confgen https://github.com/erikpukinskis/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.

aabbcc1241 3y ago

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