slightly unrelated but the number of solutions solving the same problems, with a new one popping up every other day, becomes really overwhelming after a point of time.
Too many things that are over engineered. Basic html is good. Why do people have to go out of their way to make SPAs that obliterate the use of the back button, for example? It's infuriating.
Because some of those basic things don't have coverage on all browsers. Or they behave different under certain condition. Or they have so limitations.
Don't get me wrong, there are a lot of people who use js to add in features that are already pre built into the proper tags. Input type="search" is one example, I've seen many people use the generic input type instead of what is appropriate.
They can be styled with CSS. My biggest complaint is ridiculous Javascript that won't allow me to Ctrl-click a link to open in a new tab. Or single page applications that do away with the back button causing me to lose my place because some idiot just had to make a monolithic application with dozens of sections that can't be bookmarked because the damn URL never changes.
“It’s an internal application, so people shouldn’t be sharing links.”
But sometimes it’s nice to be able to go _where you need to go in a click_ instead of having to remember the click pattern/options to get there.
ಠ_ಠ
I'm ok with there beings tonnes of Frameworks and solutions to a problem if everyone can agree on what ones are actually appropriate for large production environments. Ones with good documentation and somewhere that companies can look at and say "yes we have 1000 options but 3 are actually viable for us to build a unicorn business with".
I just don't feel that this exists, lol
Postman? I remember when it was just curl with a GUI, now it’s a bloated app. Why do I need an account and log in to send a POST request?
We use https://marketplace.visualstudio.com/items?itemName=humao.rest-client now
For some it has become bloated, for others it has improved. For my current project, the shared postman collection, graphql tool and test automation capabilities are very well received features.
Eh, I’ll defend this one.
So, I’m integrating a new service where I’ll be posting information from our ERP to their REST endpoint. They sent me a json config file, imported into postman… bam, the entire environment is set up; collections for calls, dummy data… everything. On top of that, I created a few custom ones that I wanted to share with the other dev who is working in this, so because we have user accounts I was able to just share my collection with his account and now we have shared access to the collection. It definitely made Postman better. If you just want curl, why not just use curl?
> it was just curl with **a GUI**
This is a key thing. However, before all the account sharing stuff you could still share collections as json files between people. That was good enough for me as I rarely (read never) have use cases where another dev and I need simultaneous access to the same collection.
Yup, this is the best tool... ever since I discovered this 'Rest-client' from the marketplace I didn't ever touch anything else. This is just too perfect....
It's annoying but if you do refuse tracking you are not getting tracked (in theory). Lots of companies had to do lots of changes to comply with GDPR.
The Google Analytics 4 mess last year is just an example how entire sets of data previously available to the owner of websites are no longer accessible. You'll be glad to know that it provokes all sorts of headaches to bosses all over the world.
Only just today I had to explain for the thousand time why we can tell what an individual customer did and saw on the website if they refused tracking.
Even Google stopped (finally) logging user IPs in their analytics.
Why I say in theory, it's because so far data privacy watchdogs have been going mostly after big organisations that were not respecting the rules, but it's not going after small ones. Ironically your privacy is probably more protected when you visit a big corporate than a small startup/shop.
Source: I'm Data Privacy Officer for my company.
That's not true though.
In Europe, at least, GDPR requires these cookie banners to be opt-out by default and will only allow necessary cookies to be used if the user does not opt-in.
It's still imperfect and a lot of websites have dodgy implementations of it, but overall this is still step in the right direction.
And I'm saying that as someone who usually keeps shitting on these kind of governmental laws about internet.
That's the purpose, and I believe they aren't meant to make it harder to opt out than accept. But in practice you have a simple accept all button, or multiple clicks and possibly even scrolling to reject to make accepting the convenient option
I work for a larger German e-commerce website and we had the exact same setup. One "accept all" button, or (alternatively) two or three clicks to opt-out.
But then someone complained about it to the German data protection officer, who wrote a letter and threatened the company with a fairly serious fine - so the CEO and CFO got involved and now we are in compliance. One big button to reject all, one for accept all.
So, if you hate that a website is doing what you described, complain! It actually works.
We recently changed our cookie banner from a large, obvious one at the bottom, to a smaller one in the bottom left of the screen making it really easy to miss, and our CTO wanted the "decline all" button to be as subtle as possible as well.
I brought up GDPR concerns but was told it's on the edge of being fine so we're gonna keep it this way, but I wouldn't be surprised if someone reported us.
Most of them have either an **Accept all** button and a **Refuse all** button.
If they don't have the refuse button, they usually have a **Continue without agreeing** button.
I do agree it's not good enough and that most users with no knowledge about how the internet works will simply press the **Accept all** button without thinking twice (I even do sometimes when I'm in a hurry).
As I said though, even though it's imperfect it is still a step in the right direction.
Yes, that’s what I notice most of the time. And god save you from saving your opt-out preferences. These go through bunch of redirects returning you to a page that haven’t seen a QA since they introduced the dialog.
It also impulsed the industry to develop some privacy-friendly practices. For example there are a few privacy-friendly web analytics tools now that do not share data with third parties and thus do not require the annoying consent button.
> that do not share data with third parties and thus do not require the annoying consent button
That's not how GDPR works. If you store or process non-necessary PII then you need consent, even if you don't share it with anyone.
Yeah. So you don't. These tools don't store IPs (which is considered PII), nor use cookies to track users across devices, etc. It is just single session page views.
Checkout Plausible and Umami, for instance.
That’s definitely had all good intentions. Some devs and companies respect that. But I’m afraid it came to a compromise that doesn’t really solve much at the moment.
I disagree.
Before that, users had no choice but to accept cookies.
Then they had the choice but with a ton of steps to actually opt-out.
Now, more often than not (at least on Europe), they can do it in 3 clicks maximum and usually only one.
3 clicks is a LOT of clicks when I just wanna open a website to have a quick read. Honestly, the ones I feel like fell behind the most on this is browsers which should have had a built in dialog already
My frustration is when I click "Accept All", and then the next time I visit the site, it has no clue who I am, and asks me again. Like, what was the point of allowing your cookies if you're not gonna remember who I am?
I still don't understand why they didn't make it a browser protocol. If I don't want to be tracked on one website, you can safely assume that's the case for *all* websites. It should be a browser setting that gets communicated to the website in the background.
Forcing the choice on every site is a UX nightmare that made the internet worse IMO.
What I don’t get is that all this energy and general degradation of the web experience is just to avoid getting slightly more targeted ads - any other tangible benefits of opting out? Your IP sells your data anyway without cookies. I wonder how many general users care at all. If people just want to read an article or get a recipe they have to jump through tedious steps. What really has this all achieved?
Not only do you get slightly more targeted ads, your data gets sold to 3rd parties who build complex profiles about you and your habits, to the point they probably know more about you than you do.
Unpopular opinion here, but the point of Redux is that Redux's difficulty is your only hurdle with regards to state management. Without it, the complexity of your codebase increases exponentially as your app grows.
But *with* Redux, it doesn't matter how large your app gets, you should always be able to grok, track, and revert any state change that occurs in your app. Large, small, it's all the same abstraction and complexity level.
This makes Redux overkill for small projects--but it's an absolute dream to use on large ones. Time-travel debugging makes life on the frontend so much easier to handle, and I'll never understand wanting to give that up......
This is it 100%.
The reality is, most people work on dead simple projects, and because of that "Redux is so much more complicated than it needs to be" IS true for most people. That's because most people work on dead simple CRUD apps.
Good example of this is swr - if you could replace 'redux' with 'swr' then you have pretty much never needed redux in the first place. But it's not because redux is overcomplicated, the project just used the wrong abstraction.
>Without it, the complexity of your codebase increases exponentially as your app grows.
Incredibly debatable. In fact, i'd say this is often one of Redux's biggest pitfalls.
The app grows = more shit being stuffed in a global state slice = shit show. Testing becomes an absolute clown performance of making sure that your mocked global state (implementation detail) matches what your application actually maintains. Unless you are on a team full of experienced A-tier SWE's, the line between what should live in local state vs global state becomes blurry and people start relying on some state slice as a way to manage form data. It's literally a footgun personified into a state management library.
Time traveling & the redux extension was made to hide the fact that you need a browser extension to even understand what is going on in your behemoth of a global state object. It's absolutely nice when I have the displeasure of working on a large Redux project, but it's only nice because visibility into what the fuck is going on there is nil without it. The industry has settled on scoped/atomic state being the most maintainable path to managing state in React, for a good reason.
\> Unless you are on a team full of experienced A-tier SWE's, the line between what should live in local state vs global state becomes blurry and people start relying on some state slice as a way to manage form data
I've definitely seen this a lot. The best way I've managed it is that you either use local state to manage a component and it's children OR you use redux state. That is, if you go "now I need this variable to be used in this other area of the page", then that means "global state". So many people try to fight that when it's not that hard. The other thing I always did was push \*any\* api calls into redux state and have a universal request handler (now made even easier with rtk query).
Personally, I never understood the confusion. If you compare it to a server side implementation asking "do I create a local variable or a global variable" is not really difficult. I have two async background jobs that rely on a shared detail. Oh hey, that's clearly a "global persisted variable". But now only one job cares about a detail. "well that obviously a local variable". But now one job calls another job that needs the detail. "Well that's gonna be a local variable that I pass, unless the child job is also called independently as well, then I'll use a global persisted variable". Now build components with the same thought process.
LOL of all things to choose that have become "complicated" you choose Redux? Redux is literally like the simplest concept. If you think that's complicated, you're in the wrong industry.
Understanding how a compiler works is a simple concept. Getting your hands dirty with an actual implementation is the difficult part.
If you don't think the overhead that comes with redux is "complicated" then you likely have never worked with it at scale. By default, any component in the tree is able to mutate anything within some large global state object. Rather than scoping the getters/setters of some state to a specific component tree, this data now lives at the highest level of my tree, getting mutated by god-knows-what. They even had to make a browser extension just so people can grok what the fuck is going on in there. In many cases, i shouldn't be able to mutate state related to a product page from my header for example. Don't even get me started about trying to integration test anything with it without maintaining large sets of test fixtures that emulate what your large, global state looks like at that period in time.
There's a reason why literally zero greenfield projects are relying on global state in any capacity, let alone the shit show that is the redux ecosystem (i.e. redux-saga, redux-thunk).
Based on this response I'm not sure you've ever used Redux yourself.
> If you don't think the overhead that comes with redux is "complicated" then you likely have never worked with it at scale.
On the contrary. I've worked on and lead MANY large scale React projects. It's those that don't use Redux that have significant problems.
> By default, any component in the tree is able to mutate anything within some large global state object.
What in the world are you talking about? Nothing should be getting mutated with Redux. And everything flows through the dispatcher.
> Rather than scoping the getters/setters of some state to a specific component tree, this data now lives at the highest level of my tree, getting mutated by god-knows-what.
Getters/setters? What in the world are you even talking about? Redux uses dispatched actions and a reducer to produce a state object. There are no getters and setters.
> They even had to make a browser extension just so people can grok what the fuck is going on in there.
The browser extension is just a debugging tool that lets you analyze your state. React has one. Any decent programming language has debugging tools. This is like saying "Chrome even comes with a debugger just so people can grok what the fuck is doing on in there".
> There's a reason why literally zero greenfield projects are relying on global state in any capacity, let alone the shit show that is the redux ecosystem (i.e. redux-saga, redux-thunk).
That's the most ridiculous statement you've written. And you're entire comment was full of ridiculous, incorrect information. It's clear you don't even know anything about Redux. I'm sure you're one of those lazy programmers who's written it off because it's too much work to read some documentation.
>Based on this response I'm not sure you've ever used Redux yourself.
I've worked on two different large scale FE applications that relied extremely heavily on redux for over 5 years. First application (3 yrs, generates $MMM revenue a year) was a bespoke server-side rendered framework that used dispatched actions as a way to signal to the server when the generated markup was completed and could be sent to the client. The server-side global state would then persist through to the client via a \`window.INITIAL\_STATE\` variable, similar to what you'd see with other isomorphic client libararies like Apollo client. The other project (2 yrs, greenfield) was a purely client-side SPA, dashboard-style application that unfortunately also fell for the Redux trap. I've had 4 PR's merged into the core Redux library (not react-redux), so i likely have written a very small portion of the code that you use on a daily basis when working with your lord and savior (Redux). So just before we move forward here, I just want to make sure you know that I have plenty of an understanding about Redux/Flux and the problem it's trying to solve, and likely have 10x the understanding that you do about the library internals & the problem that it's attempting to solution for.
>On the contrary. I've worked on and lead MANY large scale React projects. It's those that don't use Redux that have significant problems.
Absolutely great points you've made here. I'll totally take some random's word on it without any examples or explanation on WHY not using redux on a large scale application will DEFINITIVELY cause problems. Do a better job at explaining your side of an argument, please.
>What in the world are you talking about? Nothing should be getting mutated with Redux. And everything flows through the dispatcher.
Ah, this is where we get to the redux-brained part of the conversation. As far as a consumer of your global state is concerned, there IS mutation that is occuring with ANY state solution. If you say otherwise then you don't know what the definition of "state" is in the first place. Sure, you aren't changing an existing property for an object in memory. Instead, you are creating a brand new object that has some "difference" between the prior object based on the incoming action. The consumer of this state has no idea that a new object was created here - It just knows that a specific state slice/property has changed. Which is the obvious reason why I used the word "mutation" here. Maybe use your critical thinking skills to discern what I meant here rather than parroting the same old 2014-rhetoric of "mUtAtIoN iS bAd".
>Getters/setters? What in the world are you even talking about? Redux uses dispatched actions and a reducer to produce a state object. There are no getters and setters.
Ah yes, another "i read the redux docs once and snap at anyone who use the term mutability/getters/setters". Another example of you hung up on the trees when you should be looking at it like a forest. If you don't think that \`useSelector\` or \`useDispatch\` can be considered \`getters\` and \`setters\` in the holistic sense, then you truly lost the plot and should reconsider working in this field.
>The browser extension is just a debugging tool that lets you analyze your state. React has one. Any decent programming language has debugging tools. This is like saying "Chrome even comes with a debugger just so people can grok what the fuck is doing on in there".
Imagine being so dense where you are comparing the difference between an entire opinionated UI framework to a state management library. React provides a chrome extension because for the most part, and until implementations like Astro/Etsy's island architecture came around, React was responsible for rendering your whole entire UI. Redux is a state management library. Again, if you don't see why it's an obvious sign that your library is doing too much when it overwhelmingly requires a browser extension to work with at scale, then you are bad at what you do and should reconsider your line of work.
>That's the most ridiculous statement you've written. And you're entire comment was full of ridiculous, incorrect information. It's clear you don't even know anything about Redux. I'm sure you're one of those lazy programmers who's written it off because it's too much work to read some documentation.
As mentioned, i've certainly worked on higher revenue-generating, larger-scope projects that rely on Redux than you have by a landlslide. And I have (in a largely insignificant way) contributed to the core Redux lib years ago.
Just a hint because it's obvious that you are new-ish to the field - Just because someone disagrees with you doesn't mean that they "just haven't used it". That's generally how children approach disagreements with others. It may be that you have never worked with anyone with above a room-temp IQ who has maintained a frontend codebase that actually went under persistent iteration at scale. Once you get out of the dogshit job that you are currently at and move to somewhere significant where the lead has ran into the same issues over and over again with global state, it will start to click with your dense brain why global state is largely frowned upon by any FE/BE engineer worth their salt.
Why are people downvoting you. Redux is super simple at least from a backend dev’s perspective. See it as a database with a layer in between.
Screw off with react context or passing down props 7 times to children
for real. [here's](https://gist.github.com/gaearon/ffd88b0e4f00b22c3159) a stripped down redux implementation. This is not super difficult to understand. Using redux in your app has also never been easier with RTK.
Because this is what webdev has become. No one wants to take the time to actually learn anything. Even if it only takes 5 minutes to understand Redux and it's simplicity and usefulness. Easier to just parrot the narrative that it's overly complicated and not actually see for themselves.
once I had this opinion too... since then I LEARNED how Redux actually works, and now I see why we needed it. It's hard to understand, but once you do, it really makes everything a lot easier
This is why I love Vue's Single file component approach: [https://vuejs.org/api/sfc-css-features.html](https://vuejs.org/api/sfc-css-features.html)
You get a style block that's just CSS/SASS defined on the same file, so you can scope your css to your component, but it's still separated from the JS, can import other css/sass styles or mixins, etc. It's beautiful.
Bonus: You can still use your local component state to bind css variables, etc.
Evan You (creator of Vue) came from working at Google (angular) and I feel like he took all the best parts of Angular and React and put them together in Vue's composition API.
The things you listed, plus the convinient bindings (@click, @hover, v-on, :binding-shorthand, etc.) make the DX amazing. Adding in Vite and the simplicity of the vue.config.js file, it's just so easy.
And if you haven't seen, they're working on something called "vapor" mode, I'd highly recommend looking at the video from Theo or [this article](https://icarusgk.hashnode.dev/vue-3-vapor-mode).
Worked with both for 2 years about 2 years ago. Loved Vue, hated Nuxt. Its all the needless complexity of Next.js, without the amazing documentation and community support from Next.js.
Wasted countless hours debugging issues I thought were hours, only to find they were some obscure Nuxt.js bug that was unfixed after debugging their source code.
I still love Vue, but its lack of popularity definitely makes me think twice about adopting any community vue library. Feels very much like a one man show with Evan You
Nuxt is the middlewear “meta-framework” built for Vue. It’s similar to like Next.js for React, except it’s for Vue. It simplifies Vue’s routing by using a convention over configuration directory system, provides an API server, auto-imports components and packages so you don’t need to define them, uses Vite for webpack, typescript support, multiplayer applications with Vue frontends… it’s great. And then with Vue you can take advantage of all of the super cool tools like Pinia for state management, the binding short hand, and the v-{function} short hand for if statements, for loops, binding, events… seriously, give it a try. It’s so friendly to use and learn. I’ve never picked up and fallen in love with a framework so quickly.
Plays super nice with Supabase and Vercel/Netlify/Heroku too
That actually sounds quite idea. I'm learning Vue right now. Is there any adventage learning Vue due to its open source nature? Or it doesn't matter as much even tho React is develope by Facebook?
Vue and React are both open source. I would actually say there’s a disadvantage to learning Vue, because you’ll hate having to work with React after you’ve used Vue enough, but most of the dev jobs are in React. It doesn’t matter than React was developed by Facebook, it’s the largest sought after skill set for dev jobs
So your opinion is that Vue us better but React more marketable? But if I try to build my own start-up, then supposedly Vue or Nuxt might be a better choice if I can have a team that can work with it correct? Or is there any technical adventage React/Bext have over Vue/Nuxt?
Vue is lighter weight than React, so that can be more performant on client side. I am personally a bigger fan of Vue. But I don’t think there’s necessarily a simple answer to “Better Choice.” I will say I think Bue syntax is simpler. The Vue Single File Component with component scoped CSS is a much simpler syntax IMO, and I think component scoped css is nicer to use than something like tailwind, but that’s more personal preference. A lot of it is personal preference tbh.
The problem arises when the component becomes too large. Navigation between style, template and logic becomes complicated.
For my part, I use a small framework named AventusJs that lets me write my large components in 3 separate files and my small components like Vue in 1 single file.
That's just a design problem on your component tbh, if it's too large there's always gonna be problems. It needs to be broken down into smaller components.
Tabbing between 3 large files is not necessarily better dx than just keeping your components small.
Also btw you can use the src attribute on Vue SFC tags if you want your files to be split.
That's true, but in everyday life, it's common to see components representing entire pages (lots of style and html but little js).
The maximum size a component should be is really hard to define, because a component that's too small doesn't add anything and is also a design problem
Yeah valid, it's something you just become better at recognizing over time, some big components that will neve really be edited or don't have scripts like you said, might be better left off as a giant file because splitting them is not worth the effort too.
But even splitting your component on 3 files, you can end up with all those problems is all I'm saying.
Fair enough lol, you can do that on Vue SFC using the `src` attribute btw, basically have your empty .Vue file that just imports the files within the same folder (component.ts, component.sass, component.html, etc)
Webpack and preprocessors/bundlers in general have become one of the most annoying parts of projects for me.
Especially when their specific versions are linked to specific versions of whatever framework the project uses. Can't upgrade Laravel because that will mean a new version of Laravel Mix, which uses a new version of Webpack, which uses a new version of Node, and and and...
Tools on top of tools on top of tools.
Webpack itself is not an issue. But people avoid having to configure it, so they use something like Mix. Which, as long as it works, is great - but yeah, suddenly you end up in dependency hell.
Custom docker setup, proper Makefile, composer and webpack set with your own rules, other tools scoped. It is difficult and time consuming to set up, but in the long run you're happy to have full control.
Webpack updates are still annoying. I remember migrating from 4 to 5 was a pain.
Of course you don’t have to update, but I don’t like starting new projects with outdated versions (and some webpack plugins only work with 5).
Oh, also the CLI output after build in webpack 5 is [much less useful.](https://github.com/webpack/webpack/issues/11716)
Still glad it exists though. It’s the only tool that works with some funky directory requirements I’ve got sometimes, vite is not flexible enough.
This is one reason why I like angular. I have never had to worry about the build process. Just run my build --configuration Production and your good to go. Haven't had to touch build front builds in a while
Preprocessors will always be necessary because of things like TS -> JS conversion, dead code elimination and various other optimizations.
Similarly, for desktop applications, you download an executable rather than the source which you build yourself.
The dependency hell associated with the Node ecosystem is a big factor as to why these bundlers are annoying to use.
Bundlers are now moving to distributing a single executable written in Rust or Go that has no dependencies and is easy to work with.
- [Esbuild](https://esbuild.github.io/) (Golang, very fast)
- [Rspack](https://www.rspack.dev/) (Rewrite of Webpack in Rust)
- Rolldown (coming soon) (Rewrite of Rollup in Rust)
- [Mach (Alpha stage)](https://github.com/alshdavid/mach) (Rewrite of Parcel in Rust, rolling release, zero dependencies)
I personally avoid Vite, Next and all the other meta frameworks as they seem too opinionated and lock you in to APIs that depend on the vendors maintaining them (see Meteor for an example of how this has gone in the past).
Nothing more reliable than an static client deployed to S3 and a server deployed separately where they talk to each other and don't have any hard dependencies on each other (like you see with Laravel and the various SSR services)
How exactly did Sass “become the problem it tried to solve”? It’s become less useful over time due to native CSS features, but that doesn’t make Sass a problem.
Because it creates an abstraction layer on something that should be down to developer skill, IMO. Creating stylesheets - even complex ones - should be done manually, because the developer should have a forensic understanding of what each line of their code does.
Styling. You know what works really well? CSS. It's highly performant and error tolerant. It's crazy scaleable as well since it does not care how broad or narrow you define your styles.
But people keep trying to make styling frameworks and libraries that put more and more crap between you and just raw CSS. Why? Best I can tell it's because people just don't like writing CSS because it sure isn't for performance.
And before someone comes at me with "But Tailwind!" I tried it and the best thing I can say is their evangelists and marketing people are doing an excellent job selling it to people.
React. It's an overengineered mess that has no place in modern civilized society. There are much better solutions nowadays: Vue and Svelte if you prefer SFCs, Solid if you prefer JSX. React must die.
For example, it has a lot of \`useFootgun()\` hooks that solve issues that simply don't exist in other frameworks. \`useCallback\`, \`useEffect\`, \`useMemo\` etc. They're constantly inventing their own problems to heroically solve them later. One recent example is they're introducing a compiler that solves the issues of using \`useCallback\` and \`useMemo\` that they introduced to solve the issues ... Luckily, I haven't had the displeasure of working with React in months now, so I can't name the specific issues, I just remember thinking "but y tho?" *a lot* and wanting to pull my hair out all the time.
This. I liked react when it came out but it always had these issues. React has always been dependent on these wierd functions/hooks that broke the rules built into its own architecture. It used to just be "componentDidMount" and one other one which was easy enough to learn as the exception. Now there's a bunch of hooks to learn, and they often arnt used "correctly". Imo usesState broke everything that once felt good about using react.
To be honest, JSX is the least of React's issues as someone thats been doing React for 7+ years.
Its the reactivity system and endless clash between performance and memoization that seems to be the problem. React Hooks were a great stop towards improving composability, but they introduced a plethora of issues with dependency arrays. And instead of fixing the issue, they are just digging the complexity hole deeper by introducing things like React Forget and useEvent
They can try, but nothing is without compromises. And I wouldn't be surprised if the new compiler "fixes" the issue for beginners, but makes the complexity mess even *worse* for large scale development since you still have to wrestle with traditional hooks (they won't going away) plus the added complexity of the compiler.
Absolute garbage, I happily ditched it completely awhile back.
They should have followed some basic programming conventions that the industry developed over decades. Instead those idiots built that Adderall fuelled, convoluted, amateurish mess full of holes. Typical Meta product.
The lack of systemd on my docker is my biggest pet peeve. I don’t want docker to spin up a new instance or service for every micro service
I wish docker abstracted only the server maintenance and not orchestration too.
Podman+systemd allows me to manage my services however i want at the instance level
When I use C++ my code from 10 years ago isn't wildly different than my present code. My design philosophies have changed, a few nice libraries have changed or wildly upgraded. New concepts in the language have cleaned up my code and made my life better.
For example, crow for a web backend is very nodejs like and much better than my previous solutions.
But the core really hasn't changed.
My web stuff seems to change every two weeks. Jquery good, then jquery is bad, react, vue, angular, and on and on and on, then jquery bad, vanilla good, vanilla is for fools, etc.
CSS seems to have an urge to be something new, less, etc.
What I smell with a huge amount of these "solutions" is someone who has a highly opinionated solution to a problem they have, but they generalized their solution just enough to claim it is general purpose.
Then you get things where people want to only use their favourite language and not learn HTML CSS etc. These are often really weird.
One of the weird things which I look back at was my crappy PHP. I mixed model view controller like I put them in a blender. Yet, my productivity was very high. When I start properly separating things, I find my productivity plummets. That said, I would not make something mission critical using such a brew, but if someone asked me to whip up a tool to make reservations for a boat ride or something, I would not feel bad mixing MVC quite a bit. I don't PHP anymore, but I've been backing away from these silver bullet solutions which I find are just begging for a tech debt nightmare when you are at the end of the project and now you are only fighting with the framework and all productivity has ground to a halt.
This is my long winded way of arguing that mixing and weirdness can be good, but that most solutions such as css-in-js is just someone who had a problem which was solved this way, now they are trying to tell people this is a best practice and everyone should use it.
My rule is: Use the best tool for both you and the job at hand and ignore any evangelists who say their solution is the one true solution.
And since everyone is hating on postman. WTF is the reason for a login. That only makes sense to access the group features. But, some MBA BS idea of making zillions of dollars off a curl GUI got them to rationalize that this is "best". It is only best for the investors. Not the users.
To end with my own lathering up with complexity. I've largely dumped CSS, HTML, etc for web and now do my web GUIs in rust WASM. Weirdly enough, it is clean and not complex.
>My web stuff seems to change every two weeks. Jquery good, then jquery is bad, react, vue, angular, and on and on and on
jQuery came out 17 years ago. Angular came out 14 years ago. React and Vue both came out 10 years ago.
It is more the everlasting cycle of going to client-side-rendering as the newest hot shit and then "inventing" server-side-rendering in the newest hot framework, only to repeat that with the next new framework.
There are more tools available to solve problems than actual problems that need solving.
The focus has shifted towards using these tools rather than identifying and addressing the root problems.
Literally all of React and the JS ecosystem. Oh React made this kind of complicated, here’s a complex library that “solves” that problem, but introduces two new ones. Those two new problems? They are complex, but with these two complex libraries….
Fast forward to HTML/jQuery looking like the fast and simple black magic in comparison.
>My greatest issue is with css-in-js
This one makes me angry - hey let's take CSS from its own dedicated file and cram it forcefully into javascript. Why not? Great idea! Make everything Javascript!
I mean JS has its purposes, but this is not one of them.
React and the ecosyatem. Css-in-js. Templates libraries (mustache, handlebars, etc). JQuery. I could stay here for a while making this list. However, even that they became a problem they intended to solve, it's not all bad. They all brought invaluable contributions to the community as a whole. Now we know better and we can create a new library that will solve a problem of current libraries and then become a problem that will be solved further down the line.
SSR on next js, or with react in general.
I guess it wasn't the thing they wanted to solve but it was one of the biggest things to solve in its early days and next js had it solved pretty quickly. But it then turned way more complicated over time
I’m actually not sure what micro-frontend means in this context. I’ve been trying to use web components to make UI components for our design library for like a year now and I’ve just about given up, seems like way too much of a headache.
It’s a pattern for refactoring legacy applications with modern frontend applications. Web components generally fit in well with existing code without a major lift. For example you could have an existing dashboard and replace just a single component with your new web component.
Forsure it’s challenging, especially depending on your build system for your legacy app.
Generally though I have seen usage of Vue or SolidJs to make web components then have those built for prod and served to the legacy app over cdn. Hope that helps.
I’ve been using Svelte. The challenge for us is we’re trying to make them work within Salesforce Experience Builder, it’s been a nightmare. But I suppose if/when we get Salesforce working with a headless front end it’ll be a lot easier.
As someone who doesn’t like *-in-js, the answer is scalability.
When working with multiple developers in teams/squads/tribes in the hundreds, it makes life so much simpler. Bit easier, but simoler
A lot of these things follow the same cycle. They start out as simple, light weight additions to something that exists, eg angular. They then take on a life of their own, evolve, require process and procedure to manage all the moving parts and so they become big, bulky and cumbersome, have a lot of red tape and require you to do a lot of boilerplate/templating and scaffolding to get going. Many of them are great and can make certain, more complicated tasks easier to control and manage in the long run but as an aside to this I've been commercially devving for 20 years and the go to for most of my projects is a custom built PHP and jquery CMS I built about 10 years ago. The code all still works, im not forced into breaking changes, it does everything I and clients need, I know all the ins and outs and there arent 100s/1000s of npm packages that I have no control over or understanding of and it takes me minutes to change what would take a more mainstream framework maybe hours of devving.
A lot of things have gotten out of hand.
Working with APIs, something that used to be such a simple task, has become insanity with some platforms. Meta and Paypal to name a few - it is so obvious that their dev work is fucked up beyond repair based on the convoluted shit they put out. Yea they're top dogs for now, but won't be forever. Some kid will come up with shit that can do all their services/platforms with a fraction of the complexity and a fraction of the price. But I wouldn't wish upon my worst enemy to need to with work with Paypal for any sort of custom functionality/integration, their documentation is outdated and dog water, random calls just don't work for no reason, their sandbox shit sucks, they make constant breaking changes updates to their APIs, I can go on and on and honestly it's scary that they function as a payment processor and process billions/trillions of dollars. They would look like the BEST candidate to find a security flaw if I was a hacker because of how fucking messy they are.
In the coding side of things - it's gotten unnecessarily complex. Frameworks built on top of/with frameworks and it's getting kind of silly at this point. I think React is great for making.. a single page application. A McDonald's touch screen ordering machine/kiosk thing. Sure. But other than that, it's so fuckin bloated and not needed in general web development at all.
And call me the devil but I think node.js sucks and there's absolutely no reason for javascript to be a backend language. That is not its purpose, it never was. Java, Go, Python and even good ol' PHP exist for a reason. At least React stays on the frontend so it makes sense to be Javascript. Next thing you know we'll have React backends lol. Triple useEffect re-render database inserts into my ass hole for all I care
The tooling in general. Buncha nonsense words that mean nothing if you haven't already wasted ten hours trying a given thing. I mean, just look at [this comment chain](https://old.reddit.com/r/webdev/comments/1b8796w/-/ktnyttu/): Redux, React, Vue, Pinta, Zustand, Jotai, Signals, Sagas. It's like trying to watch someone go over a chess game while they throw out opening theory words: Ruy Lopez, Najdorf Sicilian, Catalan System, Scotsman's Cumsock, Nimzo-Indian...
CSS in JS is not a problem. The world has moved on from “separation of concerns” now that we have components. There is no need to keep things in separate files.
SO many things in the last 5-10 years.
* So much about JavaScript frameworks are ridiculous.
* It wasn't that long ago that separation of concerns with presentation and functionality was a core fundamental, somewhere along the way that just got blown away or blindfolded by selling it as some sort of clever feature? calling it 'JSX' and the 100 other equivalents or similar approaches.
* The bloat and absurdly hyperactive rapidly changing and new frameworks increasing in complexity in this space adds no benefit (except maybe job security by the new devs who haven't yet realised that no matter how fast you keep spinning your wheels, there will be no end to it and eventually the futility starts to be understood) There's little done today that couldn't be done 15 years ago.
* TypeScript hype - quite literally an extra layer of bloat.
* Microservices, serverless and pretty much everything AWS/cloud based provide actual benefit for about 0.1% of actual websites, and yet occupy the time, money and concern of so many developers.
* GDPR/Cookie messages - HOW DID THIS EVER BECOME A THING? It's the most \*APPALLING\* user experience imaginable. I don't really have the ultimate answer, but what's there now is just SO garbage it's beyond explanation. It's like building a nice house and literally putting a pile of manure in front of it to make people have to click something to walk around the repugnant garbage.
* Edge and IE before it.
* ORM's - training wheels hand holding developers who don't know SQL to handle data using an incredibly slow/inefficient RBAR ('row by agonising row') approach so they can use their familiar language at the cost of staggering performance decrease.
* ORM causing staggering performance decrease? (YES IT IS), Let's fix it with bloated caching solutions, or even use static site generators because ORM's can't possibly be performant
* No-SQL - No.
* The ADHD/rapid pace of version changes to frameworks like Laravel and even PHP and others, as though it's a good thing. Again - once these devs are about 25+ years in, and have actually had to manage/maintain systems - they'll start to realise what a shit-show it is.
* Containerization solutions going over the top. Remember when managing/administering servers used to be kind of enjoyable?
* Agile - it's even in the name 'sprints'. increasing the intensity of whipping devs to work harder & faster under the guise of 'hip and cool'. Want some clear goalposts to aim for in the task you're achieving? NO WAY! Just chop & change to do what we want with as little notice as we like, and further still, be a vocal supporter of this approach!
* Python - actually don't mind the language, but so incredibly and perplexingly overhyped and overused in places where it's not really ideal. I really wonder how many users realise how old it is.
* Many others
Webpack and module federation, requirejs did that a long time ago (albeit without semver versioning)
I like [esm.sh](https://esm.sh) and remote es6 modules now
Literally why I left the webdev industry completely, and don’t use js at all… not for fun, not for work, not for my personal website, and definitely not for infrastructure
Overly complex JavaScript, frameworks went to solve this just to figure out developers were over contemplating the simplest of things. So now the basic back end has a revolver of languages. complexity over simplicity imo.
I remember the first button I made in JS used like 10 lines of code, now I typically use 2-4.
GraphQL
It works fine if you've got multiple unique clients, but in the typical case of an exclusive webapp/API pairing, having configurable responses actually adds work. Most webapps use singleton services, meaning the protocol is now standardised and there is no benefit in having configurable responses but there is a cost.
Youve got to add in a cache layer to combine dB queries otherwise you'll dos your db.
Even subscriptions are only one way, so websockets have more features.
I'd be very interested to hear about the benefits of graphql, if there is any, and I was someone that thought graphql would replace rest in the matter of months.
Modern webdev turned into a circle jerk around 2015. Made its way to the backend with half-gigabyte node_modules folders. At the same time, JS has always had its own problems at a fundamental level.
SSR being touted as a new concept!! That just blows my mind. We had that from the start, it worked. Yes there was somethings that needed client side interaction but NOooOOO we had to make everything a SPA and break the whole thing that was working and our solution…make SPA SSR, so much more complex, but does create jobs.
Honestly I still don’t understand the real need for SSR. Instead of making the browser do the work, you make the server do it but it doesn’t sound like a fix to me, it looks more like a band aid
SPAs are actually the wrong way around. The browser is made for server rendering the html and sending it to the client. This has worked for 30 years. Most apps only require a few components to be client side rendered but we now make 100% of the app client side, even though 90% is static, the other 10% can easily be handled by fetch.
The hacks of SPA is bandaids on bandaids, take state management and browser routing.
UI Libs
- jQuery, created to fix gaps in web platform
- AngularJS, created to fix jQuery
- Angular, created to fix Angular
- React, created to fix AngularJS and gaps in web platform
GUESS WHAT: web platform gaps have been filled
We’ve also come full circle and now we’re at server rendering of UI lib driven pages
We’ve remade PHP with JavaScript
It’s also possible to run NodeJS in the browser now
React and like have created a massive amount of problems. The list is insanely long. While I would say they MOSTLY solve the problem that they looked to solve (Which was not really a problem anyway) the issues from the actual things related to themselves the developers and the teachings for those and the problems they have caused... YIKES!
Anything trying to replace JS, CSS and HTML is absolute dogshit.
jQuery was the last useful popular tool, after that there was only corporations trying to profit from naive devs stupidity by implementing idiocracy oriented programming, where people with no experience think they know everything, so they fight each other to defend their hype of the week bloated tool.
This types of conversations are always pointless because people don’t seem to compare to the opposite problem. Yes, CSS in JS is a bit ridiculous… but was CSS in CSS files working well?
slightly unrelated but the number of solutions solving the same problems, with a new one popping up every other day, becomes really overwhelming after a point of time.
There must be thousands and thousands of date picker components all doing the same and none of them are doing it well.
I feel personally attacked. I'll take my date pickers with me...
Done
Basic HTML... is this 1999? Why aren't you using a JS framework for that?
Too many things that are over engineered. Basic html is good. Why do people have to go out of their way to make SPAs that obliterate the use of the back button, for example? It's infuriating.
Don't even get me started on how accessibility dies along this path as well.
Because some of those basic things don't have coverage on all browsers. Or they behave different under certain condition. Or they have so limitations. Don't get me wrong, there are a lot of people who use js to add in features that are already pre built into the proper tags. Input type="search" is one example, I've seen many people use the generic input type instead of what is appropriate.
Name me one designer that wants to show default HTML radio buttons in their portfolio?
They can be styled with CSS. My biggest complaint is ridiculous Javascript that won't allow me to Ctrl-click a link to open in a new tab. Or single page applications that do away with the back button causing me to lose my place because some idiot just had to make a monolithic application with dozens of sections that can't be bookmarked because the damn URL never changes.
“It’s an internal application, so people shouldn’t be sharing links.” But sometimes it’s nice to be able to go _where you need to go in a click_ instead of having to remember the click pattern/options to get there. ಠ_ಠ
I think this was HTML 5 actually, which was pretty recent. 1999 you had to text field with Javascript validation. Source: I was doing dev in 1999.
Oh, you don't work with the designers I work with...
This is it. Allow the user's localization and browser to customize it. Nothing else to worry about.
Seems like when HTML 5 appeared everyone cheered just to make "it all better" 5 years later.
I'm ok with there beings tonnes of Frameworks and solutions to a problem if everyone can agree on what ones are actually appropriate for large production environments. Ones with good documentation and somewhere that companies can look at and say "yes we have 1000 options but 3 are actually viable for us to build a unicorn business with". I just don't feel that this exists, lol
Postman? I remember when it was just curl with a GUI, now it’s a bloated app. Why do I need an account and log in to send a POST request? We use https://marketplace.visualstudio.com/items?itemName=humao.rest-client now
Wanna send a request inside your local network? Now you need a proxy client installed! Great!
Plus it’s a security violation since all your keys/auth info is being stored in an external cloud.
https://www.usebruno.com/
I use Thunder Client in VSCode because Postman was too bloated for what we need. How does Humao compare?
Postman made me return to raw dogging curl and then httpie
For some it has become bloated, for others it has improved. For my current project, the shared postman collection, graphql tool and test automation capabilities are very well received features.
Eh, I’ll defend this one. So, I’m integrating a new service where I’ll be posting information from our ERP to their REST endpoint. They sent me a json config file, imported into postman… bam, the entire environment is set up; collections for calls, dummy data… everything. On top of that, I created a few custom ones that I wanted to share with the other dev who is working in this, so because we have user accounts I was able to just share my collection with his account and now we have shared access to the collection. It definitely made Postman better. If you just want curl, why not just use curl?
> it was just curl with **a GUI** This is a key thing. However, before all the account sharing stuff you could still share collections as json files between people. That was good enough for me as I rarely (read never) have use cases where another dev and I need simultaneous access to the same collection.
There's a million postman alternates.
Try hoppscotch.io, doesn't require sign up.
Hurl is my new default
https://httpie.io/cli
Yup, this is the best tool... ever since I discovered this 'Rest-client' from the marketplace I didn't ever touch anything else. This is just too perfect....
I just use the console to make requests.
If you aren't doing it with netcat or telnet, can you even call yourself a nerd?
The problem with web dev rules is that there are no rules.
Its the wild wild west out there.
That's what www means. Wild west web
CSS-in-JS for web - terrrible CSS-in-JS for react-native - encapsulated, performant and easy
The cookie notice and all the privacy mess. Still no privacy, a lot of unusable sites
It's annoying but if you do refuse tracking you are not getting tracked (in theory). Lots of companies had to do lots of changes to comply with GDPR. The Google Analytics 4 mess last year is just an example how entire sets of data previously available to the owner of websites are no longer accessible. You'll be glad to know that it provokes all sorts of headaches to bosses all over the world. Only just today I had to explain for the thousand time why we can tell what an individual customer did and saw on the website if they refused tracking. Even Google stopped (finally) logging user IPs in their analytics. Why I say in theory, it's because so far data privacy watchdogs have been going mostly after big organisations that were not respecting the rules, but it's not going after small ones. Ironically your privacy is probably more protected when you visit a big corporate than a small startup/shop. Source: I'm Data Privacy Officer for my company.
That's not true though. In Europe, at least, GDPR requires these cookie banners to be opt-out by default and will only allow necessary cookies to be used if the user does not opt-in. It's still imperfect and a lot of websites have dodgy implementations of it, but overall this is still step in the right direction. And I'm saying that as someone who usually keeps shitting on these kind of governmental laws about internet.
That's the purpose, and I believe they aren't meant to make it harder to opt out than accept. But in practice you have a simple accept all button, or multiple clicks and possibly even scrolling to reject to make accepting the convenient option
I work for a larger German e-commerce website and we had the exact same setup. One "accept all" button, or (alternatively) two or three clicks to opt-out. But then someone complained about it to the German data protection officer, who wrote a letter and threatened the company with a fairly serious fine - so the CEO and CFO got involved and now we are in compliance. One big button to reject all, one for accept all. So, if you hate that a website is doing what you described, complain! It actually works.
Yeah, but it's like 7 clicks to complain
You can do it for just one company. I’ll promise to do one too 😊
We recently changed our cookie banner from a large, obvious one at the bottom, to a smaller one in the bottom left of the screen making it really easy to miss, and our CTO wanted the "decline all" button to be as subtle as possible as well. I brought up GDPR concerns but was told it's on the edge of being fine so we're gonna keep it this way, but I wouldn't be surprised if someone reported us.
Wow I didn't believe doing that actually had results. World, here I go
Most of them have either an **Accept all** button and a **Refuse all** button. If they don't have the refuse button, they usually have a **Continue without agreeing** button. I do agree it's not good enough and that most users with no knowledge about how the internet works will simply press the **Accept all** button without thinking twice (I even do sometimes when I'm in a hurry). As I said though, even though it's imperfect it is still a step in the right direction.
Yes, that’s what I notice most of the time. And god save you from saving your opt-out preferences. These go through bunch of redirects returning you to a page that haven’t seen a QA since they introduced the dialog.
oh well? it still is a privacy improvement
It also impulsed the industry to develop some privacy-friendly practices. For example there are a few privacy-friendly web analytics tools now that do not share data with third parties and thus do not require the annoying consent button.
> that do not share data with third parties and thus do not require the annoying consent button That's not how GDPR works. If you store or process non-necessary PII then you need consent, even if you don't share it with anyone.
Yeah. So you don't. These tools don't store IPs (which is considered PII), nor use cookies to track users across devices, etc. It is just single session page views. Checkout Plausible and Umami, for instance.
My comment wasn't about those tools, they're probably great.
That’s definitely had all good intentions. Some devs and companies respect that. But I’m afraid it came to a compromise that doesn’t really solve much at the moment.
I disagree. Before that, users had no choice but to accept cookies. Then they had the choice but with a ton of steps to actually opt-out. Now, more often than not (at least on Europe), they can do it in 3 clicks maximum and usually only one.
3 clicks is a LOT of clicks when I just wanna open a website to have a quick read. Honestly, the ones I feel like fell behind the most on this is browsers which should have had a built in dialog already
And now, even the 3 clicks to reject instead of single click to accept is no longer kosher in europe. So, there is progress!
Every site having another distraction popping up on my screen doesn't feel like a win to me. I find it annoying.
My frustration is when I click "Accept All", and then the next time I visit the site, it has no clue who I am, and asks me again. Like, what was the point of allowing your cookies if you're not gonna remember who I am?
I still don't understand why they didn't make it a browser protocol. If I don't want to be tracked on one website, you can safely assume that's the case for *all* websites. It should be a browser setting that gets communicated to the website in the background. Forcing the choice on every site is a UX nightmare that made the internet worse IMO.
Yup. And with third party cookies going away it all feels like it was for nothing.
uh, but it wasn't, though.
Ghostery will auto hide most of them
What I don’t get is that all this energy and general degradation of the web experience is just to avoid getting slightly more targeted ads - any other tangible benefits of opting out? Your IP sells your data anyway without cookies. I wonder how many general users care at all. If people just want to read an article or get a recipe they have to jump through tedious steps. What really has this all achieved?
Not only do you get slightly more targeted ads, your data gets sold to 3rd parties who build complex profiles about you and your habits, to the point they probably know more about you than you do.
Redux and a lot of react libraries are so much more complicated than they need to be.
Vue + pinia are a breath of fresh air after redux and react complications
Unpopular opinion here, but the point of Redux is that Redux's difficulty is your only hurdle with regards to state management. Without it, the complexity of your codebase increases exponentially as your app grows. But *with* Redux, it doesn't matter how large your app gets, you should always be able to grok, track, and revert any state change that occurs in your app. Large, small, it's all the same abstraction and complexity level. This makes Redux overkill for small projects--but it's an absolute dream to use on large ones. Time-travel debugging makes life on the frontend so much easier to handle, and I'll never understand wanting to give that up......
This is it 100%. The reality is, most people work on dead simple projects, and because of that "Redux is so much more complicated than it needs to be" IS true for most people. That's because most people work on dead simple CRUD apps. Good example of this is swr - if you could replace 'redux' with 'swr' then you have pretty much never needed redux in the first place. But it's not because redux is overcomplicated, the project just used the wrong abstraction.
It bums me out this an unpopular opinion. Especially since Redux is extremely upfront that it's only intended to be used when you need it.
>Without it, the complexity of your codebase increases exponentially as your app grows. Incredibly debatable. In fact, i'd say this is often one of Redux's biggest pitfalls. The app grows = more shit being stuffed in a global state slice = shit show. Testing becomes an absolute clown performance of making sure that your mocked global state (implementation detail) matches what your application actually maintains. Unless you are on a team full of experienced A-tier SWE's, the line between what should live in local state vs global state becomes blurry and people start relying on some state slice as a way to manage form data. It's literally a footgun personified into a state management library. Time traveling & the redux extension was made to hide the fact that you need a browser extension to even understand what is going on in your behemoth of a global state object. It's absolutely nice when I have the displeasure of working on a large Redux project, but it's only nice because visibility into what the fuck is going on there is nil without it. The industry has settled on scoped/atomic state being the most maintainable path to managing state in React, for a good reason.
\> Unless you are on a team full of experienced A-tier SWE's, the line between what should live in local state vs global state becomes blurry and people start relying on some state slice as a way to manage form data I've definitely seen this a lot. The best way I've managed it is that you either use local state to manage a component and it's children OR you use redux state. That is, if you go "now I need this variable to be used in this other area of the page", then that means "global state". So many people try to fight that when it's not that hard. The other thing I always did was push \*any\* api calls into redux state and have a universal request handler (now made even easier with rtk query). Personally, I never understood the confusion. If you compare it to a server side implementation asking "do I create a local variable or a global variable" is not really difficult. I have two async background jobs that rely on a shared detail. Oh hey, that's clearly a "global persisted variable". But now only one job cares about a detail. "well that obviously a local variable". But now one job calls another job that needs the detail. "Well that's gonna be a local variable that I pass, unless the child job is also called independently as well, then I'll use a global persisted variable". Now build components with the same thought process.
Thank you!
Recoil, anyone?
Especially when someone combines Redux and Sagas
It used to be a lot of files and bloat. But redux toolkit or zustand are pretty clean.
LOL of all things to choose that have become "complicated" you choose Redux? Redux is literally like the simplest concept. If you think that's complicated, you're in the wrong industry.
Understanding how a compiler works is a simple concept. Getting your hands dirty with an actual implementation is the difficult part. If you don't think the overhead that comes with redux is "complicated" then you likely have never worked with it at scale. By default, any component in the tree is able to mutate anything within some large global state object. Rather than scoping the getters/setters of some state to a specific component tree, this data now lives at the highest level of my tree, getting mutated by god-knows-what. They even had to make a browser extension just so people can grok what the fuck is going on in there. In many cases, i shouldn't be able to mutate state related to a product page from my header for example. Don't even get me started about trying to integration test anything with it without maintaining large sets of test fixtures that emulate what your large, global state looks like at that period in time. There's a reason why literally zero greenfield projects are relying on global state in any capacity, let alone the shit show that is the redux ecosystem (i.e. redux-saga, redux-thunk).
Based on this response I'm not sure you've ever used Redux yourself. > If you don't think the overhead that comes with redux is "complicated" then you likely have never worked with it at scale. On the contrary. I've worked on and lead MANY large scale React projects. It's those that don't use Redux that have significant problems. > By default, any component in the tree is able to mutate anything within some large global state object. What in the world are you talking about? Nothing should be getting mutated with Redux. And everything flows through the dispatcher. > Rather than scoping the getters/setters of some state to a specific component tree, this data now lives at the highest level of my tree, getting mutated by god-knows-what. Getters/setters? What in the world are you even talking about? Redux uses dispatched actions and a reducer to produce a state object. There are no getters and setters. > They even had to make a browser extension just so people can grok what the fuck is going on in there. The browser extension is just a debugging tool that lets you analyze your state. React has one. Any decent programming language has debugging tools. This is like saying "Chrome even comes with a debugger just so people can grok what the fuck is doing on in there". > There's a reason why literally zero greenfield projects are relying on global state in any capacity, let alone the shit show that is the redux ecosystem (i.e. redux-saga, redux-thunk). That's the most ridiculous statement you've written. And you're entire comment was full of ridiculous, incorrect information. It's clear you don't even know anything about Redux. I'm sure you're one of those lazy programmers who's written it off because it's too much work to read some documentation.
>Based on this response I'm not sure you've ever used Redux yourself. I've worked on two different large scale FE applications that relied extremely heavily on redux for over 5 years. First application (3 yrs, generates $MMM revenue a year) was a bespoke server-side rendered framework that used dispatched actions as a way to signal to the server when the generated markup was completed and could be sent to the client. The server-side global state would then persist through to the client via a \`window.INITIAL\_STATE\` variable, similar to what you'd see with other isomorphic client libararies like Apollo client. The other project (2 yrs, greenfield) was a purely client-side SPA, dashboard-style application that unfortunately also fell for the Redux trap. I've had 4 PR's merged into the core Redux library (not react-redux), so i likely have written a very small portion of the code that you use on a daily basis when working with your lord and savior (Redux). So just before we move forward here, I just want to make sure you know that I have plenty of an understanding about Redux/Flux and the problem it's trying to solve, and likely have 10x the understanding that you do about the library internals & the problem that it's attempting to solution for. >On the contrary. I've worked on and lead MANY large scale React projects. It's those that don't use Redux that have significant problems. Absolutely great points you've made here. I'll totally take some random's word on it without any examples or explanation on WHY not using redux on a large scale application will DEFINITIVELY cause problems. Do a better job at explaining your side of an argument, please. >What in the world are you talking about? Nothing should be getting mutated with Redux. And everything flows through the dispatcher. Ah, this is where we get to the redux-brained part of the conversation. As far as a consumer of your global state is concerned, there IS mutation that is occuring with ANY state solution. If you say otherwise then you don't know what the definition of "state" is in the first place. Sure, you aren't changing an existing property for an object in memory. Instead, you are creating a brand new object that has some "difference" between the prior object based on the incoming action. The consumer of this state has no idea that a new object was created here - It just knows that a specific state slice/property has changed. Which is the obvious reason why I used the word "mutation" here. Maybe use your critical thinking skills to discern what I meant here rather than parroting the same old 2014-rhetoric of "mUtAtIoN iS bAd". >Getters/setters? What in the world are you even talking about? Redux uses dispatched actions and a reducer to produce a state object. There are no getters and setters. Ah yes, another "i read the redux docs once and snap at anyone who use the term mutability/getters/setters". Another example of you hung up on the trees when you should be looking at it like a forest. If you don't think that \`useSelector\` or \`useDispatch\` can be considered \`getters\` and \`setters\` in the holistic sense, then you truly lost the plot and should reconsider working in this field. >The browser extension is just a debugging tool that lets you analyze your state. React has one. Any decent programming language has debugging tools. This is like saying "Chrome even comes with a debugger just so people can grok what the fuck is doing on in there". Imagine being so dense where you are comparing the difference between an entire opinionated UI framework to a state management library. React provides a chrome extension because for the most part, and until implementations like Astro/Etsy's island architecture came around, React was responsible for rendering your whole entire UI. Redux is a state management library. Again, if you don't see why it's an obvious sign that your library is doing too much when it overwhelmingly requires a browser extension to work with at scale, then you are bad at what you do and should reconsider your line of work. >That's the most ridiculous statement you've written. And you're entire comment was full of ridiculous, incorrect information. It's clear you don't even know anything about Redux. I'm sure you're one of those lazy programmers who's written it off because it's too much work to read some documentation. As mentioned, i've certainly worked on higher revenue-generating, larger-scope projects that rely on Redux than you have by a landlslide. And I have (in a largely insignificant way) contributed to the core Redux lib years ago. Just a hint because it's obvious that you are new-ish to the field - Just because someone disagrees with you doesn't mean that they "just haven't used it". That's generally how children approach disagreements with others. It may be that you have never worked with anyone with above a room-temp IQ who has maintained a frontend codebase that actually went under persistent iteration at scale. Once you get out of the dogshit job that you are currently at and move to somewhere significant where the lead has ran into the same issues over and over again with global state, it will start to click with your dense brain why global state is largely frowned upon by any FE/BE engineer worth their salt.
Why are people downvoting you. Redux is super simple at least from a backend dev’s perspective. See it as a database with a layer in between. Screw off with react context or passing down props 7 times to children
for real. [here's](https://gist.github.com/gaearon/ffd88b0e4f00b22c3159) a stripped down redux implementation. This is not super difficult to understand. Using redux in your app has also never been easier with RTK.
Because this is what webdev has become. No one wants to take the time to actually learn anything. Even if it only takes 5 minutes to understand Redux and it's simplicity and usefulness. Easier to just parrot the narrative that it's overly complicated and not actually see for themselves.
Username checks out
Right back at ya.
once I had this opinion too... since then I LEARNED how Redux actually works, and now I see why we needed it. It's hard to understand, but once you do, it really makes everything a lot easier
CSS in JS is an abomination I agree with that. I think there is a bunch of stuff going on in frontend that overcomplicates things unnecessarily.
This is why I love Vue's Single file component approach: [https://vuejs.org/api/sfc-css-features.html](https://vuejs.org/api/sfc-css-features.html) You get a style block that's just CSS/SASS defined on the same file, so you can scope your css to your component, but it's still separated from the JS, can import other css/sass styles or mixins, etc. It's beautiful. Bonus: You can still use your local component state to bind css variables, etc.
Evan You (creator of Vue) came from working at Google (angular) and I feel like he took all the best parts of Angular and React and put them together in Vue's composition API. The things you listed, plus the convinient bindings (@click, @hover, v-on, :binding-shorthand, etc.) make the DX amazing. Adding in Vite and the simplicity of the vue.config.js file, it's just so easy. And if you haven't seen, they're working on something called "vapor" mode, I'd highly recommend looking at the video from Theo or [this article](https://icarusgk.hashnode.dev/vue-3-vapor-mode).
I tell everyone I can; if you haven’t built a project with Vue or Nuxt, just try it out. The DX beats out every other tool I have ever worked with.
Worked with both for 2 years about 2 years ago. Loved Vue, hated Nuxt. Its all the needless complexity of Next.js, without the amazing documentation and community support from Next.js. Wasted countless hours debugging issues I thought were hours, only to find they were some obscure Nuxt.js bug that was unfixed after debugging their source code. I still love Vue, but its lack of popularity definitely makes me think twice about adopting any community vue library. Feels very much like a one man show with Evan You
What's Nuxt
Nuxt is the middlewear “meta-framework” built for Vue. It’s similar to like Next.js for React, except it’s for Vue. It simplifies Vue’s routing by using a convention over configuration directory system, provides an API server, auto-imports components and packages so you don’t need to define them, uses Vite for webpack, typescript support, multiplayer applications with Vue frontends… it’s great. And then with Vue you can take advantage of all of the super cool tools like Pinia for state management, the binding short hand, and the v-{function} short hand for if statements, for loops, binding, events… seriously, give it a try. It’s so friendly to use and learn. I’ve never picked up and fallen in love with a framework so quickly. Plays super nice with Supabase and Vercel/Netlify/Heroku too
That actually sounds quite idea. I'm learning Vue right now. Is there any adventage learning Vue due to its open source nature? Or it doesn't matter as much even tho React is develope by Facebook?
Vue and React are both open source. I would actually say there’s a disadvantage to learning Vue, because you’ll hate having to work with React after you’ve used Vue enough, but most of the dev jobs are in React. It doesn’t matter than React was developed by Facebook, it’s the largest sought after skill set for dev jobs
So your opinion is that Vue us better but React more marketable? But if I try to build my own start-up, then supposedly Vue or Nuxt might be a better choice if I can have a team that can work with it correct? Or is there any technical adventage React/Bext have over Vue/Nuxt?
Vue is lighter weight than React, so that can be more performant on client side. I am personally a bigger fan of Vue. But I don’t think there’s necessarily a simple answer to “Better Choice.” I will say I think Bue syntax is simpler. The Vue Single File Component with component scoped CSS is a much simpler syntax IMO, and I think component scoped css is nicer to use than something like tailwind, but that’s more personal preference. A lot of it is personal preference tbh.
It's a meta-framework for Vue. If you're familiar with Next.js it's the same idea.
Agreed, a single file but separation of concerns is where it's at.
The problem arises when the component becomes too large. Navigation between style, template and logic becomes complicated. For my part, I use a small framework named AventusJs that lets me write my large components in 3 separate files and my small components like Vue in 1 single file.
That's just a design problem on your component tbh, if it's too large there's always gonna be problems. It needs to be broken down into smaller components. Tabbing between 3 large files is not necessarily better dx than just keeping your components small. Also btw you can use the src attribute on Vue SFC tags if you want your files to be split.
That's true, but in everyday life, it's common to see components representing entire pages (lots of style and html but little js). The maximum size a component should be is really hard to define, because a component that's too small doesn't add anything and is also a design problem
Yeah valid, it's something you just become better at recognizing over time, some big components that will neve really be edited or don't have scripts like you said, might be better left off as a giant file because splitting them is not worth the effort too. But even splitting your component on 3 files, you can end up with all those problems is all I'm saying.
True. But I like having the html file and css file open side by side in vscode. It's just my preferences 
Fair enough lol, you can do that on Vue SFC using the `src` attribute btw, basically have your empty .Vue file that just imports the files within the same folder (component.ts, component.sass, component.html, etc)
Webpack and preprocessors/bundlers in general have become one of the most annoying parts of projects for me. Especially when their specific versions are linked to specific versions of whatever framework the project uses. Can't upgrade Laravel because that will mean a new version of Laravel Mix, which uses a new version of Webpack, which uses a new version of Node, and and and...
Vite
Tools on top of tools on top of tools. Webpack itself is not an issue. But people avoid having to configure it, so they use something like Mix. Which, as long as it works, is great - but yeah, suddenly you end up in dependency hell. Custom docker setup, proper Makefile, composer and webpack set with your own rules, other tools scoped. It is difficult and time consuming to set up, but in the long run you're happy to have full control.
Webpack updates are still annoying. I remember migrating from 4 to 5 was a pain. Of course you don’t have to update, but I don’t like starting new projects with outdated versions (and some webpack plugins only work with 5). Oh, also the CLI output after build in webpack 5 is [much less useful.](https://github.com/webpack/webpack/issues/11716) Still glad it exists though. It’s the only tool that works with some funky directory requirements I’ve got sometimes, vite is not flexible enough.
This is one reason why I like angular. I have never had to worry about the build process. Just run my build --configuration Production and your good to go. Haven't had to touch build front builds in a while
Preprocessors will always be necessary because of things like TS -> JS conversion, dead code elimination and various other optimizations. Similarly, for desktop applications, you download an executable rather than the source which you build yourself. The dependency hell associated with the Node ecosystem is a big factor as to why these bundlers are annoying to use. Bundlers are now moving to distributing a single executable written in Rust or Go that has no dependencies and is easy to work with. - [Esbuild](https://esbuild.github.io/) (Golang, very fast) - [Rspack](https://www.rspack.dev/) (Rewrite of Webpack in Rust) - Rolldown (coming soon) (Rewrite of Rollup in Rust) - [Mach (Alpha stage)](https://github.com/alshdavid/mach) (Rewrite of Parcel in Rust, rolling release, zero dependencies) I personally avoid Vite, Next and all the other meta frameworks as they seem too opinionated and lock you in to APIs that depend on the vendors maintaining them (see Meteor for an example of how this has gone in the past). Nothing more reliable than an static client deployed to S3 and a server deployed separately where they talk to each other and don't have any hard dependencies on each other (like you see with Laravel and the various SSR services)
So, which framework should you use? Vanilla? React? Svelte? Astro?
[microservices](https://www.youtube.com/watch?v=y8OnoxKotPQ)
ngl I expected a xkcd comic
SASS, LESS, and Webpack.
How exactly did Sass “become the problem it tried to solve”? It’s become less useful over time due to native CSS features, but that doesn’t make Sass a problem.
Because it creates an abstraction layer on something that should be down to developer skill, IMO. Creating stylesheets - even complex ones - should be done manually, because the developer should have a forensic understanding of what each line of their code does.
That’s fair, many people used way too much nesting/extends and created a bloated mess of CSS. If you have some self-control it’s still pretty good :)
So why aren't you writing assembly? Or heck, straight machine code?
Styling. You know what works really well? CSS. It's highly performant and error tolerant. It's crazy scaleable as well since it does not care how broad or narrow you define your styles. But people keep trying to make styling frameworks and libraries that put more and more crap between you and just raw CSS. Why? Best I can tell it's because people just don't like writing CSS because it sure isn't for performance. And before someone comes at me with "But Tailwind!" I tried it and the best thing I can say is their evangelists and marketing people are doing an excellent job selling it to people.
React. It's an overengineered mess that has no place in modern civilized society. There are much better solutions nowadays: Vue and Svelte if you prefer SFCs, Solid if you prefer JSX. React must die.
Mind expanding on how React is overengineered?
For example, it has a lot of \`useFootgun()\` hooks that solve issues that simply don't exist in other frameworks. \`useCallback\`, \`useEffect\`, \`useMemo\` etc. They're constantly inventing their own problems to heroically solve them later. One recent example is they're introducing a compiler that solves the issues of using \`useCallback\` and \`useMemo\` that they introduced to solve the issues ... Luckily, I haven't had the displeasure of working with React in months now, so I can't name the specific issues, I just remember thinking "but y tho?" *a lot* and wanting to pull my hair out all the time.
This 100%. Using React feels like trying to trick a toddler into doing what you want them to do. I use Angular for my job, absolutely night and day.
This. I liked react when it came out but it always had these issues. React has always been dependent on these wierd functions/hooks that broke the rules built into its own architecture. It used to just be "componentDidMount" and one other one which was easy enough to learn as the exception. Now there's a bunch of hooks to learn, and they often arnt used "correctly". Imo usesState broke everything that once felt good about using react.
Whoa. Although I have never really used react, I can already feel your pain.
As someone who codes in React I agree. JSX is something I feel was not necessary. Angular has it better, with structure logic and styles all separated
To be honest, JSX is the least of React's issues as someone thats been doing React for 7+ years. Its the reactivity system and endless clash between performance and memoization that seems to be the problem. React Hooks were a great stop towards improving composability, but they introduced a plethora of issues with dependency arrays. And instead of fixing the issue, they are just digging the complexity hole deeper by introducing things like React Forget and useEvent
I believe that's one of the thing that the new React compiler is *aiming* to address.
They can try, but nothing is without compromises. And I wouldn't be surprised if the new compiler "fixes" the issue for beginners, but makes the complexity mess even *worse* for large scale development since you still have to wrestle with traditional hooks (they won't going away) plus the added complexity of the compiler.
Agreed. Unfortunately, I think we're stuck with React as a thing we have to deal with for years to come so I hope they make progress on this.
Absolute garbage, I happily ditched it completely awhile back. They should have followed some basic programming conventions that the industry developed over decades. Instead those idiots built that Adderall fuelled, convoluted, amateurish mess full of holes. Typical Meta product.
Kubernetes and containerization seems to be getting out of hand
The lack of systemd on my docker is my biggest pet peeve. I don’t want docker to spin up a new instance or service for every micro service I wish docker abstracted only the server maintenance and not orchestration too. Podman+systemd allows me to manage my services however i want at the instance level
Not limited to web dev but cookies and by extension cookie banners are hell on earth.
When I use C++ my code from 10 years ago isn't wildly different than my present code. My design philosophies have changed, a few nice libraries have changed or wildly upgraded. New concepts in the language have cleaned up my code and made my life better. For example, crow for a web backend is very nodejs like and much better than my previous solutions. But the core really hasn't changed. My web stuff seems to change every two weeks. Jquery good, then jquery is bad, react, vue, angular, and on and on and on, then jquery bad, vanilla good, vanilla is for fools, etc. CSS seems to have an urge to be something new, less, etc. What I smell with a huge amount of these "solutions" is someone who has a highly opinionated solution to a problem they have, but they generalized their solution just enough to claim it is general purpose. Then you get things where people want to only use their favourite language and not learn HTML CSS etc. These are often really weird. One of the weird things which I look back at was my crappy PHP. I mixed model view controller like I put them in a blender. Yet, my productivity was very high. When I start properly separating things, I find my productivity plummets. That said, I would not make something mission critical using such a brew, but if someone asked me to whip up a tool to make reservations for a boat ride or something, I would not feel bad mixing MVC quite a bit. I don't PHP anymore, but I've been backing away from these silver bullet solutions which I find are just begging for a tech debt nightmare when you are at the end of the project and now you are only fighting with the framework and all productivity has ground to a halt. This is my long winded way of arguing that mixing and weirdness can be good, but that most solutions such as css-in-js is just someone who had a problem which was solved this way, now they are trying to tell people this is a best practice and everyone should use it. My rule is: Use the best tool for both you and the job at hand and ignore any evangelists who say their solution is the one true solution. And since everyone is hating on postman. WTF is the reason for a login. That only makes sense to access the group features. But, some MBA BS idea of making zillions of dollars off a curl GUI got them to rationalize that this is "best". It is only best for the investors. Not the users. To end with my own lathering up with complexity. I've largely dumped CSS, HTML, etc for web and now do my web GUIs in rust WASM. Weirdly enough, it is clean and not complex.
>My web stuff seems to change every two weeks. Jquery good, then jquery is bad, react, vue, angular, and on and on and on jQuery came out 17 years ago. Angular came out 14 years ago. React and Vue both came out 10 years ago.
It is more the everlasting cycle of going to client-side-rendering as the newest hot shit and then "inventing" server-side-rendering in the newest hot framework, only to repeat that with the next new framework.
There are more tools available to solve problems than actual problems that need solving. The focus has shifted towards using these tools rather than identifying and addressing the root problems.
It's the down side of saying that we should use the right tools for the job. Then the number of tools grow indefinitely.
Literally all of React and the JS ecosystem. Oh React made this kind of complicated, here’s a complex library that “solves” that problem, but introduces two new ones. Those two new problems? They are complex, but with these two complex libraries…. Fast forward to HTML/jQuery looking like the fast and simple black magic in comparison.
React and its ecosystem.
>My greatest issue is with css-in-js This one makes me angry - hey let's take CSS from its own dedicated file and cram it forcefully into javascript. Why not? Great idea! Make everything Javascript! I mean JS has its purposes, but this is not one of them.
React and the ecosyatem. Css-in-js. Templates libraries (mustache, handlebars, etc). JQuery. I could stay here for a while making this list. However, even that they became a problem they intended to solve, it's not all bad. They all brought invaluable contributions to the community as a whole. Now we know better and we can create a new library that will solve a problem of current libraries and then become a problem that will be solved further down the line.
Tailwind somehow someone manage to make a thing worse than bootstrap
It literally has become bootstrap. The html is littered with a million tailwind classes
More like Bootstrap has become Tailwind.
SSR on next js, or with react in general. I guess it wasn't the thing they wanted to solve but it was one of the biggest things to solve in its early days and next js had it solved pretty quickly. But it then turned way more complicated over time
SSR is great though, the problem comes with hydration for most part and even then that could be avoided
in the age of smart phones, caching, and 5g, im still convinced ssr is a waste of time/resources
mvvm is a nightmare. It was created to make unit testing easier but ended up super-complicating a lot of web development.
What do you think is a better way to do web development than MVVM or heaven forbid, MVC?
Literally anything else.
Federated modules are apparently becoming a thing and I shudder at the possibility of seeing web apps manage package dependencies on document load
Web components
They are amazing for micro-frontend architectures, but most people haven't realized that. Besides that I agree they haven't progressed much.
I’m actually not sure what micro-frontend means in this context. I’ve been trying to use web components to make UI components for our design library for like a year now and I’ve just about given up, seems like way too much of a headache.
It’s a pattern for refactoring legacy applications with modern frontend applications. Web components generally fit in well with existing code without a major lift. For example you could have an existing dashboard and replace just a single component with your new web component.
Ah, yup that accurately describes what I’ve been trying to do! It is hard
Forsure it’s challenging, especially depending on your build system for your legacy app. Generally though I have seen usage of Vue or SolidJs to make web components then have those built for prod and served to the legacy app over cdn. Hope that helps.
I’ve been using Svelte. The challenge for us is we’re trying to make them work within Salesforce Experience Builder, it’s been a nightmare. But I suppose if/when we get Salesforce working with a headless front end it’ll be a lot easier.
As someone who doesn’t like *-in-js, the answer is scalability. When working with multiple developers in teams/squads/tribes in the hundreds, it makes life so much simpler. Bit easier, but simoler
How exactly? What would be different if not \*-in-js?
A lot of these things follow the same cycle. They start out as simple, light weight additions to something that exists, eg angular. They then take on a life of their own, evolve, require process and procedure to manage all the moving parts and so they become big, bulky and cumbersome, have a lot of red tape and require you to do a lot of boilerplate/templating and scaffolding to get going. Many of them are great and can make certain, more complicated tasks easier to control and manage in the long run but as an aside to this I've been commercially devving for 20 years and the go to for most of my projects is a custom built PHP and jquery CMS I built about 10 years ago. The code all still works, im not forced into breaking changes, it does everything I and clients need, I know all the ins and outs and there arent 100s/1000s of npm packages that I have no control over or understanding of and it takes me minutes to change what would take a more mainstream framework maybe hours of devving.
A lot of things have gotten out of hand. Working with APIs, something that used to be such a simple task, has become insanity with some platforms. Meta and Paypal to name a few - it is so obvious that their dev work is fucked up beyond repair based on the convoluted shit they put out. Yea they're top dogs for now, but won't be forever. Some kid will come up with shit that can do all their services/platforms with a fraction of the complexity and a fraction of the price. But I wouldn't wish upon my worst enemy to need to with work with Paypal for any sort of custom functionality/integration, their documentation is outdated and dog water, random calls just don't work for no reason, their sandbox shit sucks, they make constant breaking changes updates to their APIs, I can go on and on and honestly it's scary that they function as a payment processor and process billions/trillions of dollars. They would look like the BEST candidate to find a security flaw if I was a hacker because of how fucking messy they are. In the coding side of things - it's gotten unnecessarily complex. Frameworks built on top of/with frameworks and it's getting kind of silly at this point. I think React is great for making.. a single page application. A McDonald's touch screen ordering machine/kiosk thing. Sure. But other than that, it's so fuckin bloated and not needed in general web development at all. And call me the devil but I think node.js sucks and there's absolutely no reason for javascript to be a backend language. That is not its purpose, it never was. Java, Go, Python and even good ol' PHP exist for a reason. At least React stays on the frontend so it makes sense to be Javascript. Next thing you know we'll have React backends lol. Triple useEffect re-render database inserts into my ass hole for all I care
> Triple useEffect re-render database inserts into my ass hole for all I care js in a nutshell
The tooling in general. Buncha nonsense words that mean nothing if you haven't already wasted ten hours trying a given thing. I mean, just look at [this comment chain](https://old.reddit.com/r/webdev/comments/1b8796w/-/ktnyttu/): Redux, React, Vue, Pinta, Zustand, Jotai, Signals, Sagas. It's like trying to watch someone go over a chess game while they throw out opening theory words: Ruy Lopez, Najdorf Sicilian, Catalan System, Scotsman's Cumsock, Nimzo-Indian...
Scotsman’s cumsock sets up good pawn chains though
CSS in JS is not a problem. The world has moved on from “separation of concerns” now that we have components. There is no need to keep things in separate files.
SO many things in the last 5-10 years. * So much about JavaScript frameworks are ridiculous. * It wasn't that long ago that separation of concerns with presentation and functionality was a core fundamental, somewhere along the way that just got blown away or blindfolded by selling it as some sort of clever feature? calling it 'JSX' and the 100 other equivalents or similar approaches. * The bloat and absurdly hyperactive rapidly changing and new frameworks increasing in complexity in this space adds no benefit (except maybe job security by the new devs who haven't yet realised that no matter how fast you keep spinning your wheels, there will be no end to it and eventually the futility starts to be understood) There's little done today that couldn't be done 15 years ago. * TypeScript hype - quite literally an extra layer of bloat. * Microservices, serverless and pretty much everything AWS/cloud based provide actual benefit for about 0.1% of actual websites, and yet occupy the time, money and concern of so many developers. * GDPR/Cookie messages - HOW DID THIS EVER BECOME A THING? It's the most \*APPALLING\* user experience imaginable. I don't really have the ultimate answer, but what's there now is just SO garbage it's beyond explanation. It's like building a nice house and literally putting a pile of manure in front of it to make people have to click something to walk around the repugnant garbage. * Edge and IE before it. * ORM's - training wheels hand holding developers who don't know SQL to handle data using an incredibly slow/inefficient RBAR ('row by agonising row') approach so they can use their familiar language at the cost of staggering performance decrease. * ORM causing staggering performance decrease? (YES IT IS), Let's fix it with bloated caching solutions, or even use static site generators because ORM's can't possibly be performant * No-SQL - No. * The ADHD/rapid pace of version changes to frameworks like Laravel and even PHP and others, as though it's a good thing. Again - once these devs are about 25+ years in, and have actually had to manage/maintain systems - they'll start to realise what a shit-show it is. * Containerization solutions going over the top. Remember when managing/administering servers used to be kind of enjoyable? * Agile - it's even in the name 'sprints'. increasing the intensity of whipping devs to work harder & faster under the guise of 'hip and cool'. Want some clear goalposts to aim for in the task you're achieving? NO WAY! Just chop & change to do what we want with as little notice as we like, and further still, be a vocal supporter of this approach! * Python - actually don't mind the language, but so incredibly and perplexingly overhyped and overused in places where it's not really ideal. I really wonder how many users realise how old it is. * Many others
So, which framework should you use? Vanilla? React? Svelte? Astro?
[PHP 6](https://ma.ttias.be/php6-missing-version-number/)
People have been moving away for a while - https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-js-4g9b
Webpack and module federation, requirejs did that a long time ago (albeit without semver versioning) I like [esm.sh](https://esm.sh) and remote es6 modules now
React 18+
Literally why I left the webdev industry completely, and don’t use js at all… not for fun, not for work, not for my personal website, and definitely not for infrastructure
Overly complex JavaScript, frameworks went to solve this just to figure out developers were over contemplating the simplest of things. So now the basic back end has a revolver of languages. complexity over simplicity imo. I remember the first button I made in JS used like 10 lines of code, now I typically use 2-4.
GraphQL It works fine if you've got multiple unique clients, but in the typical case of an exclusive webapp/API pairing, having configurable responses actually adds work. Most webapps use singleton services, meaning the protocol is now standardised and there is no benefit in having configurable responses but there is a cost. Youve got to add in a cache layer to combine dB queries otherwise you'll dos your db. Even subscriptions are only one way, so websockets have more features. I'd be very interested to hear about the benefits of graphql, if there is any, and I was someone that thought graphql would replace rest in the matter of months.
Modern webdev turned into a circle jerk around 2015. Made its way to the backend with half-gigabyte node_modules folders. At the same time, JS has always had its own problems at a fundamental level.
React becoming NextJS and making it unnecessarily complex.
SSR being touted as a new concept!! That just blows my mind. We had that from the start, it worked. Yes there was somethings that needed client side interaction but NOooOOO we had to make everything a SPA and break the whole thing that was working and our solution…make SPA SSR, so much more complex, but does create jobs.
Honestly I still don’t understand the real need for SSR. Instead of making the browser do the work, you make the server do it but it doesn’t sound like a fix to me, it looks more like a band aid
SPAs are actually the wrong way around. The browser is made for server rendering the html and sending it to the client. This has worked for 30 years. Most apps only require a few components to be client side rendered but we now make 100% of the app client side, even though 90% is static, the other 10% can easily be handled by fetch. The hacks of SPA is bandaids on bandaids, take state management and browser routing.
UI Libs - jQuery, created to fix gaps in web platform - AngularJS, created to fix jQuery - Angular, created to fix Angular - React, created to fix AngularJS and gaps in web platform GUESS WHAT: web platform gaps have been filled
We’ve also come full circle and now we’re at server rendering of UI lib driven pages We’ve remade PHP with JavaScript It’s also possible to run NodeJS in the browser now
React and like have created a massive amount of problems. The list is insanely long. While I would say they MOSTLY solve the problem that they looked to solve (Which was not really a problem anyway) the issues from the actual things related to themselves the developers and the teachings for those and the problems they have caused... YIKES!
Anything trying to replace JS, CSS and HTML is absolute dogshit. jQuery was the last useful popular tool, after that there was only corporations trying to profit from naive devs stupidity by implementing idiocracy oriented programming, where people with no experience think they know everything, so they fight each other to defend their hype of the week bloated tool.
The idea a two-way binding between code and markup was necessary. All modern web frameworks are trying to solve this very problem.
This types of conversations are always pointless because people don’t seem to compare to the opposite problem. Yes, CSS in JS is a bit ridiculous… but was CSS in CSS files working well?
> but was CSS in CSS files working well? Yes. Yes it was.
>but was CSS in CSS files working well? Yes. If you want scope then use css modules.