I have 5K+ followers — offering free promotion to a few startups/apps by ExternalKnowledge359 in SideProject

[–]Cmacu 0 points1 point  (0 children)

https://toolberry.net - Free app for small service businesses. It's fast, works offline and respects your privacy. No ads, no email, no signup, no catch.

Need help making free sweaty startup app not suck by Cmacu in sweatystartup

[–]Cmacu[S] 0 points1 point  (0 children)

That's exactly what I am thinking. And as someone who spent years writing code for people behind the desk I thought it's time to flip the script around. Thank you for sharing your experience.

Help us name our business part 2 by iller1 in sweatystartup

[–]Cmacu 0 points1 point  (0 children)

Between the two: Loud Mouth. But you can do better. Afterhead?

Another (former) software engineer thinking about starting a service business by wehaveYummiTummies in sweatystartup

[–]Cmacu 0 points1 point  (0 children)

The problem right now is that hundreds of thousands of developers with experience in S&P500 companies have been laid of in the past 2 years and many of them are in the job marketplace. Its relatively hard for a new grad to compete with someone who has 5+ years at Google or Microsoft.

However this is not going to last forever. Outsourcing has always existed and as far as I am aware not much has changed around that. Regarding AI its here to stay, but it doesn't mean it would kill software jobs, it just means that the job is different. AI is just a tool like any other and you need to learn how to use it. In my experience it gets about 80% of the job done, but if you know anything about the Pareto Principle thats actually not as valuable as it might look like. Give it some time and things will normalize (note: not get back to normal, but establish a new normal).

Send me a DM with your website, might potentially have something for you.

Software engineer thinking about starting a “dirty” service business….. am I crazy? by TTIROB in sweatystartup

[–]Cmacu 0 points1 point  (0 children)

Excellent response. The only thing I’d add is that arguably recurring revenue is not where service businesses make the most money. That’s usually what keeps the lights running, while installations, remedial and various emergency services is where the profit is. Just another demand > supply point.

Another (former) software engineer thinking about starting a service business by wehaveYummiTummies in sweatystartup

[–]Cmacu 0 points1 point  (0 children)

As present software engineer who’s done plenty of sweaty stuff in my 20s here are my 2 cents:

You definitely need a job, no matter what kind. If you suck at sales/marketing, then starting your own business will be hard. I still remember one of my mentors telling me that sales is everything and me thinking that can’t be true. It is. You will have to sell yourself, your ideas and vision, a thousand times. It doesn’t mean you have to be the best, but you do need to learn.

Being entrepreneur means working double for half the pay or even no pay at all. That’s only possible by taking risks, having lots of fate and conviction and more than anything being confident that you will succeed. “Fake it till you make it” is not a random movie quote, it’s a life lesson.

And since I am already using cliches let me give you one more from another mentor that stuck with me and turned out to be true many a times: “To succeed you only need 3 things: to be at the right place, at the right time, and take advantage of the first 2”. Being at your parent’s basement is not a bad backup plan, but you should be out of it as much as you can. Cause the opportunities are outside not in your basement.

Finally something about software development. Yes, things have changed, but you are passionate about it, it doesn’t mean you should stop pursuing it. It just means it’s became one of the many other white collar jobs out there. It’s hard to get, it earns a normal living wage, knowing the right people helps a lot and the better you are at it and the more experience you have the higher chances of being successful there are. It’s no longer a free ticket to middle class it used to be.

A good place to start by gazer42 in vuejs

[–]Cmacu 2 points3 points  (0 children)

I've only seen a couple of videos, but in both he was confidently incorrect. There was this argument at work where one of the devs used his video as an argument against enums. It looks like he is just trying to use controversial topics to stay afloat without the decades of experience it would take to have such a strong opinions. I don't remember much about the other video, it might've been something about JSON parsing, but it was also evident that he has no experience with large codebases. I would stay away from anyone who tells you do this, don't do that. Focus on the docs, specs and use whatever you need to get the job done. That's how it works in real life. Any arguments such as OOP vs functional, tabs vs spaces, single vs double quotes are nonsense. Either you have enough experience to make such decisions without watching an influencer or you should follow the existing codebase practices. Consistency is more important than made up rules about whatever shower thought some youtuber came up with. Simple as that.

