Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Don’t Know as of 2018

overreacted.io

Post reply on HN
Print view View original

201–210 of 226 posts

Re: Things I Don’t Know as of 2018

#201

Post by mercer »

jchw wrote: post #53
erulabs wrote: post #45

This is an awesome article! I like the idea of being more forthcoming with what we don't know. > Containers. I have no idea about how to use Docker or Kubernetes. (Are those related?) I have a vague idea that they let me spin up a separate VM in a predictable way. Sounds cool but I haven’t tried it. > Deployment and devops. I can manage to send some files over FTP or kill some processes but that’s the limit of my dev…

>My "thing I dont know as of 2018", just for good measure: How to build complex front-end applications without making a complete mess of things! If you find anyone that truly knows the answer, please let us know :) I'm sure plenty of people claim to, and many more will just claim that the mere concept is flawed so there's no point, and there are even more non-answers. But the actual problem is very difficult. I remem…

My primary background as a professional developer is front-end, and I sometimes feel I can barely keep up. For any project where it's an option, I try to put as much in the back-end as possible. So far it's working out well.

For example, I had a little game where initially I wrote a React+ecosystem solution that worked. Then, considering that I don't need x updates per seconds, I switched to server-side rendering + morphdom.

As a result I could reduce all my code to 1) websockets messages to the server and strings of markup from the server, and 2) a few 'optimistic updates' on the client-side by directly changing the DOM. Having no more client-side state to maintain really simplifies things.

Considering that this was a viable solution to a game that has to update the DOM on pretty much every click (but no more than that), it's probably a fine solution to the vast majority of apps I build.

I can't wait for Phoenix LiveView to make this kind of solution less ad-hoc, but at least so far even the ad-hoc solution is so much simpler...

Re: Things I Don’t Know as of 2018

#202

Post by freehunter »

acemarke wrote: post #24
freehunter wrote: post #22

Earlier quoted context omitted.

I will admit I am a terrible programmer, but I will say using Redux scared me away from using React at first. Maybe my React needs are minimal, but I tried following a tutorial using React and Redux and I was immensely confused. Once I struck out on my own and ditched Redux for just straight React, everything became so much clearer and simpler.

Hi, I'm a Redux maintainer. Anything specific that confused you? Which tutorials were you looking at? We're currently planning a revamp of the Redux docs. I'd really appreciate any feedback on what things caused problems, so we can know how to make the docs better. Feel free to comment here, or ping me on Twitter or in the Reactiflux chat channels. I've also got a survey open asking for suggestions on docs structurin…

It wasn't the Redux docs, it was the entire mindframe of Redux. This connects to that which connects to that and sets this while this gets that. Like I said, I'm a terrible programmer and I have a hard time keeping complex interactions in my mind. If this block of code needs to change a variable, I want it to just change the variable right there and move on. Having to write the code that needs to change the variable, then switching to another file to write the code that actually changes the variable, then switching to another file to write the code that returns that new variable to my original function is just... so damn unnecessary. There's just too many moving parts that can (and do) break. It's so complex, and when something doesn't work I struggle to debug why.

I will admit I did not choose to use Redux, it was part of a tutorial I was following on Udemy. I never got the hang of it, and once I figured out React Native well enough, I quickly scaled back my reliance on Redux. It's made my life a lot easier.

My day job is a technical consultant for a major tech company, and we have meetings to discuss the meeting we're going to have before the meeting. The administrative overhead of Redux reminds me of that in a very bad way. Instead of my Facebook login button calling auth_actions.js which then returns the auth token to auth_reducer.js which then returns the auth token to auth_screen.js (but don't forget to add it to the combineReducers in index.js), I just put the authentication code in 'await doAuth()' inside of the auth_screen.js file. I've never heard a convincing reason as to why I shouldn't do that, even though the tutorial I followed said it's a bad idea.

Re: Things I Don’t Know as of 2018

#203

Post by freehunter »

wawhal wrote: post #30
freehunter wrote: post #22

