Live data from Hacker News

Things I Don’t Know as of 2018

overreacted.io

61–70 of 226 posts

Re: Things I Don’t Know as of 2018

#61

Earlier quoted context omitted.

It's interesting and notable because of who wrote it. The author created one of the most-used programming frameworks, yet there are a lot of things he doesn't know. This type of article can actually be super helpful for people with impostor syndrome, as it shows that you don't need to be an expert in everything to create work that millions of people use and love.

> The author created one of the most-used programming frameworks, yet there are a lot of things he doesn't know. There are far more accomplished people in the world who know far less about far more topics. This case doesn't seem particularly extraordinary.

If these people write an article like this we would be discussing it as well :)

Re: Things I Don’t Know as of 2018

#62
post #53
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…

Word!

Re: Things I Don’t Know as of 2018

#63

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…

[not OP but I can remember feeling the same, also I haven't done a big redux project in about a year]

I haven't looked at the docs in a while but I'm not sure that's where the big problem lies. The hard thing about Redux is that you need to "get" the core concepts (not that complex), and how they interplay with how (and when) React renders component subtrees (very complex - this requires a new understanding of react you didn't need before).

After you learn React and finally "get" it you definitely won't get Redux. Not because of Redux perse, but because the way you structure your application is so different. After that you'll encounter more subjective questions like do we put this (semi localized) state in Redux? And there are no right answers anymore, just opinions.

Also the boilerplate doesn't help.

Re: Things I Don’t Know as of 2018

#64

You can make a living as a frontend dev without having to touch those topics much. Other devs: desktop app devs, mobile devs, backend devs, devops devs, network devs, data scientists, game devs get exposed to those a little bit more. If you are interested in learning a lot of those at the same time, write a server in C. https://beej.us/guide/bgnet/html/multi/index.html

That's a great book. We were using this book as a tutotial/reference during our http server assignment in college.

Re: Things I Don’t Know as of 2018

#65
post #53
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…

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 website projects, I use react-static as a static site generator as it can handle all your data loading, bundle splitting, server side rendering, etc. for you automatically. It’s best to start your project with react-static rather than retrofitting it, they have a command line tool to set up a new project so this is usually instead of CRA/Parcel. Gatsby is probably an equally valid choice, react-static seemed a little simpler to me and I’ve been happy so far but Gatsby community seems larger.

- I’ve not used Redux for a couple of years now, instead using MobX for application state. Personally I find it so much quicker and easier to use, although it is undeniably more “magic”. Honestly think this is one of the biggest productivity enabling changes I’ve made since switching to React.

- Personally I’m a fan of Typescript, while it can be a bit of a pain initially, I think you reap the rewards as a project progresses in terms of ability to refactor easily and avoid wasting time on syntax errors.

Re: Things I Don’t Know as of 2018

#67
post #53
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…

There is a core issue with UI development that makes things harder and less elegant than the backend.

It's the io loop. Components must change state and react to state. This where the complexity arises. If you remove the loop by having components only react to state, you will find your programs to be simple, modular and more beautiful.

The feedback loop of IO destroys the functional and modular nature of UI. Functional programming simplifies programming through restriction, however ui development is inheritly an object oriented problem due to the IO loop, so the results of trying to make it functional will have limited benefites.

The way to make UI work is to find a way to have components react to state and change state in a simple way and without hard coding a refrence to external state in the component itself. Aka stateless.

Many people believe that passing a closure is the solution. The reality is passing a closure is awkward and a form of encapsulating state with methods that leads to the same issues of complexity that you get with oop. Keep data and functions seperate always, a closure is technically a functional concept, but it is also oop in disguise as it is instatiating state coupled with a functions just like an object in oop.

Global event emitters might be the best way. I'm not sure if redux does this. I'm not a UI guy so everything is just imho.

Re: Things I Don’t Know as of 2018

#68
post #50

To be honest, knowing your limitations that well is a ver good thing. Probably many people would say "yes, I know" knowing not much more than what he summarized for some of the items of the list with just a few words. Didn't know him, but I like him now.

Wenn du weist, dass du nichts weist weist du mehr als wenn du nichts weist das nicht weist.

If you know what you don't know anything, you know more than if you don't know anything and you don't know.

Re: Things I Don’t Know as of 2018

#69
What I miss from this article is what he does know. Not to boats, but to contrast. I know some of the things he does not know, and I'm sure he knows things I don't know. But without knowing what his expertise is, it's easy to think you know more than him.

Re: Things I Don’t Know as of 2018

#70

What I miss from this article is what he does know. Not to boats, but to contrast. I know some of the things he does not know, and I'm sure he knows things I don't know. But without knowing what his expertise is, it's easy to think you know more than him.

He's one of the most prominent React core developers. The author of Redux etc. Many JavaScript and React developers (myself included) consider him a rockstar.
Post reply on HN