Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@retoor I left w/ the same impression 4 Vue vs React, but sadly don't see Vue to be in job posts @ all.
-
@retoor I went code-vegan so to speak, just stopped using frameworks. I tried Vue back in the day. It felt easier than react, but Vue’s reactive mechanism feels like pure magic. And I don’t like magic, because when it breaks (yes, “when”, not “if”), it will take days to figure out, and there’s no guarantee the breakage is not fundamental and can be fixed at all
-
@azuredivay going back to pure JS and realizing it is a whole different language from jQuery times feels like pure modernism. We have native imports! No need for a build system. We have web components. We have web workers for true multithreading, we have service workers for offline-first websites. We have PWA. We have WASM, we have WebGL. We even have DOM mutation observers and whatnot. And the momentum is strong, the development never stops. What a time to be alive and use JS.
-
I feel this. I wanted to build our current app with vanilla, maybe implementing a small library for reactivity. The team refused to do so.
I don't actually blame them, they are not that experienced with js.
Ended up building it with vue. Never used it before, I must say it is nice, not like its two older brothers. -
I have seen exactly one vanilla JS webapp that wasn't a tangled mess, and that's because it rebuilt the DOM declaratively on every interaction for all updated components - the same thing React does but dumber. Less magic, less power.
Imperative DOM mutation other than class lists invariably ends up a giant pile of unstated assumptions and hidden dependencies that can kinda-sorta be figured out with keyword search on the codebase, exactly like JQuery, only now with built-in functions for JQuery's antipatterns. -
@lorentz I do direct DOM manipulations exclusively. Granted, it requires some architecture skills to keep it from turning into a mess, but the immense time benefits worth it. About react, I worked with react exclusively for six years across different companies, and I’ve never seen a react app that isn’t a huge mess. The only difference between a messy react app and a messy vanilla app is the react app took ten times longer to implement, and has twenty times the code for roughly the same functionality.
React is nothing but a very costly way of buying false sense of security. -
@kiki If a single dev bypasses the architecture and relies on the lifetime of an event handler longer than the element instance is guaranteed to persist, you get a bug that is practically impossible to screen for, will not reemerge until an unrelated code change triggered by any event replaces that instance, and will probably not be detected while testing that second change.
Repeat this x100 and you have your average vanilla webapp. -
@lorentz a case this specific probably reflects your personal experience. I wouldn’t go so far as to put EVERY vanilla app in this basket, but I see your point.
There might be real-world circumstances that would make developing/switching to vanilla architecture challenging. Lack of funding right there and right now, absence of a potential vanilla frontend team lead to keep an eye on what middle devs are doing, working with a legacy frontend that took years to develop, etc. I understand that.
It’s just that I want nothing to do with those cases, and I avoid them. My posts reflect my personal experience and aren’t intended to be THE manual on how EVERY dev MUST approach things. -
@kiki My claim was essentially that an architecture based on imperative transformations decays easily, the decay is hard to detect because it does not have immediate consequences, and it is usually easier to make mistakes than to fix them in such an environment so you don't need the lousy devs to be in majority in order for the codebase to degrade.
I don't doubt that if everyone on the team is good vanilla JS works, but that's because a good team that can understand and apply principles can make pretty much anything work, by choosing the right principles and applying them well. -
@ostream and others, in all seriousness though, where is the proof that it is even possible to build a complex app with React? where's React's killer app? If that's facebook chat widget, it totally failed. I know for a fact that it's possible to build very large systems with Lisp — it was used in space programs. C++ is fine too (though I don't like it). Even Java is fine. But not React.
-
@ostream I worked at a company that used React and react-native together. Web frontend built in React was slow, complex and cumbersome. I wasn't the one who built it, but now, with my knowledge, I can easily rebuild it in vanilla. And react-native part was so slow that we used to write a lot of Swift and Kotlin code to make it at least tolerable. It was done to the point that react-native merely served as a wrapper for the native code. We would've been better off just writing native code, without react.
-
@kiki we use react in a lot of internal software, because it's nice to develop in (especially for managing state and shit like that). But yes, it's a whole set of different things to keep in mind, especially architecturally (because if you fuck that up, the react app will be slow). I personally prefer using pure js in frontend (or wasm if possible) and whatever fits best for backend. (preferably compiled).
-
@thebiochemic agree on vanilla, disagree on wasm. Granted, everything depends on the application, but wasm fundamentally doesn’t have any accessibility features. That’s a dealbreaker for me.
In terms of backend, in my experience, the database is always the bottleneck. The kind of backend architecture I do every time is a mere proxy that ties the db to the frontend with a set of purposely built controllers. On top of that, it also handles integrations. In that case, nodejs is more than enough, and we win on hiring staff — one developer can work on both backend and frontend. -
@kiki yeah that's a fair point indeed. But as you said, it depends on the application.
Nodejs is fine, but as you also say, it's essentially just binding together the database with the frontend through some controllers, and i would argue that it doesn't really matter what you use, as long it works for you (or the devs that work on the project) -
I developed some middlesozed projects in vabilla and always enjoyed it. The last one was probably the best piece of code i ever wrote. Just a few hundred loc but a highly complex and easily extensible tool. No compiles time, everyone can understand the code immideatly (given an understanding for map/reduce). So I really like to read that you where sucessfull frameworkless.
I would be afraid at a certain size of a project to try it though. But if boss would ask me to i would love to try it.
There is something else i would like to try: I come from the Angular camp and like two things there: I really enjoy typescript and I strongly prefer observable hell over promise hell. So I would be really curius to write a project using exactly those two libraries, rxjs and typescript and nothing else. -
@kiki usually at the point that you get everything you were asking for, or could reasonably expect, is the point something else, less finished but cooler comes along, and everyone abandons the thing which does what they wanted all along.
Theres gotta be a name for this pattern. -
There is another argument for your point, @kiki, that a mess of vanilla is at least cheaper than a mess entangled with framework: Framework developers are humans as well and they get bored maintaining and security-fixing the same stuff all over again - so at one point they develop *shiver* ideas - and boom you have breaking changes galore and even paradigm shifts that costs you hundreds of working hours just to make your app continue working and keep getting thee newest security fixes.
-
@horus couldn't agree more.
-
@Jason I’m fine, but I’m actually not. Bipolar depressive phase 🤷♀️
It was when I ditched React. I replaced it with raw JavaScript, with frontend being built with Gulp and Twig (just because HTML has no includes). Here are the results:
1. Previously, a production frontend build took 1.5 minutes. Build time became so fast that after I push the code, the build was done before me going to Netlify to check build status. I go there, and it’s almost always already done.
2. In a gallery with a lot of cards, with every card opening a modal, the number of listeners was reduced from N to one. With React, I needed 1000 listeners for 1000 cards. With raw JavaScript, I needed just one click listener with checking event target to handle all of the cards.
3. Page load time and time-to-interactive was reduced from seconds to milliseconds.
4. Lighthouse rating became 100 for desktop and 93 for mobile.
But there is one more thing that is way better than all of the above: cognitive complexity.
Tasks that took days now take hours. Tasks that took hours now take minutes.
Tasks that took thousands of lines now take hundreds. Tasks that took hundreds of lines now take tens.
In real business apps, it is common to build features and then realize it’s not needed and should be discarded. Business is volatile, just because the real world is volatile too. With this kind of cost reduction per feature, it became way less painful to discard them. Throwing out something you spent time and emotional resource on doesn’t feel good. But with features taking minutes to build, it became easier.
rant
wk368