6 ms·

About 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

About 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 opening experience. Then I wrote an MVC framework from scratch because I thought others were too heavy (ZF, Symfony, etc). It helped me understand an application development at a deeper level, figuring out the best strategy for code modularization, organization, and performance. It helped me to learn creating something that looks so painlessly easy to use is a pretty difficult task (there will always be something ugly sticking out). It took me on a ride of what happens with extreme level of abstractions breaking up code for each roles and a simpler route much like the Sinatra / Express bootstrap approach. I've found a new level of respect for those who develops codes at a macro-level (frameworks / libraries). There are lot of thoughts and love been applied to them. DHL (Rails) is up there, as well as John Resig (jQuery). I'll also give a shout out to Sequel (Jeremy Evans) while at it for creating an ORM that is almost perfect. Vue.js (Evan You) also particularly deserves a lot of credit for what he is doing in the front-end world. I like React too, can be fun, but I did not like the whole Redux experience. I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple.

acemarke 7y ago
> I did not like the whole Redux experience Out of curiosity, anything specific that concerned you? If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns in practices in our Style Guide docs page [2] that should result in simpler and easier to understand code. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide
- ratww 7y ago
  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. In an ideal world for me you'd be able to deprecate old Redux and just replace it with Toolkit.
  - acemarke 7y ago
    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 immutable update logic by hand, making a mistake in that immutable update logic and causing accidental mutations, etc [0]. I do understand the suggestion to "replace the Redux core with RTK", and I take it as a great compliment that people suggest that. However, it can't happen, because a lot of people are already using Redux with their own customizations and abstractions. Changing the Redux core to suddenly include a bunch of other dependencies would not be what they want. The other aspect is that the Redux core was designed from the beginning to be unopinionated, while RTK is _deliberately_ opinionated. Not all Redux users want RTK's opinions. As it is, we've had folks who didn't like the fact that RTK _is_ opinionated and requires use of Immer in our `createReducer` and `createSlice` APIs. We had a long discussion issue about whether it made sense to add things like this to the Redux core (which was actually part of what prompted us to create RTK in the first place) [1]. FWIW, we explicitly recommend RTK as the standard way to write Redux logic [2], and now that Redux Toolkit 1.3 is out with some new APIs [3], my next task is to create a new "Quick Start" tutorial page for the Redux core docs [4] that does actually teach Redux using RTK as the default syntax, ie, "this _is_ how you write Redux code", in the same way that the Apollo docs teach Apollo-Boost as the default way to use Apollo. [0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [1] https://github.com/reduxjs/redux/issues/3321 https://github.com/reduxjs/redux/issues/3321 [2] https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic https://redux.js.org/style-guide/style-guide#use-redux-toolk... [3] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0 https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0 [4] https://github.com/reduxjs/redux/issues/3674 https://github.com/reduxjs/redux/issues/3674
JackMorgan 7y ago
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.
- dahfizz 7y ago
  > anyone writing a UI in 2020 to have a damn good reason to not use react and redux. Avoiding JavaScript is all the reason anyone needs. UI =\= website
  - hombre_fatal 7y ago
    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."
    - bryanrasmussen 7y ago
      I thought the point to absurdity was what they mean by UI =\= website? on edit: =\= is the prolog version of !=, I guess they didn't want to use != in case anyone thought they used JavaScript in real life.
    - dahfizz 7y ago
      What is absurd about native programs? I think trying to turn a web browser into an OS is absurd.
      - stnmtn 7y ago
        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?
        7y ago
kqr 7y ago
> I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple. I don't fully agree. Yes, some programming needs to be done at a meta level, but far from all of it. Sometimes a software engineer is just there to solve a business problem, and in that case what makes them great is efficiently solving that particular problem, and not a meta-problem. Sometimes shorter code is easier to write, less buggy, and more maintainable than meta code.
- dep_b 7y ago
  How you solve that particular business problem should be really easy to deduce from the code that you wrote to solve it. 2000 line functions that are one big switch / case statement don't fall into that category for example. So it's still thinking about how others (that could even be yourself two years down the road) use the code is very important for such applications. The definition for code to me is a language used to explain other programmers what you are trying to do that can be parsed by a computer.
- ivanhoe 7y ago
  I don't see these two as opposed. If you're building a framework that means you need to do some meta thinking about its future users and their needs. If it's a special niche problem then you need some meta thinking about the clients business needs. It's all about deeply understanding the problem that you're attempting to solve.
- collyw 7y ago
  I would say that's the difference between making something work. And Making at work in an elegant way.
guggle 7y ago
I initially followed the same path... then I just ditched completely PHP and its ecosystem and then never felt the need to write my own ORM/Router/libs again.
- beaker52 7y ago
  Haha me too. I think PHP was a great rite-of-passage as a developer back then: inconsistent standard API, all the session and cookie access built in, with all the security gotchyas, evolution from major versions 4 to 5, obsession with Frameworks, growth and development of ZF and Symfony etc. Great experience. As I left the ecosystem, I realised I approached writing code in a very defensive, overly structured way and have written less than half as many libraries ever since. The jury is out on whether that's a good thing or not. As a sometimes-front-end dev, part of me quietly yearns to go back to the days of serving full html pages, especially since data transfer speeds are higher than they've ever been. Edit: that's not a rejection of React et al. more an acknowledgement that everyone wants to do server-side rendering "because performance" which was... what we used to do. If we serverside render most of the page, we only need to enhance _some_ of the UI clientside? Yup. Exactly what we used to do.
  - guggle 7y ago
    ahh... the good ol' days of magic_quotes enabled by default... because, yeah, why would anyone want to use data for anything else than putting it in a mysql db ? mm ? :-)
  - apotheon 7y ago
    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, choose C instead. As for the benefits of rendering server-side, they are legion, and most important among them is the fact that pushing everything to the client-side part of the system means not really knowing what your code will do in the wild, imposing whole new classes of frustration on users, and piles of other horrors. Yes, we could benefit from falling back on far more default-server-side technologies and using JavaScript only where it's needed, I think, for the sake of the users first and foremost. JavaScript is great for some things. It's terrible for others, and all too often trying to use JavaScript for everything means coupling the wrong tools for many jobs together with the wrong place to run code, too. Even when I enjoy JavaScript work, the simple act of checking online documentation for the JavaScript tools I'm using ruins the whole experience for me as I realize how we're punishing our users when we don't think about how we're using JavaScript from a user's perspective.

acemarke 7y ago

> I did not like the whole Redux experience Out of curiosity, anything specific that concerned you? If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns in practices in our Style Guide docs page [2] that should result in simpler and easier to understand code. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide

ratww 7y ago
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. In an ideal world for me you'd be able to deprecate old Redux and just replace it with Toolkit.
- acemarke 7y ago
  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 immutable update logic by hand, making a mistake in that immutable update logic and causing accidental mutations, etc [0]. I do understand the suggestion to "replace the Redux core with RTK", and I take it as a great compliment that people suggest that. However, it can't happen, because a lot of people are already using Redux with their own customizations and abstractions. Changing the Redux core to suddenly include a bunch of other dependencies would not be what they want. The other aspect is that the Redux core was designed from the beginning to be unopinionated, while RTK is _deliberately_ opinionated. Not all Redux users want RTK's opinions. As it is, we've had folks who didn't like the fact that RTK _is_ opinionated and requires use of Immer in our `createReducer` and `createSlice` APIs. We had a long discussion issue about whether it made sense to add things like this to the Redux core (which was actually part of what prompted us to create RTK in the first place) [1]. FWIW, we explicitly recommend RTK as the standard way to write Redux logic [2], and now that Redux Toolkit 1.3 is out with some new APIs [3], my next task is to create a new "Quick Start" tutorial page for the Redux core docs [4] that does actually teach Redux using RTK as the default syntax, ie, "this _is_ how you write Redux code", in the same way that the Apollo docs teach Apollo-Boost as the default way to use Apollo. [0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [1] https://github.com/reduxjs/redux/issues/3321 https://github.com/reduxjs/redux/issues/3321 [2] https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic https://redux.js.org/style-guide/style-guide#use-redux-toolk... [3] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0 https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0 [4] https://github.com/reduxjs/redux/issues/3674 https://github.com/reduxjs/redux/issues/3674

JackMorgan 7y ago

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.

dahfizz 7y ago
> anyone writing a UI in 2020 to have a damn good reason to not use react and redux. Avoiding JavaScript is all the reason anyone needs. UI =\= website
- hombre_fatal 7y ago
  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."
  - bryanrasmussen 7y ago
    I thought the point to absurdity was what they mean by UI =\= website? on edit: =\= is the prolog version of !=, I guess they didn't want to use != in case anyone thought they used JavaScript in real life.
  - dahfizz 7y ago
    What is absurd about native programs? I think trying to turn a web browser into an OS is absurd.
    - stnmtn 7y ago
      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?
      - 7y ago

kqr 7y ago

> I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple. I don't fully agree. Yes, some programming needs to be done at a meta level, but far from all of it. Sometimes a software engineer is just there to solve a business problem, and in that case what makes them great is efficiently solving that particular problem, and not a meta-problem. Sometimes shorter code is easier to write, less buggy, and more maintainable than meta code.

dep_b 7y ago
How you solve that particular business problem should be really easy to deduce from the code that you wrote to solve it. 2000 line functions that are one big switch / case statement don't fall into that category for example. So it's still thinking about how others (that could even be yourself two years down the road) use the code is very important for such applications. The definition for code to me is a language used to explain other programmers what you are trying to do that can be parsed by a computer.
ivanhoe 7y ago
I don't see these two as opposed. If you're building a framework that means you need to do some meta thinking about its future users and their needs. If it's a special niche problem then you need some meta thinking about the clients business needs. It's all about deeply understanding the problem that you're attempting to solve.
collyw 7y ago
I would say that's the difference between making something work. And Making at work in an elegant way.

guggle 7y ago

I initially followed the same path... then I just ditched completely PHP and its ecosystem and then never felt the need to write my own ORM/Router/libs again.

beaker52 7y ago
Haha me too. I think PHP was a great rite-of-passage as a developer back then: inconsistent standard API, all the session and cookie access built in, with all the security gotchyas, evolution from major versions 4 to 5, obsession with Frameworks, growth and development of ZF and Symfony etc. Great experience. As I left the ecosystem, I realised I approached writing code in a very defensive, overly structured way and have written less than half as many libraries ever since. The jury is out on whether that's a good thing or not. As a sometimes-front-end dev, part of me quietly yearns to go back to the days of serving full html pages, especially since data transfer speeds are higher than they've ever been. Edit: that's not a rejection of React et al. more an acknowledgement that everyone wants to do server-side rendering "because performance" which was... what we used to do. If we serverside render most of the page, we only need to enhance _some_ of the UI clientside? Yup. Exactly what we used to do.
- guggle 7y ago
  ahh... the good ol' days of magic_quotes enabled by default... because, yeah, why would anyone want to use data for anything else than putting it in a mysql db ? mm ? :-)
- apotheon 7y ago
  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, choose C instead. As for the benefits of rendering server-side, they are legion, and most important among them is the fact that pushing everything to the client-side part of the system means not really knowing what your code will do in the wild, imposing whole new classes of frustration on users, and piles of other horrors. Yes, we could benefit from falling back on far more default-server-side technologies and using JavaScript only where it's needed, I think, for the sake of the users first and foremost. JavaScript is great for some things. It's terrible for others, and all too often trying to use JavaScript for everything means coupling the wrong tools for many jobs together with the wrong place to run code, too. Even when I enjoy JavaScript work, the simple act of checking online documentation for the JavaScript tools I'm using ruins the whole experience for me as I realize how we're punishing our users when we don't think about how we're using JavaScript from a user's perspective.