448
Asking the important questions
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Apr 2024
448 points (96.7% liked)
Programmer Humor
30950 readers
163 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 4 years ago
MODERATORS
Am I the only one left writing pure JS webpages? I swear for the stuff I've done recently, adding React or even jQuery makes things 10x more complicated and bloated. The base JS support browsers have now is actually great. It's not like the old days trying to support every browser back to IE6
When you are writing some complex web app, you will wish you used a framework. Some web apps can have more than 50 pages with multiple states that depend on remote data to be locally cached and synced depending if you are online/offline. Framework can handle a lot of the heavy state management for you and even provide a nice UI component library. But I do agree that React is too much, but jQuery is being replaced by vanilla JS. That is why I usually use Vue. But for simple stuff, yes, Vanilla JS is pretty much good enough
No framework will make FSM for you. Managing state of web ui is not as hard as managing state of game.
Using TCP for networking? Loss, retransmit, lag, you're dead. Using UDP for networking? Loss, desync, you're dead. Sending full game state? Congestion, loss, lag, dead. Doing sync right, but still pushing too much data? Congestion, loss, lag, dead. Also keeping on server you need not only track game state, but what game state client confirmed to receive.
Strictly speaking, the original commenter is talking about website but sure there is an FSM JS framework too (XState).
I like base JS and I like jQuery. Only reason I'm using React is for native cross platform mobile/web but I'm beginning to regret choosing it for that
I assume you mean react native, not react, unless you're using something like capacitor. React native is a far shot from react and is much more annoying to deal with.
Yes I mean react native
Wouldn't be bothering with it if I were just working with web
Using capacitor as a native shell for your web app can be very nice, actually. It lets you hook into native API calls and build native apps while hardly ever having to write native code, unless you want to, which presumably you don't since you're writing react native.
Honestly doing it again I'd just write in xamarin or something not web orientated because as it turns out the web app is going to need to be separate anyway
I might look into capacitor but is that not basically just electron?
I guess you could see it that way, but web views are inherent in mobile operating systems, they don't need to be bundled into your app, so capacitor apps aren't big bloated memory consuming applications like electron apps are. There's a lot of well made apps running on capacitor that you wouldn't even know, especially if you use something like ionic framework to actually have the look and feel of native mobile apps.
Definitely need to look into this for future, would make dev so much easier to just write for web and not have to deal with react native's bullshit
Why not try flutter then?
Had a look at it, looked worse than react
The biggest problem frameworks solve is “I need the value of this variable to be on the page and I need it to stay up-to-date.” If you don’t have this problem, or you only have it in a couple of places where hand-writing the necessary event listeners isn’t too arduous, then yeah you don’t really need a front end js framework.