4 ms·

I recently adopted the "you shouldn't have to think about your toolset" and "use boring technology" mindsets. I learned React but I stopped following all other

by lopatin 11y ago

I recently adopted the "you shouldn't have to think about your toolset" and "use boring technology" mindsets. I learned React but I stopped following all other wonderful work being done by the community. It was just too much. And as a result I became happier and more productive. My passion is my pet project which uses JS, not the JS ecosystem itself. I'll wait a year for build tools to become easier and React architectures to stabilize. Until then, my code won't be the holy grail of immutable flux, but my users will never know that. My re-builds take a couple seconds and I don't have hot code reloading. And I'm ok with that. I work with (what I consider to be) the bare minimum: React, Babel, Browserify, and fswatch. It's all wired together in my Makefile. It works pretty well. When something clearly needs improvement then I'll address it. Maybe I'll switch to Webpack and integrate hot code reloading to improve build times when I have some free time. But only as a luxury. I can get by without it. The above sounds easier for build tools than for JS architecture. After all, switching from Browserify to Webpack is a lot easier than refactoring your code from your existing setup to something like Relay, Om, etc... What I say to that is this: Gradually integrating flux (vanilla or Redux) into an existing React app is actually very simple. Extract local state, throw it into a store, and add a subscription. I wouldn't expect any refactoring headaches at all if your component hierarchy makes sense. Everything else (for example anything related to GraphQL, ClojureScript, you see where I'm going) counts as "not boring technology" and significantly increases the risk of being pulled back into the unproductive search of JavaScript enlightenment. I certainly don't want to discourage library authors in any way. If that's what you're passionate about then don't let my jaded thoughts stop you from building something great. We are in a period of great discovery, innovation, and change. I just wanted to share my thoughts about making a conscious effort to minimize my toolset and accepting the tradeoffs of not having the latest tech.

voltagex_ 11y ago
>I recently adopted the "you shouldn't have to think about your toolset" and "use boring technology" mindsets. I learned React but I stopped following all other wonderful work being done by the community. It was just too much. And as a result I became happier and more productive. Thank you! I had to pick up Node.JS and npm for a project recently. Apart from it not working properly in an enterprise environment (NTLM proxy and interception certificates) there are so many things to remember on top of my normal Visual Studio knowledge. I know Microsoft is moving in this direction with DNX and I think it's a good thing, but also could lead to a lot of unnecessary complexities. No one's going to miss XML-based project files though (sln and vcproj are being replaced by json files)
mbrock 11y ago
When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to hash change events. We got up and running very quickly and fleshed out the app in a couple of months with no major problems. Later we've started using some stuff, but we did it gradually according to real needs. So when I see people starting their projects by configuring dozens of tools and technologies that they don't really need up front, I wonder why they don't just start simple.
- chvid 11y ago
  Exactly. The problem is when people ask themselves "What do I need?" and then go "I don't know ... hmmm ... I better get everything then ..."
  - eva1984 11y ago
    +1 A lot of dev, like me in the college, have the tendency to get everything right before starting writing first line of code when learning something new, in hope that orthodox practice will help avoiding pitfalls on the way. But what I really learned along those years, is that pitfalls are inevitable, and expose yourself to them at the early phase of learning is helpful so that you could later appreciate other people's solution and the reasoning behind. Trying to get everything right from beginning hinder you from getting such first-hand and organic insight, and wondering with tools too much will stray yourself from focusing on the essentials.
- cageface 11y ago
  React is still pretty new and doesn't really proscribe anything beyond the view layer. So when people jump into it they go online to try to get an idea of how they should structure their apps they find a lot of buzz around things like Redux and React-Router. Those are both good tools but the combined learning curve for those + ES6 + Webpack + Babel can be pretty steep. But, like you say, for a lot of apps you can start with a much simpler stack. I did the same thing when I was getting started. My "stores" were just simple JS objects with some subscribe methods. This worked well enough that I was able to focus on building my app and to see first hand how great the React model is for building UIs.
AKifer 11y ago
Agree with that attitude, you'll never have enough neurons to follow all the things released. The key is to pick only the minimum you need and forget about the rest. Anyway, as Knuth says, premature optimization is the root of all evils.
substack 11y ago
Webpack doesn't have a monopoly on hot reloading, you can do this in browserify too: `npm install browserify-hmr` With watchify: watchify -p browserify-hmr -o bundle.js With budo: budo main.js -p browserify-hmr If you're using react, you'll only need a tiny wrapper around the root element to opt in to hot reloading: https://github.com/substack/react-starter-hmr/blob/master/main.js#L7 https://github.com/substack/react-starter-hmr/blob/master/ma... All of this should fit comfortably in a Makefile (or npm run script) and each piece you add is small and comprehensible.

by lopatin 11y ago

voltagex_ 11y ago

>I recently adopted the "you shouldn't have to think about your toolset" and "use boring technology" mindsets. I learned React but I stopped following all other wonderful work being done by the community. It was just too much. And as a result I became happier and more productive. Thank you! I had to pick up Node.JS and npm for a project recently. Apart from it not working properly in an enterprise environment (NTLM proxy and interception certificates) there are so many things to remember on top of my normal Visual Studio knowledge. I know Microsoft is moving in this direction with DNX and I think it's a good thing, but also could lead to a lot of unnecessary complexities. No one's going to miss XML-based project files though (sln and vcproj are being replaced by json files)

mbrock 11y ago

When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to hash change events. We got up and running very quickly and fleshed out the app in a couple of months with no major problems. Later we've started using some stuff, but we did it gradually according to real needs. So when I see people starting their projects by configuring dozens of tools and technologies that they don't really need up front, I wonder why they don't just start simple.

chvid 11y ago
Exactly. The problem is when people ask themselves "What do I need?" and then go "I don't know ... hmmm ... I better get everything then ..."
- eva1984 11y ago
  +1 A lot of dev, like me in the college, have the tendency to get everything right before starting writing first line of code when learning something new, in hope that orthodox practice will help avoiding pitfalls on the way. But what I really learned along those years, is that pitfalls are inevitable, and expose yourself to them at the early phase of learning is helpful so that you could later appreciate other people's solution and the reasoning behind. Trying to get everything right from beginning hinder you from getting such first-hand and organic insight, and wondering with tools too much will stray yourself from focusing on the essentials.
cageface 11y ago
React is still pretty new and doesn't really proscribe anything beyond the view layer. So when people jump into it they go online to try to get an idea of how they should structure their apps they find a lot of buzz around things like Redux and React-Router. Those are both good tools but the combined learning curve for those + ES6 + Webpack + Babel can be pretty steep. But, like you say, for a lot of apps you can start with a much simpler stack. I did the same thing when I was getting started. My "stores" were just simple JS objects with some subscribe methods. This worked well enough that I was able to focus on building my app and to see first hand how great the React model is for building UIs.

AKifer 11y ago

Agree with that attitude, you'll never have enough neurons to follow all the things released. The key is to pick only the minimum you need and forget about the rest. Anyway, as Knuth says, premature optimization is the root of all evils.

substack 11y ago

Webpack doesn't have a monopoly on hot reloading, you can do this in browserify too: `npm install browserify-hmr` With watchify: watchify -p browserify-hmr -o bundle.js With budo: budo main.js -p browserify-hmr If you're using react, you'll only need a tiny wrapper around the root element to opt in to hot reloading: https://github.com/substack/react-starter-hmr/blob/master/main.js#L7 https://github.com/substack/react-starter-hmr/blob/master/ma... All of this should fit comfortably in a Makefile (or npm run script) and each piece you add is small and comprehensible.