Earlier quoted context omitted.

I will admit I am a terrible programmer, but I will say using Redux scared me away from using React at first. Maybe my React needs are minimal, but I tried following a tutorial using React and Redux and I was immensely confused. Once I struck out on my own and ditched Redux for just straight React, everything became so much clearer and simpler.

Redux, IMO is a beautiful state management library. Were you following Dan’s tutorial on Redux? Because that is a beautifully made tutorial as well. ( https://egghead.io/redux ) If you have tried to build a substantially big app with React alone, you will find yourself lost in passing down the props and callbacks and hoisting variables and what not. You definitely need a state management library where you can CRUD fr…

It very well could be a problem with the tutorial I was using, where the author leaned too heavily on using Redux for everything. I wildly scaled back my usage of Redux after I got going. It's just too many moving parts, and I've never figured out how to debug it when something doesn't work. I end up with 'console.log("we made it to the action")' and 'console.log("we made it to the reducer")' and then 'console.log("we made it to mapstatetoprops")' followed by 'console.log("so why the hell is this.state.fbToken still null!?")'. Then I come to find out I forgot to add auth_reducer to the combineReducers in my reducers/index.js.

I can't count the number of hours I've lost to stuff like this.

Re: Things I Don’t Know as of 2018

#204

Post by yakshaving_jgt »

mlevental wrote: post #198
yakshaving_jgt wrote: post #193

Earlier quoted context omitted.

I’m well aware of who I am addressing. It seems you’re implying we should make special allowances for people depending on how popular they are. My entire point is that I won’t take someone at their name; I completely reject the idea of the “celebrity” programmer. Redux is pretty neat; IIRC it was a state store influenced by Elm and implemented in about 50 lines of JavaScript. But there are plenty of developers — even…

my point is exactly not how popular he is but how accomplished he is and how condescending he could be (since he is so popular and accomplished) and how gracious he is being to you. it's like those movies where someone is starting a fight (giving cause) with a person 10x their size and then the bigger person gracefully declining to batter - it should make you reconsider who's the protagonist...

So yes, you are exactly giving special treatment to someone you perceive to be of greater merit owing to their popularity.

Your position is that I should not argue against Dan Abramov because you perceive him to be relatively accomplished. This is an embarrassing point of view.

Burn your idols.

Re: Things I Don’t Know as of 2018

#205

Post by jpochtar »

ben_jones wrote: post #143
tomduncalf wrote: post #65

Earlier quoted context omitted.

A few things that have made creating new React projects easier for me: - create-react—app or Parcel bundler, both of which require zero config. CRA is easiest but I’m not a fan of their defaults for Typescript (which is to prevent the app loading in dev if you have any tslint or compiler errors, even if they are just warnings) so once I’ve messed around fixing that, it’s almost just as easy to use Parcel. - For websi…

I disagree with CRA because it promotes developers avoiding and fearing configuration files. If you are a full time front end developer and your shop uses it you NEED to learn Webpack/Babel/NPM/etc because it is a short up-front investment, will save significant amounts of time, and will lead to a noticeably better product. We're talking about hours of study leading to a long-term hundreds of hours of time saved.

As a new web developer: what can I do once I know how to config these things, that I don’t get as part of CRA?

Re: Things I Don’t Know as of 2018

#206

Post by yawaramin »

sidcool wrote: post #73

This is a very good article. What stumps me though is how the 10x engineers/architects make such sound technical choices without knowing a lot of things. I perennially feel ignorant of Computer Science concepts that many others seem to possess. This article helps me to understand it's not only me. But I would still like to make the best tech choices most of the times...But the problem is..WHAT TO LEARN NEXT? THERE'S…

They make good choices because they work in teams where members have different strengths and help each other.

Re: Things I Don’t Know as of 2018

#207

Post by ben_jones »

jpochtar wrote: post #205
ben_jones wrote: post #143

Earlier quoted context omitted.

I disagree with CRA because it promotes developers avoiding and fearing configuration files. If you are a full time front end developer and your shop uses it you NEED to learn Webpack/Babel/NPM/etc because it is a short up-front investment, will save significant amounts of time, and will lead to a noticeably better product. We're talking about hours of study leading to a long-term hundreds of hours of time saved.

As a new web developer: what can I do once I know how to config these things, that I don’t get as part of CRA?

Off the top of my head, I'm sure I'm missing a few obvious ones. Notably CRA doesn't prevent you from doing any of these, but taking the time to learn the various build tools will better enable it.

* spend less time debugging dependencies across version changes

* reduce bundle sizes

* create a better CI/CD pipeline

* reduce unnecessary dependencies

* fork/fix/create your own plug-ins and other tools

* self-hosting npm to avoid production/dev outages

* easily learn new tools because you understand the underlying systems/alternatives

Re: Things I Don’t Know as of 2018

#208

Post by ben_jones »

acemarke wrote: post #191
ben_jones wrote: post #143

Earlier quoted context omitted.

I disagree with CRA because it promotes developers avoiding and fearing configuration files. If you are a full time front end developer and your shop uses it you NEED to learn Webpack/Babel/NPM/etc because it is a short up-front investment, will save significant amounts of time, and will lead to a noticeably better product. We're talking about hours of study leading to a long-term hundreds of hours of time saved.

Devs shouldn't have to spend hours setting up build configuration just to get started learning React, or every time you have a side project you want to try out. Granted, you _never_ needed Babel and Webpack _just_ to use React, but for a long time every React tutorial started with "First, we'll learn how to set up Babel and Webpack". Now, they can just say "Run `npx create-react-app my-app`", and immediately get a so…

Couldn't you make this same argument about math curriculum? "Why should we teach algebra when its so easy to just use basic calculus for real world problems".

The problem is there is a huge gap between a development react application and a production react application that is served to users with best security/operational processes. The own creators of CRA do not recommend it be used in production and isn't that the goal for most react developers, to put apps into production?

Re: Things I Don’t Know as of 2018

#209

Post by Nikspatel007 »

mettamage wrote: post #37

I would like a list to see what he does know, according to himself. Somehow I get giddy making a comparison between what he knows and doesn’t know. I want to make a mental model of what a real dev looks like, even if it is a biased one.

He wrote a post on that too.

https://overreacted.io/the-elements-of-ui-engineering/

Re: Things I Don’t Know as of 2018

#210

Post by acemarke »

ben_jones wrote: post #208
acemarke wrote: post #191

Earlier quoted context omitted.

Devs shouldn't have to spend hours setting up build configuration just to get started learning React, or every time you have a side project you want to try out. Granted, you _never_ needed Babel and Webpack _just_ to use React, but for a long time every React tutorial started with "First, we'll learn how to set up Babel and Webpack". Now, they can just say "Run `npx create-react-app my-app`", and immediately get a so…

Couldn't you make this same argument about math curriculum? "Why should we teach algebra when its so easy to just use basic calculus for real world problems". The problem is there is a huge gap between a development react application and a production react application that is served to users with best security/operational processes. The own creators of CRA do not recommend it be used in production and isn't that the…

On the contrary, CRA's docs specifically recommend it for production use:

> No Configuration Required: You don't need to configure anything. A reasonably good configuration of both development and production builds is handled for you so you can focus on writing code.

Nowhere in the docs do I see phrases like "don't use this in production".

As for the math analogy: I'd say the difference is that many calc concepts do require understanding of algebra to grasp and use, whereas the only thing about React that _sorta_ implies knowledge of Babel is the JSX transform, which isn't a hard requirement to use React but is certainly the common preferred approach.

Again, I'm not at all saying that people _shouldn't_ learn how to set up build tool configs. I agree that's valuable knowledge to have. I'm just saying it shouldn't be a hard blocker for using React, and that React tutorials shouldn't have to spend half their time teaching unrelated build tools instead of React itself.

Post reply on HN