Why are you aggressive? I am just saying public speaking is a core asset of a slightly different career path. You can follow this and there're many career opportunities, especially in tech marketing/dev evangelizing but it's a different path than being an engineer, coding all day or a managing engineer heading devs in the right direction.
Holding good speeches is hard work and takes time. Writing good code, sketching solid abstractions is hard work and takes time as well. Focus on one. And if your code/repo/whatever got 100K stars on Github, then of course hold a speech, it will be easy because everybody want just to see THAT guy. It's complex and this notion, everybody should hold speeches yes, but a guide to speaking at tech conferences? IDK.
If people like public speaking and want to center the career around it, great. But then they need to commit, to do it frequently and of course they start small. But it doesn't make sense to do a recorded talk at a conference if you don't have any experience and do it only once. Like the speaker who writes a 10-liner C++, for what?? Who shall hire that C++ coding speaker? Oh wait, he could moderate a tech conference, because he wrote 10 lines C++... or maybe not.
It just a lazy analogy for many useless talks. Btw, I LOVE talking about my vim config in a small setting like a 10 person meetup just because I LOVE vim and like to be with like-minded people. But I'd never do a public speech on it because it's no achievement and more important: my vim config is not my identity (maybe a bit ;)
Speaking at conferences is a strong urge in the dev community. Some do it because they want to improve their public speaking skills or to prove something to themselves ('I can be as outgoing as the marketing guy next door, har har'). Or to improve their market value.
In my early days, I had also this urge but it's wrong. The whole post is wrong. Ask yourself WHY you want to speak at tech conferences. What's the aim of your speech? Most of the times and most people don't have an answer.
You want to have nice Google SERPs on your name?
Why?
To increase your personal market value?
You think one speech is enough?
Not at all. You need so much more. A topic, more than your vim config or some Github repo which got five stars. You need achievements, first. You need a damn story, a sharp profile. Then go out and hold 10 talks/year, shotgun Google's video search with your talks. I promise you, once you have a good story, public speaking is easy, it feels like talking. But if you don't have anything to tell you sound like the odd & boring AWS sales guy who wants to sell some new overpriced AWS service and paid for the speaking slot.
And be aware that public talks don't necessarily improve your market value. One so-so talk on Youtube about your vim config at some third-class conference is worse than nothing. Besides, most tech conference are third-class created by some greedy local meetup tycoon rebranding his useless meetups. The best is that the meetup tycoon gets free content, YOU on stage, on Youtube, for a crappy conference he sold tickets for 500 bucks. He doesn't care if the entire world makes fun of your speech about your vim config.
I remember one guy who did music with hard-coded JS decades ago, not impressive, maybe a bit interesting. This guy was on several speaking gigs with always the same topic, his stupid JS music. After the third time I saw him, I started to hate him, I swore to never hire this person. Remember, speaking can backfire if you don't have a topic.
I've another guy: Jared, he wrote amazing Formik, a great lib. His talks though are so-so, promoting his company (I think it's just a shell for him freelancing) too much and yeah not on par with his repo. When seeing his talks on a shabby meetup, my first thought was, better fix your repo's issues instead of doing this self-promotion. Again: it backfired and didn't improve his market value. Rather the opposite, before I thought Formik, Jared, the king. Once I saw the speaches, OMG, Jared got jarring.
I rather prefer a cozy Youtube video on a living room couch on Svelte like from the Youtuber Harry Wolff (highly recommended!!! => [1]). Good speakers like Harry are entertainers, they understand to be authentic without even trying and it's hard to deconstruct what they do right.
So, public speaking skills are overrated. It's enough to be able to moderate a meeting/standup for 10-50 people. To do proper speaking, you need to do it frequently, you need to understand entertainment, you need to get deeply into story telling, how to plot narratives, sometimes you need script writers, media trainers and you MUST be in shape, no need to look like James Bond but getting on keto few weeks before sounds like a plan.
If you still think you should be a public speaker, test if you have the basics for being a good entertainer. Do internal presentation at your company, bigger ones where you invite multiple departments, do Youtube videos, screen recordings. Test how people react on your voice, on your appearance, your jokes, If you see positive signals or slight growth, continue.
Otherwise just don't. Public speaking is a profession and imagine a public speaker who wants to pair-program with you in C++. I mean why not? If you can hold a speech he should be able to write some kernel code.
Yes but it's so much more work + the code won't be maintainable and something like Transferwise needs a lot of interactivity.
Rather check out the recent thread about the react SSR. The entire field/frontend got quite complex and a good starter is first to understand the underlying concepts of SSR, SPA, react. If you haven then still time, checkout Vue, Svelte.
I meant the docs. It's like decades ago like when you wanted to learn Rails. Then somebody said stop! First learn Ruby... This is not how people learn. There's too much time between learning and trying, so there's no proper and face-paced feedback loop. Let's try to get into somebody's head who's ok in react and slowly wants to get into state management but having no clue of nothing:
His mind:
- Ok, where should I start?
- Which is the best? Mobx, redux, just ContextProvider or local state??
The poor guys falls into the rabbit hole and reads Reddit, HN, Github issues for hours, still not sure what to do; 2 hours later
- Ok, let's try redux, for whatever reason, the maintainers seem to be quite active
The poor guy tries to decide if he should go just with redux/react-redux or rtk; former because it is good to understand the foundation, latter good because just to avoid boilerplate and that's what this acemark is promoting everywhere. The guy is still overwhelmed and don't forget doing decision is hard; it's one of the biggest struggles for humans
- Ok, I guess I need to start with redux because it's the foundation.
He sees all the theory, new terms, the boilerplate and there's no fast-paced feedback loop; he just think heck and checks out mobx, 4 hours later
- Man mobx is even more weird, totally unstructured and while mobx's maintainer seems to be a nice guy, my gut feeling is: stay away
- Let's check out npmtrends, oh great, npmtrends shows that people also don't like mobx, cool, it has much less traction, decision made, nice
- So, let's try redux again, maybe this time I start with RTK
We know what happens, RTK has better feedback loops but w/o the basic knowledge of redux he will struggle, 6 hours later after jumping back and forth the both docs
- Lets stop here, tomorrow is another day.
He is out of flow, motivation is down, the next day he doesn't continue because the whole experience didn't feel good, he writes a post on HN that redux sucks steel and maybe looks the next week again on it
The situation is a bit like with kubernetes; until you have proper feedback loops with k8s you need days, with new k8s distros this got better but the biggest bummer are the k8s docs, too much, too verbose, so many new terms, no feedback loops at all and every k8s examples has minimum 100kb yamls.
What would be great and I know that writing good docs is much harder than actual code:
One and only piece which the reader should read first, which teaches him redux foundation, react-redux boilerplate and rtk within max 2 hours. After that he should have a working example AND should have understood it. No links to other resources, no nothing.
This main piece should be linked everywhere in the Github readmes of all redux relates projects in bold and h1 READ OUR MAIN PIECE FIRST, on all the doc pages and in all forum posts. I mean look at your post's footer in this thread: so many links, why? You need one entry point. RTK could be the entry point, it just needs a bit more flesh on redux and should be declared as the entry point of redux. There's one disadvantage though: with RTK as entry you'd kill the ecosystem around redux but IDK if you did this anyway by declaring RTK the standard way. And you would have a lot of redundant docs with redux/react-redux. Or maybe we need to merge all because maintaining redundant docs is just too much for an OSS project.
Whatever, all not easy but there must be a way because redux is the most underrated thing in the frontend world, it's def the best state management and RTK is a nice and long deserved abstraction.
Still doesn't make sense. Instagram and postcards have different use cases and latter is not about sending someone a physical photo or showing a any photo (hint again: it's a gesture).
Yang says that breaking up tech monopolies won't help (with giving a very weak example) but he doesn't give a proper answer how to get competition back. Why does China have 20 different kind of Youtubes and the western world just one?
IDK, it's good to have competition but I could never get warm with mobx, undo is not baked it, more magic, similar learn curve but less real understanding at the end. Then, the biggest bummer, you have also mobx state tree which is too much fragmentation within mobx.
IDK. While this idea is as old as the Internet, does it make any sense? The key point of a postcard is not to communicate (limited space, not secure, slow) but being a gesture. Buying a postcard, writing something on it and bringing it yourself to the post office is a huge gesture and signals many things--in contrast to postcard gateways like this one. Any receiver who will get this machine printed postcard will think, 'why didn't she/he just text me?' and throws it in the trash bin.
But maybe OP can give us a hint about the real use case or he is hand-writing the cards himself.
Redux is a mixed bag but I'd say it's one of the most elegant ways to handle state.
Biggest problem and reason why people (me included at the beginning) don't like Redux, you should know when you need it and you should use some abstraction layer (eg RTK). One cause could be the docs: while the maintainer try their best to educate a lot (also in this thread paired with interesting link building strategies), there is not quick and easy way to get into Redux. If you start with RTK's docs, you don't understand everything. Then, you need to read the Redux docs, then again back and forth. And this just takes too long to grok an actual simple API.
One easy indicator for Redux or not: does your app need kind of an undo feature, then you should dive into Redux and I'll promise you. there is no other way to do this in such a sane, maintainable way.
Re your second point: How is the SSR scene in Go land? Are there thriving ecosystems?
Besides, it took me a long to leave pug/stylus, I'am still not sure if a pug-based SSR is still the best way to get stuff out of the door. But again, opting for an 10 years old stack let you miss lot of things (eg maintainability of react code is top-notch).
Good point and I agree that the borders between SPA and SSR are blurry. However, I just wanted to stress that a debate without having requirements is useless, it's like saying a racing car is better than a truck. But for what? Building websites is not like building websites 20 years ago. There are many uses cases and saying one is better than the other rather shows that you never experienced the other side. I mean, there are still people out who never touched react, how should they fully grok what mighty system and ecosystem react has created and choosing another stack comes with much smaller or dying ecosystems.
To your points, I still think a proper SPA without any quirks such as DHTML, React Suspense, etc. gives the best UI for dashboard and logged-in kind of uses cases. However, having mixed environments is from a production and dev perspective subpar and hence you end up with setups like Next (SSR) with some Next pages having a stronger SPA notion (SPA within SSR).
People debate SPA vs SSR without any context. Both have their use case:
Everything before a login => SSR, everything after => SPA.
Why? SSR is proven to be much better at SEO. But SPAs offer best UIs. Nobody wants to click through stuttery SSR dashboards in 2019, wait for page loads, submits, etc. People prefer slick UIs, that was one of the reasons DigitalOcean got big (because of their then stunning dashboard or after-login-experience [1]) and hence every other hoster copied their interface.
[1] DigitalOcean's dashboard experience was for a long time the main teaser (as an animated gif/video) on their landing page.