5 ms·

This is precisely why you see this move from complexity. The younger devs are beginning to see it. Just like we dumped atrocities like SOAP and XML in favor of

This is precisely why you see this move from complexity. The younger devs are beginning to see it. Just like we dumped atrocities like SOAP and XML in favor of simpler and more ergonomic tech, this generation is learning - again - that complexity kills (and makes this job intolerable). Who knows, maybe software development is going to be fun again, even if for a few years before the new batch starts turning it into a mess.

asynchronous 3y ago
After kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.
- throw1234651234 3y ago
  Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSideProps' function that will do magic and generate component props, but it has to live in the page, so the page gets extremely bloated, oooo." I hate Next. And I realize "hate" is a strong word that takes some earning.
  - cccybernetic 3y ago
    The API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.
    - throw1234651234 3y ago
      Could you elaborate on the last point or link me please? I disagree on the convenience point - it's bloat and not in the sense that people say "IDEs are bloat". It's regressive in going back to an MVC pattern in a framework that's meant to be an SPA and completely violates the "There should be one, and only one, way of doing things" principle in that it adds confusing options that people end up using in practice.
      - satvikpendem 3y ago
        > Could you elaborate on the last point or link me please? https://nextjs.org/docs/app https://nextjs.org/docs/app Next.js is pretty convenient, not sure why people find it so inconvenient. With the pages directory, each page is its own page, just like in the PHP days. Why do you think it's an MVC pattern? I don't use Next like that at all, it's just React.
  - ttfkam 3y ago
    Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to. It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left. const { count, setCount } = useState(0); becomes let count = 0; There is no more useMemo(…) or useEffect(…). They just don't exist. There's no need for them. State management "just works" by using a store variable like $store. No more explicit subscribe and then having to remember to set up an event callback to unsubscribe and avoid a resource leak. Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.) Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
    - throw1234651234 3y ago
      I think you just sold me on Svelte, and I am not joking - I haven't tried it yet, but I want to now.
      - ttfkam 3y ago
        https://learn.svelte.dev/ https://learn.svelte.dev/
      - dihrbtk 3y ago
        the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.
        ttfkam 3y ago
        Yep, the amount of UI component libraries for React is truly staggering. I myself am more of a clean, standard HTML with PicoCSS kind of dev, but that model doesn't work for everyone. Some might be surprised how much plain old HTML and the ease of development for Svelte components narrows that gap, but I'll be the first to admit the gap absolutely exists.
        3y ago
danjac 3y ago
It's not happening fast enough. For greenfield projects, new startups, sure. But the rest of us stuck in legacy-land the toxic waste dumps of these over-engineered behemoths will be with us for years to come.
- throw1234651234 3y ago
  See my comment above - it's greenfield projects too. Company I work for had a nice .NET Core / Gatsby React set up with reasonable Microservices on Azure. New leadership came in. Rewrote it "all" (3 years in so far) into a wait for it, MONOREPO! in Python (at least they used FastAPI), Next.js (just to have a useless API which calls other APIs, because apparently 'cookies are more secure than JWTs' (I guess they think not being able to fetch them in JS is somehow security), and AWS. So far it has half the functionality, 10x the libraries, 100x the confusion, but hey, at least we went from 5 devs to 100 just so everyone can be confused TOGETHER!
2devnull 3y ago
It’s the interest rate. When rates are low, devs are paid to build complexity, new frameworks, tools, languages. If the interest rate stays low other devs will get paid to play around with those new frameworks, build more complexity on top and so on. SQL, html, C … get things done. When rates go up, these non-bs technologies are incentivized. Paying devs to create new frameworks/apps/products just so that those devs are happy and don’t go work for the competition is what results in complexity for complexity sake. Those who hitch their success to the latest greatest shiney new bs tech are the same who used to sneer at those who didn’t cover their webpages in flash animation. They make the mistake of thinking the current way is the best way. It’s not old vs young, these two mindsets exist across different stages of the lifespan. Generally speaking, older people have more data and will therefore spot the patterns/cycles a bit easier.

asynchronous 3y ago

After kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.

throw1234651234 3y ago
Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSideProps' function that will do magic and generate component props, but it has to live in the page, so the page gets extremely bloated, oooo." I hate Next. And I realize "hate" is a strong word that takes some earning.
- cccybernetic 3y ago
  The API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.
  - throw1234651234 3y ago
    Could you elaborate on the last point or link me please? I disagree on the convenience point - it's bloat and not in the sense that people say "IDEs are bloat". It's regressive in going back to an MVC pattern in a framework that's meant to be an SPA and completely violates the "There should be one, and only one, way of doing things" principle in that it adds confusing options that people end up using in practice.
    - satvikpendem 3y ago
      > Could you elaborate on the last point or link me please? https://nextjs.org/docs/app https://nextjs.org/docs/app Next.js is pretty convenient, not sure why people find it so inconvenient. With the pages directory, each page is its own page, just like in the PHP days. Why do you think it's an MVC pattern? I don't use Next like that at all, it's just React.
- ttfkam 3y ago
  Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to. It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left. const { count, setCount } = useState(0); becomes let count = 0; There is no more useMemo(…) or useEffect(…). They just don't exist. There's no need for them. State management "just works" by using a store variable like $store. No more explicit subscribe and then having to remember to set up an event callback to unsubscribe and avoid a resource leak. Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.) Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
  - throw1234651234 3y ago
    I think you just sold me on Svelte, and I am not joking - I haven't tried it yet, but I want to now.
    - ttfkam 3y ago
      https://learn.svelte.dev/ https://learn.svelte.dev/
    - dihrbtk 3y ago
      the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.
      - ttfkam 3y ago
        Yep, the amount of UI component libraries for React is truly staggering. I myself am more of a clean, standard HTML with PicoCSS kind of dev, but that model doesn't work for everyone. Some might be surprised how much plain old HTML and the ease of development for Svelte components narrows that gap, but I'll be the first to admit the gap absolutely exists.
      - 3y ago

danjac 3y ago

It's not happening fast enough. For greenfield projects, new startups, sure. But the rest of us stuck in legacy-land the toxic waste dumps of these over-engineered behemoths will be with us for years to come.

throw1234651234 3y ago
See my comment above - it's greenfield projects too. Company I work for had a nice .NET Core / Gatsby React set up with reasonable Microservices on Azure. New leadership came in. Rewrote it "all" (3 years in so far) into a wait for it, MONOREPO! in Python (at least they used FastAPI), Next.js (just to have a useless API which calls other APIs, because apparently 'cookies are more secure than JWTs' (I guess they think not being able to fetch them in JS is somehow security), and AWS. So far it has half the functionality, 10x the libraries, 100x the confusion, but hey, at least we went from 5 devs to 100 just so everyone can be confused TOGETHER!

2devnull 3y ago

It’s the interest rate. When rates are low, devs are paid to build complexity, new frameworks, tools, languages. If the interest rate stays low other devs will get paid to play around with those new frameworks, build more complexity on top and so on. SQL, html, C … get things done. When rates go up, these non-bs technologies are incentivized. Paying devs to create new frameworks/apps/products just so that those devs are happy and don’t go work for the competition is what results in complexity for complexity sake. Those who hitch their success to the latest greatest shiney new bs tech are the same who used to sneer at those who didn’t cover their webpages in flash animation. They make the mistake of thinking the current way is the best way. It’s not old vs young, these two mindsets exist across different stages of the lifespan. Generally speaking, older people have more data and will therefore spot the patterns/cycles a bit easier.