For work, sure because it's scalable and many people need to work with it. For a hobby, fuck it, do whatever the fuck you want! As long as it works and you have fun!
This is what always pushes me away from flutter. every time I try to learn it, and I search how to do the most miniscule thing, it's a 30 line snippet full of theming abstractions, modifiers, factory classes and whatnot. It's like doing interfaces in Java 8. This makes me understand why people end up doing webview apps for mobile instead of native apps
I mean I'm sure things can get complex in flutter just like anything else, but this example here is literally just
dart
Scaffold(
appBar: AppBar(title: Text("My App Bar")),
// ...
)
A lot of simple cases tend to be pretty short in flutter, then you add more depending on what you want
Yeah this was a simple case but I don't think I needed a complex one to illustrate my point.
My point being that every time I'm making something, that thing already exists and now I have to learn to use it and all its 30 arguments and implicit variables
Well, you don't have to, if the thing you make does what you need it to do, do you? Sure, you can always add another npm package for the more complete, but more complex solution for your problem. But if your use case is simple enough for your handmade component, just use that. You'll also learn something about the framework this way, and maybe in the process learn to appreciate why the existing solution exists the way it does, and why it makes sense to use it.
for flutter it's the easiest imo what's tricky sometimes is layouts..
the example in the meme is Jetpack Compose and as someone who's very new to it I feel the same way
Oh stop it, it’s easy to read
Nah, Android native without compose it's pretty straightforward, not this compose thing that you have 10+ arguments for a function that makes a simple button
A joke but true. It's always those who don't do anything who criticize and talk about "best practices" the most
Fr this is also an issue with a lot of tutorials and stackoverflow questions, you try to look up something quite basic and some dude is out in the comments showing off the most complicated way to rename a file thats known to man
This is how I feel when I do anything with SwiftUI.
Me when trying to use win32 or batch, recently had to make a strlen binary because somehow there is none in batch, and when I was trying to make a window with win32, there was so many things I had to create, and when it got close to a hundred lines of code, I gave up and decided to not try to make my own 2D renderer. TLDR don't let Microsoft code anything
We are going backwards, arent we?
Just because we have shitty programmers, so we get awful frameworks and systems to mitigate that. Just write good code goddamnit.
This is the real issue. Vanilla js can be more than enough. Everyone is bad at programming even the best. The trouble is most people on reddit are absolutely horrendous at programming AND designing programs.
Don't add more cruft than you need. If a bare minimum top bar works, use it.
For me, the most difficult thing in android development was definitely learning these long functions. For the first time, I looked at the code and was like "OMG! Where do I start? SetContentView, AppCompatActivity etc."
Your custom-made app bar when the user wants to use a different theme or is using accessibility software:
This is spot on the kotlin experience
Repeat after me: HTMX is the way.
How nice you see the thing you yet don't understand why Google embraces if there isn't any design guidelines because there's no standard because it's yet "beta"
I remember using just html, css and JavaScript to make apps - now we have dozens of abstracted programming layers, shadow DOMs, state management, component libraries, dependencies, server-side rendering, unit tests, etc.
It just seems...excessive.
You are still just using JavaScrip, html, and css. It’s just that the complexity is anticipated rather than rediscovered every time you make an app.
t
Javascrip is optimised for medical applications
Javascrip is what they pay me when I work in the Starbucks in the company town
That may be true, however when adding complexity, more tools and systems are needed to manage and/or optimize that complexity, which in turn need even more tools and systems, etc.
I would like to watch you make any complicated frontend with javascript. I did because my company had a crazy tech-lead who forced everyone to do this. It was a disaster. I learned to appreciate frameworks since then, after implementing sub-optimally everything that comes out of the box. If you only need html-css-js for your frontend, more often than not you will be glad to pick astro
For years, I used to work for a very prominent financial corporation and helped build their public facing websites and tools.
This was a time just before SPAs took over (angular/react) and we mainly built responsive apps using jQuery, JavaScript, css and html while using SVN for version management.
I agree if you're building a large enterprise level app, then these modern tools can be helpful, but still it can seem like a bit much sometimes.
Well written vanilla js will beat any framework. That is just a fact. It is more difficult, but sometimes it’s the only rational option.
Beat in what exactly??? Being productive and delivering features to users? No, no chance
Yeah you’ve never actually worked with competent teams unfortunately.
Performance matters.
There is nuance to all this. You can’t say with straight face that it is framework fault that you implemented something poorly. There are constrains, but it is not worth it 99.999% of the time to do this tradeoff of consistency, ease and quality out of the box for microseconds. And if you want to prove me wrong, point to any successful app made with vanilla js at its core.
You are completely missing the point. Netflix for example has removed bloated frameworks when speed and conversion matters most.
Requirements matter. The answer is not always let’s use a giant framework.
99.999% is also a completely arbitrary meaningless figure btw 🤷♂️✌️
No, they removed it for their home page
Neither vanilla ja an answer to everything. If you need vanilla js for one part nothing stops you from doing it when react is your rendering layer. Netflix is still using frameworks for most of their stuff, but they have internal libraries for stuff they need to get right performans-wise. So no, it doesn’t prove that you SHOULD use vanilla js instead of framework. Still waiting for any example of successful web app using only js
Or I could just use Next JS and yeet out a a functioning web app without needing an entire team.
FTFY
It is enforced and imposed on us from the outset. I would gladly accept this complexity and get punched in the face every single time I run an npm command if it meant avoiding the nightmarish balls of mud I had to work with in the past. I tried introducing teams to knockout.js and other, less intrusive frameworks, but they were always convinced that JavaScript was "easy," and would only allocate about 5% of their brainpower when working with it.
The only thing that changed this was when the toolchain became so alienating that they had absolutely no choice but to reconceptualize frontend development as hard. And it was. It was a fucking nightmare where they couldn't just hit F5 to see their changes, they had to wait for whatever Rube Goldberg of transpilation and bundling was popular at the time to finish, only to discover that a single misplaced comma in a config file buried twelve directories deep had silently broken everything.
This is God's punishment for what they did to me. This is the divine retribution I prayed for every time someone thought that the frontend was for interns and that the backend was what we were supposed to take seriously.
Well yes, but that complexity is pushed into everything from the start. It's not "available", it's "required". I can't start simple and upgrade as I need, I have to start with a whole architecture even if I'm just doing the stupidest thing
I mean, it would be pretty hard to build a cargo ship on the frame of a bicycle.
Start with what makes sense? What other engineering field has this luxury? IT is still the most flexible, but you do need some foresight, otherwise your bicycle ship won't fly.
Well yes, but many times the project doesn't start being a cargo ship. They'll tell you "we need something like a fishing boat because our main source of income is fishing" and three months later "what do you mean our fishing boat can't carry shipping containers? We need this ASAP".
You need flexibility and scalability for your project to survive, but developing everything as the next do-everything app from the get-go is just not feasible. There's a reason for the saying "premature optimization is the root of all evil" and the KISS principle. Doing things because you WILL need them later? Sure. But only just in case you MAY need it later? Waste of time IMO
I guess this is where experience comes into play - if you were tasked with a fishing boat that needed shipping container support, and a kayak that needed shipping container support, then next time do give your smallish ship at least an attachment where it can be extended.
Leaving behind the analogy, on the backend side I would definitely almost always start with a spring boot minimal framework - a "hello world" won't be 2 KB, but it does scale down pretty low nowadays, and I can endlessly extend it later on. Frontend is more variable, I agree there, but I would have to have very good reason to go full on vanilla JS.
I can agree with the dev simplifications and benefits of stuff like React and jsx. But I cannot agree with the performance hits taken at runtime. And I always feel uncomfortable making tradeoffs like that.
it's like hiring an entire orchestra just to play a single note on a flute.
You are free to learn the flute. But if you can see that you need a trombone player right afterwards, and 5 violinists in a week, then maybe you better improve your conductor skills, though.
Do you know how much a full orchestra costs?
Do you know how much time AND money is it to learn an instrument?
The analogy works, home-grown "frameworks" suck, they reinvent the wheel badly, slowly and insecurely. Unless your needs are that specific, you are better off with the "fat" way.
Yes, I mean didn’t you learn an instrument at school?
Also who said anything about homegrown frameworks?
Yeah but if you tried to build the same app without all that stuff I think in a day or two you’d be asking for it all back
the good old days where no one requires state and reactivity on web
The good old days when they still needed state, but it was stored globally, implicitly and you had inconsistent checkboxes everywhere.
Unit tests are great.
The rest are optional
Unit tests are great, and I'm sure each of these tools and automations perform some useful purpose - it's just, kinda crazy how much there is these days.
Absolutely love Maven and its automated dependency management.
All the other stuff you can add to it like deployment, bug detection, code coverage, etc is nice to have and exhausting to keep up with.
Most of those things are incredibly useful for solving a problem.
God damn there are a lot though
Shadow DOM is just a DOM with a private interface. You mean virtual DOM I assume?
Ah apologies and you're correct!
As an sdet, I hate shadow doms
I think it’s a grift in a lot of cases. Ask yourself what value these complex frameworks or libraries actually bringing BEFORE you start using them. For example, does react have its uses? Absolutely. Do you need it for a smaller application? Probably not
I really hope you weren't implementing business logic in JavaScript.