Earlier quoted context omitted.
Regarding PHP, if you want it as a rite of passage it should come after writing software in better languages with better tools. PHP-first means bad-habits-first. C imposes similarly rigorous proving grounds for developers, but without pushing new developers into bad habits that would come back to bite them later. If you want people to start with more requirements for hard thinking about how to not build a deathtrap,…
My first language was Pascal. I'd like to think I learned good habits up front. But I'll fully admit, when I first started writing PHP, I definitely treated it as a "script". My code barely used functions at first. It was a big top-down autoexec.bat style recipe. It took quite awhile for me to come around to treating PHP like a real programming language. I think a lot of it came from the fact that I'd edit, and refre…
How I became a better programmer (2017)
141–150 of 150 posts
Re: How I became a better programmer (2017)
#142Earlier quoted context omitted.
What is absurd about native programs? I think trying to turn a web browser into an OS is absurd.
It's orders of magnitude harder to get users to download a program than it is to just give them a link and have everything right there, no?
Re: How I became a better programmer (2017)
#143Earlier quoted context omitted.
I'm not sure what you mean by "it's not Redux". It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it. What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested…
Maybe "it's not Redux" is meant in the same way as "Toyota Camry isn't Car". It's a car, but you can have a car that isn't a Camry. Otherwise, I'm really not sure what that "it's not Redux" comment means, either. edit: Oh, crap, I just made a software/car analogy. I hate those.
Vanilla Redux on its own is like Linux without an userland, so you have to implement yourself.
Redux Toolkit is a proper Linux with GNU userland. It's ready to use, and people can even use each other's computers without reading through the source code!
It doesn't make a lot of difference for smaller projects, but the thing about Redux is that as soon as you have 20+ or 30+ people working on the same codebase you get a hodgepodge of different patterns and structures. Toolkit solves it.
Re: How I became a better programmer (2017)
#144Earlier quoted context omitted.
Not OP but: You probably know the answer to your own question, since I'm guessing you made Toolkit to scratch your own itch! :) The "Redux Experience" is a bit overwhelming, boilerplatey, verbose and full of gotchas. Structures are all over the place. IMO that is solved by Toolkit. The only problem with Toolkit is that it's not Redux. People don't know it yet, and I have to fight to convince people it's good enough.…
I'm not sure what you mean by "it's not Redux". It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it. What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested…
Starting a project with Vanilla Redux is like starting a Vanilla PHP or Vanilla Javascript project: you're on your own. And most people don't really have a very big grasp on the full concept and just blindly follow some rando tutorial they saw in 2017 or 2018, because that's the best they can do.
That's kind of fine! I don't really mind using different architectures, or even different frameworks. But in large projects the inconsistencies from different approaches generates bit rot and lot of bikeshedding.
I find RTK really good (maybe I'm biased because I've been using Immer from day 1), but that's beside the point: the best part is that it removes the least productive and most boring parts IMO of building software in large teams: bikeshedding, boilerplate and lack of structure in large projects.
Re: How I became a better programmer (2017)
#145Re: How I became a better programmer (2017)
#146Earlier quoted context omitted.
What is absurd about native programs? I think trying to turn a web browser into an OS is absurd.
It's orders of magnitude harder to get users to download a program than it is to just give them a link and have everything right there, no?
That's a very single-dimensional decision making progress. You're nowhere near convincing that all UIs must be made with a website.
Even if we restrict our view to UIs made for businesses for the purpose of making a profit, native apps make a lot of sense. Just think of any big tech company; they all have robust apps and consumers largely prefer the apps. You can order door dash or an Uber in a web browser, but people almost always use the app because a good native app is a better experience than a good website app.
Re: How I became a better programmer (2017)
#147About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye…
As a recent convert to redux who ended up recreating it from first principals but in a much much clunkier way, I highly recommend anyone writing a UI in 2020 to have a damn good reason to not use react and redux. It's so well designed today. Well worth the time to learn.
Re: How I became a better programmer (2017)
#148Earlier quoted context omitted.
Not to be rude or anything but if you continue down this road productivity might be the only thing going for you and you'll soon realise you are the only one who can work with your code. Substitute software engineering with any other engineering descipline with "I stopped worrying about best practices" and you will be able to see what's wrong with your approach. But then again, if it's php, your domain doesn't requir…
Although I agree in general, a 10 line for loop is usually more readable than a clever one liner.
Re: How I became a better programmer (2017)
#149Earlier quoted context omitted.
The most charitable interpretation of their point is any UI where you were going to use Javascript heavily anyways which is what Redux+Redux competes with. To take your point to absurdity, you could also just say "nope, write a native client instead."
What is absurd about native programs? I think trying to turn a web browser into an OS is absurd.
Re: How I became a better programmer (2017)
#150Earlier quoted context omitted.
I'm not sure what you mean by "it's not Redux". It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it. What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested…
I mean the problems is that it's not Redux itself. People have to actively look for RTK to use it, and few do. I wish you guys had replaced Redux with RKT and moved redux to @reduxjs/core like proposed on the issue and proclaimed "Redux is dead, long live Redux!" Starting a project with Vanilla Redux is like starting a Vanilla PHP or Vanilla Javascript project: you're on your own. And most people don't really have a…
There's also nothing we can do about the 5 million existing tutorials out there on the internet, and it's not like the core APIs would be _removed_. All those are still syntactically valid. Even if we shipped all these additional APIs as part of the core, people would have to look to see that they exist.