To start this static single page project you first need to pull two dozen of JavaScript modules and configure them in 5-10 different files and learn the currently most hyped framework before even writing a single line of code.
And if you’re done, you’ll have to learn how your CI/CD stuff works, and kubernetes, and Helm. And somehow you’re also required to know the arcane and inconsistent rules that Ops put in place a few months ago without anyone telling the devs about it.
Then when you’re done, you find out one of the core modules you use is considered a ‘security risk’ by your infosec team. So you have to start over.
deleted by creator
I’m have done both, Spring Boot and Laravel on BE and Vue, Svelte and React on FE.
Don’t believe the FUD. Vue and Svelte are fun if you have a moderate understanding of HTML, JS/TS and CSS in your sleeve and those reactive frameworks are indefinitely better than vanilla JS or jQuery. React is another beast and I really didn’t like working with it.
Both Vue and Svelte have nice setup tools for NPM/PNMP (I’d recommend the latter) that create template applications in a few minutes which immediately run inside a local dev-server. Change some code and changes are immediately reflected inside the browser. It’s really a nice DX. And both frameworks have very nice ecosystems and GUI frameworks, e.g. VueUse or shadcn-svelte.
React is fine too with the right tooling. Next.js, create-t3-app, vite etc. are all nice. I think svelte has fewer unfamiliar mental models and hurdles to initial development though. I tried vue years ago and found react made far more sense to me for some reason.
It’s really not that bad if your SE sets good standards.
We use C#, Entity Framework, and GraphQL for the BE.
Then TypeScript React for the FE. Now using Vite where we used to use CRA.
Oh you’re using react? I heard it’s not great for security. Just swap it out for angular and we’ll give our approval
As an ops person I disagree! Our arbitrary changes are documented in a jira ticket in the ops project. If you can’t view the ops project fill free to open a ticket in ops and we will triage it when we feel like it.
deleted by creator
Honest question: What is/are your problem(s) with Svelte? So far it seems a lot easier to use than react to me but I wouldn’t consider myself experienced so there might be unwelcome surprises waiting.
It is day and night. Svelte is nearly vanilla JS/TS. No quirks and surprising side-effects like in React. No shadow DOM. With the new rune system in the next version it will even be better. For me it had the best DX of all frameworks I tried.
I suppose OP is frustrated because the business world hasn’t catched up and most of them still only search for React devs, which is in my opinion very stupid, because React can be so frustrating for devs. The reddit sub for svelte has ever so often posts by them praising the sanity of Svelte.
But it would be a valid point by OP if that is their reason when their income depends on it. We can only hope Svelte catches up in that regard.
deleted by creator
Found the Brit.
To start this project, you 1. Install Nix and 2. Run
nix run(god I really love Nix. When it work. And use IFD to not have to manually update a single hash/run a command when you update the lock files.)
Framework has multiple config files, allowing you to customize almost every aspect of it.
Nooo, this is too much config files, they take up too much space in my project tree.
Framework is a monolith with a single file to configure it.
Nooo, the file is unreadable and developing extensions for it is annoying.
Framework is minimal
Nooo, it doesn’t have any useful built-in features.
Framework is a complete solution without too many things to configure.
Nooo, it doesn’t allow me to do what I want.
I feel personally attacked.
I have tried making a framework once, and was annoyed with myself for more than one of those reasons.
So it’s hell for every tool to have a somewhat easy and similar way to customize it to your exact needs? Hard to imagine that working better imo. If there’s a problem here, it’s that you’re overusing tools.
If you think this is hell, you should try using terraform. Some of the most common basic cloud things will mean hundreds of weird, largely illegible files
If they could all coesxist in one file, preferably json or yaml, it would be better.
If all configs could use the same format and be in the same place, that would be nice. Although I think eventually you’d want to split out that config file into multiple places, because having a config thousands of lines long would suck.
If the picture in the OP is the only alternative, I wouldn’t mind, you can easily collapse json/yaml and only focus on the section you need. Maybe split into files based on functionality.
Aren’t these configs in the OP already split by functionality though? If each of these of config files were only going to be a few lines long, having it all in one file would be great.
Well, for example, there’s no reason eslintrc and eslintignore need to be separate files in any scenario, i would group them and prettier into “formatting”. But, yes I agree, one big file is preferred in most scenarios.
or maybe most of them in a folder? and one file that defines their locations for environment variables
Kind of what .env files are meant for. Not enough tools use them.
I wish something like
.configwould be a thing for storing configuration files in repositories. Instead we have a.vscode,.github,.gitlab,.idea,.vs, etcYeah, code editors really missed the memo that the XDG tried sending out, that (… mostly) works so well on Desktop Linux
I agree it would be nice to have that as an option
You could probably do this pretty easily with a custom pre-build step.
I’m not confident a single 2000 line config file would be better, though. Sounds an awful lot like Makefile hell.
I know XML is very last century but if they could coexist in one file, a file that treats each config section as an object, so we can create a Project Object Model, call it pom for simplicity, and then if you are old store it in xml and the you could have only one file and call it pom.xml and then maybe one day someone can make this very useful file a bit more modern and turn it into json or yaml but for now a single pom.xml could save us from that config hell others speak of /s
Welcome to projects 101 where you are now in charge of coding, infrastructure, logging, metrics, secrets, linting and deployment.
Yeah, the whole “you build it, you own it” thing sounds great until you’re neck deep in it.
Modern software development:
I’m a backend dev. I needed basically a single js function for my personal website that called out to some NPM package. I thought: I’ll do this the proper modern way, typescript and everything. Result: under 10 lines of code, but 12 config files (and 1.5h of fiddling with ES Modules vs CommonJS).
The correct way is you download the npm package, copy and paste the function you need and paste it directly into your website
Unless that function has so many dependencies it becomes a hassle just to try that.
git rm -- \.* git commit -m "be better" git push --force origin/main shutdown now # take the rest of the week off - you've earned itmy last super simple project with js:
- index.html
- main.js
- main.css
and the initial stuff was done with chatgpt. From start to finish the project took me about an hour (including deploying it to my server)
But if you didn’t have 200 configs files did you even build a project?
i used http://vanilla-js.com/
Solo development is great, isn’t it?
Actual lines of meaningful code: 3
:3
;3
deleted by creator
:3
Kinda reminds me of
I mean that’s not a programming problem that’s just a webdev is shit problem
stop using javascript i guess
Delete the whole thing
I see a flakes.nix
RIP
deleted by creator
Perfectly balanced
I miss the simpler times of PHP and jQuery
.eslintignorecan be replaced by anignorePatternskey in.eslintrc.cjs- Unless you’re ignoring entire directories or using Prettier in your editor,
.prettierignorecan be replaced with// prettier-ignorecomments in files you want to ignore, or specifying globs in the command line (usually in thepackage.jsonscript fields) - The entirety of
.prettierrccan be replaced by aprettierkey inpackage.json - Everything that ends in
.ts,.js, and.cjsa script, not a config file, and they could all be moved to a separate folder and pointed at with command line flags - All of the options above are categorically worse than the standard layout
pnpm-lock.yamlandflake.lockaren’t config files and shouldn’t be edited unless you know what you’re doing- tailwind is bad and cringe
tailwind is bad and cringe
Everyone disagrees with me when I say this, I’m glad to find someone else who sees through the lies
I’ve seen plenty of people say what you’re saying - though they usually change their tone once they’ve actually tried Tailwind.
I’ve tried it and I still hate it
Sure, some people will have that reaction. In my anecdotal experience you’re part of the absolute minority though, at least 80% of devs I know who have tried Tailwind love it.
It’s bad if you don’t have a design system. If you have a design system it’s :chef’s kiss:
But is it not really annoying to redefine the entire style in the class list of every component? Like if you have multiple things that look almost identical you need about a dozen classes that are identical on each and if you ever want to change that you have to go through each of them and change it, rather than using css classes how they’re actually supposed to be used and changing it in a single place
That’s where the good system design part comes in.
If you have a dozen identical looking components, they should have been one component imported into a dozen places. Keep it DRY.
If you’re more concerned about stuff like common borders or background colors being applied everywhere, you can always use the “@apply” directive to create a new reusable class.
Tailwind makes creating and iterating through design concepts so much faster and easier if your system is designed well.
I agree that it’s useful if you’re trying to create something quick and small but as soon as you want to do anything where there’s complexity that needs to be kept consistent then it falls apart for me. Surely tailwind is the exact opposite of DRY with the way you specify properties directly on the component instead of in a normal css system?
Tailwind isn’t any more or less DRY than normal CSS.
First off, it’s rare to use CSS in the intended way these days - scoped styling has become very popular for good reasons, which means component styles are either already separated, or you’re importing things. This doesn’t change with Tailwind, you can still import things just the same.
But where it shines is removing the need for arbitrary class names. Almost every CSS codebase I’ve seen used class names differently, sometimes even for the same thing. How often have you seen
.containeroverloaded with different meanings? Instead of having to come up with individual class names that might or might not actually be descriptive, I connect the styles to the elements that use them. No more jumping around between CSS and JS, no more arbitrary names - classes have well-defined name structures that you learn once, and use for every project after that.IMO, scoped styling removes Tailwind’s usefulness.
I’ll use Svelte as an example. In Svelte, you can just put a style tag at the bottom of your component, and everything you put in there is automatically scoped to it. I’m not hunting through dozens a CSS files trying to find where a class was overridden and adding !important everywhere. Using vanilla CSS allows me to keep my markup clean and concise so I can better see the actual structure of each component without dozens of CSS class names cluttering everything up.
Sure, you can write your own class in Tailwind using the @apply directive, but why not just add a global CSS class? That’s essentially what you’re doing anyways. And now you don’t have to hunt through multiple layers of abstraction to figure out what styles are actually being applied.
In my experience, Tailwind was good as long as I didn’t try to do anything too interesting. What ended up happening in my project was that I would use Tailwind classes for basic styling, then break into vanilla CSS whenever Tailwind wasn’t sufficient. And that meant I was looking in multiple places to see what styling was affecting my component… which kinda defeated the purpose of using Tailwind.
Personally, I also just found Tailwind harder to read. I prefer to read code vertically rather than horizontally.
I tried so hard to like tailwind. It’s just so… hard to work with.