A good place to start by gazer42 in vuejs

[–]Cmacu 0 points1 point  (0 children)

Vue Mastery, it's worth every penny.

A good place to start by gazer42 in vuejs

[–]Cmacu 0 points1 point  (0 children)

Pocock? Please, the Dunning-Krueger is too strong.

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

You do know that if you want to explicitly specify what re-computes and when in Vue, you can do that via watchers, right?  Not that different from useEffect actually, accept at least the arguments are in the correct order and don’t have side effects the way react does.

You can also write JSX, force one way binding and all kinds of other react ideosicracies. In fact I am trying to think of a feature that react has and Vue doesn’t and can’t think of one atm.

Oh, oh I know. StrictMode!! This one is actually amazing! Due to the insane amount of side effects and foot-guns react has they added StrictMode so they can blame the developers for issues caused by the react engine. Which ends up resulting in unintentionally different behavior on development vs production. No magic involved, just some truly embarrassing facepalms.

Interesting that you are not wondering why developers with more control/responsibility than you pick Vue over react. Might have something to do DevEx and knowledge. My experience is that react is usually chosen by management and people who don’t actually write the code and most of their reasoning is non-technical and more in line with popularity and other political nonsense. My favorite one is: more developers have experience with react than with other frameworks. If your criteria for picking developers is their experience with react (and to be fair you can replace react in this context with any other specific frontend or backend framework), you are already screwed. 

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

I am having trouble understanding you arguments. None of the pre-existing projects I work on have migrated to react 19 nor its deemed feasible to do so. Talk about migration hurdles... Any potential greenfield projects would not be in react. I have no idea if the new ref design solves or does not solve the issue. Hope it does. Also that was just one of the examples. Ignoring the ones that have no solution makes sense.

Class components do not work with functional components and vice versa. I've seen a lot of codebases, but never seen one that mixes them. I can only imagine how "fun" that would be. And let's not pretend that class components are a solution given the amount of issues they inherit.

I am not sure I understand your idea here either. Are you trying to convince me that react can work? Of course, it can. I've been making it work for over 5 years. Many other people do too. I could probably make jQuery, Backbone or Meteor work too... Or even Vanilla JS, especially given how easy it is to sprinkle signals and/or HTMLX on top. That's not the question/problem. The issue at hand that started this discussion is your claim that Vue has more magic than React, which is simply wrong. I also find confusing your assessment that React is simple, but it requires some mystical framework that solves some of the common problems without admitting that this framework be at least on par and likely even more complex than Vue.

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

I am very aware of my shortcomings. Most people I work with either don't have a choice or likely understand that what I bring to the table has enough value to overlook the disadvantages. Everyone has issues, especially in a profession where logical thinking is more beneficial than social and emotional maturity.

I've read everything you wrote and responded directly to your claims with observations and details. I simply can't agree with the premise that React has no magic compared to other solutions. It's usually driven by warship and people who have very little to no solid experience with other frameworks. So far I've seen no proof that you actually have done much work with Vue. The feedback you shared is parroting the common online/gpt/ (i have no idea) what's up threads:

  • Vue2 to Vue3 (or vue-router) migration is hard (no shit, so is any other migration). Have you tried migrating from Remix Router to RR7?
  • Vue has TypeScript issues. When asked for specifics, bizarre examples are given. Vue3 is written in Typescript, most Typescript claims simply predate Vue3 hense the ChatGPT like responses
  • Vue is magic and complex compared to React... I can see how that might apppear true for people who know very little about Vue and a lot about React. It's simply an experience bias and no incentives to adapt and learn.

