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.
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.
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.
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.
React is miles ahead of a bunch of much older frameworks businesses still use. I have projects being built new right now that use ui5 from sap. We have projects with spring boot with the templates in jsp.
I would much prefer a react project to ui5 or jsp. And businesses with long running projects tend not to like using frameworks that don’t have at least ten years of usage and thus some proven surviveability unfortunately.
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 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.
I wish something like .config would be a thing for storing configuration files in repositories. Instead we have a .vscode, .github, .gitlab, .idea, .vs, etc
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
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).
<span style="color:#323232;">git rm -- .*
</span><span style="color:#323232;">git commit -m "be better"
</span><span style="color:#323232;">git push --force origin/main
</span><span style="color:#323232;">shutdown now # take the rest of the week off - you've earned it
</span>
Add comment