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.

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.

Thanks. I somehow straight-up ignored gitattributes and can’t recall to have seen them in projects. Glad that’s past tense now and I will add presets from your link where appropriate (If I remember it). Never had conflicts with windows users on linux based repos but I suspect thats VSCodes merit in keeping the files as-is.

The two commands in your post are not mentioned in the linked repo-readme but instead in the github docs (see [1]).

I know git reset only from dealing with a detached HEAD. I did not understand the situation as well as the git reset command. Both is explained very good in [2].

So here’s the gist of my research (possibly wrong).

Before you even add the .gitattributes file you should add all unstaged changes, commit & push them. To quickly revert back when things go wrong: zip the whole project.

git rm --cached -r: Normally git rm would remove a file from the filesystem in addition to the repo but the --cached says to only remove/untrack the file from the repo (what’s inside the .git dir). Recursively removes every file. Cleans the current staging area too. So at this point you’d have to do git add again for every file but you wouldn’t have lost any uncommitted changes in the working dir.

Now for the dangerous part:

git reset --hard This resets the HEAD to the most recent commit (and cleans the staging-area/index which was already done in the in git rm) and in addition possibly overwrites many unstaged/uncommitted changes with the files contents from the last commit.

So to end this novel. If you havent commited everything before executing the commands your in for a bad time. As far as I see it.

[1].

[2]

The 3-way merge editor in VSCode is a fantastic tool. Really helps in visualizing what comes from where and preventing merge accidents.