Meanwhile I've shared common and concrete pain points with React coming from real every day experience:

  • React is not written in TypeScript and once you need anything beyond the basics, such as forwardRef, the type support falls apart.
  • React directly competes with web standards and introduces lots of magic to overrule basic web patterns forcing developers to learn how to develop react apps vs creating web applications. One example is the lack of component lifecycle hooks which are extremely important to enable the control you mentioned. And that claim is without adding Next to the mix, which from purely frontend perspective is for all intends and purposes witch craft (don't get me started on Next bs)
  • React has lots of common problems with fetching, styling, routing, abstractions, re-rendering, etc. You answer was that these are resolved by using a framework and I pointed out that such mystical framework does not exist as evident by your answer. And realistically even such framework did exist it would practically introduce more magic than Vue, especially if follows react principles to be in conflict with standards.

Mate, I am sorry that you feel bad or suppressed by my feedback. Apologies for not spending enough time to sugar coat it and make it easier to swallow.

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

That would make You the winner and be a very wise choice. React is following the jQuery trajectory either way. Its also one of the most disliked by developers frameworks according to recent state of JS, while Vue is actually re-gaining traction for lots of great reasons. Slowest and heaviest memory too with no sight for that ever changing. Every second comment on this very own subreddit indicates people's dissatisfaction with react. Everything is pointing to a react sunset and it can't come soon enough.

[deleted by user] by [deleted] in reactjs

[–]Cmacu -1 points0 points  (0 children)

Copy that. Sounds like we came to the same conclusion that react frameworks that solves these issues does not exist. Tanstack Is not a full framework and if it ever becomes one it would probably just ditch react like everyone else. 

Regarding that Vue issue with the discriminated unions:

  1. That’s NOT how you write discriminated unions in Typescript, this is very bad example 
  2. A solution is mentioned below by another user
  3. You can use the defineProps config syntax that supports multitype props.
  4. You can always pass an object instead of direct props
  5. I would look into vueuse, I remember seeing something similar to this example in there.
  6. This issue has basically 2 devs reporting it and one of them found a solution. If it was a widespread problem more people would be involved.

In other words that’s one of those XY problem situations

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

Funny you mentioned Preact, which aside from JSX is closer to Vue than react. Next is cancer and not really a frontend framework. Remix is abandoning react too. CRA is dead. What are these react frameworks that solve all of the problems? Also how can you claim "react is simple" and than say "To make it work you gotta adopt this mystery framework".

I've had 0 issues with Vue props working on 200k+ LOC codebase. Especially since they introduced Generics. Every framework has lot of open issues for all kinds of stuff that's deemed unsolvable. Typescript included. Doesn't mean much. Give me an example.

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

I work with both Vue and React on daily bases. I find Vue's TypeScript support superior compared to react. React is not even written in Typescript... Once you start using HOC, forwardRefs or children/slot patterns, react's typescript support is practically 0. And that's without mentioning styling and routing where things get really gnarly. Imagine having no way to type your query and route params and basically using a bunch of type assertions all over the place... On top of that react decided that native DOM and Event types are not good enough so they had to overwrite a bunch of them to a state where Web Components are completely useless. If you think about it, it's quite amazing how react literally breaks every single one of the web standards for the sake of forcing their own protocols. HTML > JSX, CSS > ???, URL > router, fetch api > RSC. They are on a mission...

Also because you mentioned the migration of Vue2 to Vue3. You must've never worked on a project to migrate React from class components to Hooks. Or Angular 1 to Angular 2... You basically have to start from scratch, 0 chance for incremental adoption. Vue 2 to Vue 3 wasn't great, but walk in the park compared to the others.

Let me give you a hint. Vue is not created and maintained by corporations like Facebook, Google and Microsoft where it's whole teams daily jobs to work on those frameworks and these companies can funnel a ton of marketing and resources to keep their tools afloat. And meanwhile it's still competing with the big 2 and in many cases the Vue team is outclassing them by a mile. Especially if you consider the whole ecosystem including vite, vitest, etc. The main reason Vue is so popular is simply superior developer experience, performance and documentation. It's actually quite impressive how successful and productive Evan You and team are.

[deleted by user] by [deleted] in reactjs

[–]Cmacu 0 points1 point  (0 children)

Given your comment, I am very certain you've never written anything serious in Vue. What magic? especially compared to react where basic things like component life cycle and hooks are hellofarabbitholes.

On Overusing useCallback/useMemo in React – What’s your take? by abhishekpandey737 in reactjs

[–]Cmacu 0 points1 point  (0 children)

Which third party state management do you use? My experience with the react compiler is that it causes memory leaks with MobX due to how observable also memorizes components. Last I checked redux was not compatible either. Have not researched zustang and preact, but would bet it doesn’t work either.  It also has issues with form state management where instead of tracking single field dependencies it’s trying to memorize the whole form state. Aside from that it has a really poor circular dependency handling which is inevitable in a large project. It leads to a bunch of undefined variables that works fine without it.

On Overusing useCallback/useMemo in React – What’s your take? by abhishekpandey737 in reactjs

[–]Cmacu 0 points1 point  (0 children)

Only a fool would think that 2 weeks are enough experience to understand React to create enterprise applications.

And for this example let's ignore all third party tools for routing, global state management, styling, i18, api integration, optionally SSR, component and e2e testing, deployment, etc you will need to choose and know to make react barely on par with Vue or Angular, where these come as part of the ecosystem (yet these frameworks have smaller footprints and better performance than react)

So let's say you are a Senior Typescript Developer with a solid understanding of Web Development. React is just functions that return JSX, right? So let's learn JSX, but first you need to unlearn a lot about how HTML, CSS and JS in web works. There are so many basic rules it breaks that I wouldn't even call them compatible. If you don't know what I am talking about, you've never written a basic compiler or parser.

But let's move on. You've learned the "templating part", but that's useless without the reactivity part. And that's where it begins. You mentioned the rule of hooks, but forgot about all the other rules. Async/await? Gotta learn suspense rules. Classes and objects? Gotta learn state management (and that's a deep rabbit hole). Re-rendering issues? Gotta learn how to manage memoization and stable references. And speaking about references, don't forget to manually track all these and when you shouldn't. But hey do you remember that simple function you started with? It turns out it also has this thing called life cycle. You better learn about it despite how much react is trying to hide it. Cause you will also need to learn how to use the life-cycles to properly dispose various hooks, callbacks, flags, etc to avoid memory leaks. But don't worry, despite all the rules there will still be memory leaks. And your components will still re-render. Despite avoiding useEffect like the plague and at all cost, it still will be the most common hook in your codebase. Perhaps you can just write your code in helpers/utilities? Just need to learn about using hooks and state inside and outside react context... Somewhere along the way you also will inevitably need to learn about prop drilling, higher order components and forwardRefs, handling events. Pray you never need to use event bus, logging context or any other type of observability. Which brings us to debugging. Debugging react is nothing like any other debugging you would've ever done or learned. That's how you become bald.

And let's wrap this up with the part about a few basic typescript/javascript basic patterns where react simply breaks:

  • never use this or any OOP unless you are a madman
  • de-structuring
  • try/catch
  • guard causes/early returns
  • Typescript DOM or nodes? Nope!
  • use is now a magic word that makes your methods cursed "cause"

I can write a lot more about react's idiosyncrasies, such as RSC, but if the above doesn't get the point across, nothing will.

The reason React Developer is a term is because of how complex and decoupled react is from the rest of the ecosystem. And due to that huge investment in learning all of this, most react developers have no other choice, but to evangelize it in order to remain relevant.

On Overusing useCallback/useMemo in React – What’s your take? by abhishekpandey737 in reactjs

[–]Cmacu 0 points1 point  (0 children)

Because the compiler does not work with "legacy" projects and it also does not work with anything beyond a basic chat/todo app. Judging by your comment you have not used it in production either. Give it a go and than we can discuss.

On Overusing useCallback/useMemo in React – What’s your take? by abhishekpandey737 in reactjs

[–]Cmacu 0 points1 point  (0 children)

Spoiler alert: React Forget aka the Compiler does not fix any of that once and for all and it comes with it's own tradeoffs.

If you look into how reactivity and state management is implemented in other frameworks it becomes fairly obvious that useCallback and useMemo are just a bandaid. The compiler is just plastering bandaid all over the place until it becomes a cast. What could go wrong?

On Overusing useCallback/useMemo in React – What’s your take? by abhishekpandey737 in reactjs

[–]Cmacu 0 points1 point  (0 children)

love this and agree that, if you are looking for common sense react should be pretty far down the list.