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.
I'm an occasional lurker here but I created this account because of this comment as it represents what is so annoying about this community sometimes.
What exactly are you aiming to achieve with this comment? Sometimes the best thing to say is nothing at all.
> 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.
Who are you to say it's wrong? Even if people are doing it for the wrong reasons, the fact that they are doing it means that this post is relevant to them. To call the post "wrong" is so arrogant and adds nothing to the contribution. All it does is give you a useless delusion of grandeur that makes you think you know better than this author, or those that find value in the post.
> - 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.
This makes no sense. If you're still advocating for eventually going to give talks, why did you start off by calling this post wrong when it gives advice to people that want to speak?
> 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.
This sounds like a personal problem for you. And no, one so-so talk on Youtube about your vim config at some third-class conference isn't necessarily worse than nothing
> 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, sometimes you need script writers, media trainers, etc.
If you're moderating a meeting with 10-50 people, good public speaking skills will go a long way into making the meeting worthwhile for the attendees.
I have no relation to the author of this post, but it's jarring seeing comments like that throw away nuance and kindness, and let out arrogant statements all under the guise of intellectualism.
Honestly, that seems like an overstatement. The same could be said for anything finding its way onto the internet that doesn't represent you at your current best. Maybe if you're a really bad speaker/writer/etc. and, for whatever reason, think you will never get better you should be cautious about doing anything that will expose you online. But I'd suggest simply improving might be a better approach.
In the case of speaking specifically, if you don't start off giving maybe so-so talks at a Meetup, you're probably never going to get better.
ADDED: To your example. So if your first C++ code doesn't hit it out of the park, you should just give up?
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.
I don't think I was being aggressive. To the degree I was, it's because I do think--as an industry--we should encourage people who don't consider themselves part of the established elite to put themselves out in public.
And I know tons of people who do public speaking where it isn't a career path or even (really) their primary day job--a number of whom are quite good about it.
Of course, if you have nothing to talk about you shouldn't give a talk. But I wouldn't discourage anyone who has something they want to share--even if it's unrelated to their day-to-day work or it's potentially trivial. It's frankly the job of the conference organizers to decide whether it's potentially relevant and interesting to attendees.
Long term lurker as well, but your comment comes off in bad faith. When you decide to try and break apart each point piece by piece to address, instead of his whole argument as a whole, it signals that you're only trying to argue for arguement's sake. Please don't do this, because it ruins the vibe.[0]
In one enormous post, you have managed to tip-toe the line of civility with passive aggression, but also outright hostility "so arrogant," that it comes into question whether or not the GP's comment was directed at your specific demogrpahic: people that do things because they feel they want to, and not because they have thought it through.
Perhaps you should ask yourself the same question: "What exactly are you aiming to achieve with this comment?"
From an onlooker's perspective, it comes off as needlessly aggressive, but without clear motive. One could say the only purpose of your comment was to express that aggression, and not to spur interesting or novel dicussion.
In that likely case, you are posting in bad faith, and as you said "sometimes the best thing to say is nothing at all."
[0] I've been around message boards since usenet. This behavior isn't new, and neither is it appreciated.
If your assessment is that my comment was to express aggression, that would be correct. I thought about what I was trying to achieve and I felt that I didn't owe the OP any grace, since he failed to extend grace to the author of the post. My goal was to express how I felt about the OP's comment as directly as I could, so they could perhaps consider it the next time they want to make another comment like that. Whether or not being less aggressive would make my point more useful is a separate discussion, but at the time of writing the comment, I opted for a bit of aggression.
And FYI, I've not spoken at any conference and I have no interest in speaking at one, so I don't think the comment was directed at my demographic, I just found it to be distasteful.
I thank you for expressing self-awareness and civility in your reply.
Emotions are what make us human. Complex expressions of neural impulses that manifest as many different feelings which move us to action. However, like any other impulse, the understanding of and their proper utilization, always brings greater utility to one's life.
We can all agree that unbridled emotional expression -- that is the actions those emotions move us to do -- can become harmful by their unchecked nature. We can also all agree that emotions have a purpose, and to repress them is not the best of decisions.
Then perhaps there is a useful middle ground. Call it, "emotion, but in moderation." That by stepping back and analyzing our emotions, what caused them to appear, and why we feel the way we feel, we can in-turn make better, more productice decisions.
What flowers from this post, is of no concern of mine, but I felt moved to plant these seeds.
> 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.
I hereby make a standing offer to work with any professional public speaker to pair with them to write kernel code. Like public speaking, it's a learnable (and teachable) skill, and if you're interested in it, nobody should stand in your way and say it's not worth your time or that it's pointless.
(You, meanwhile, should put a name to your comment so that we can swear never to hire you. You're a 0.1x engineer: your presence on a team will demotivate other people in the organization.)
I know some "normies" get on our nerves Like "Jared" but the thing is:
Jared is nice, has some friends and more people want to be around him so his chances of happiness are greater.
I really wish you expose your work on Hackernews you seem a very good and intelligent (did not mean wise).
Please show your skills and work it may improve your market rate or even maybe people can contact you and exchange information.
This is incredibly negative. You could make the same comment about any public form of communication. Speeches, articles, heck even a Twitter post.
This is an absolutely destructive viewpoint in particular for all those brilliant people who do interesting stuff but never think they are ready to share their story just because they are no Jimmy Fallon. Being bad at things in the beginning is part of every journey.
That was my initial reaction as well. Basically, never be a first-time speaker because you might not be perfect, at which point you might as well get out of the field.
I'm sure I'd cringe to see early talks I gave at events. (To say nothing of more recent ones that just didn't come together as I intended. Or, heck, even IMO good ones that aren't as good as awesome speakers give.)
I'm an obstinate lurker of HN, but I felt moved to create an account to address your post -- and another's.
It was a breath of fresh air to read your experiences, and the way you decided to put into writing what your intuition had surmised from said experiences. I read forums religiously to keep my own worldview fresh and to stave off the natural human inclination to bring myself into a homeostatic perception bubble.
Uncannily, one of the most common things I've found is the exact type of person you've described: one that doesn't think about what value their post will bring to others, but only to post for posting's sake. You and your post are an exceptional delight, and I thank you for sharing.
The world -- and by extension the internet, a microcosm of said world -- is overrun with wishy-washy expression that only appears to express a lot, but when stripped of all it's fat, manages to express nothing at all (f.e speaking a lot, but saying little).
As an addendum, my apologies for coming off in the same manner as the subject of your ire. Appearances are important, after all.
The problem with this is you'll end up with just TED talks. Very entertaining soundbites by super-professional speakers. But the guy with all the technical knowledge who works on code all the time doesn't speak because he's not Tony Robbins. That'd be a shame.
Are there many talks about a single person's vim config? That seems like a poor topic to me, and I'm not sure how many people would consider it a good idea.
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 ;)
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.
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?
Yang wants to give everyone legal ownership of their own data. That is going to be more disruptive to the tech industry than antitrust rulings against a few companies.
What does that actually mean in practice? From a technical perspective, thanks to GDPR, Facebook and other sites now let you download your data (even outside EU), but it hasn't led to a resurgence of competition in social networks. From a legal perspective, you do own the content you provide to Facebook, you only provide them a non-exclusive license to use it.
I think an obvious but interesting thing about video-based business models in general is how their storage costs per video are basically indefinitely constant, but their revenue per video declines dramatically. 20 years from now Youtube might have 100x more content to store on their servers but it probably won't be getting 100x the views. I think the internet hasn't been around quite long enough for these kinds of things to become a real problem just yet.
Certainly one plausible future is that, if your video isn't making them money after some period, you either pay them some ongoing fee to keep it live or they delete it. After all, that's the model for most other hosted content.
That YouTube is a free hoster for video content wasn't inevitable and isn't guaranteed going forward into the indefinite future.
There's no law of nature that data/eyeballs-based monetization (including advertising) has to remain viable everywhere that it is today. I find it entirely plausible that 10 years from now people will have to directly pay for more of the services that they use.
You're already seeing this with the increased number of paywalls around publication content. I expect we'll see more subscriptions and services just shutting down if people aren't willing to pay.
I feel like because he's new and trying to shake things up that people are holding him to way higher of a standard than other candidates. Other candidates have been throwing things out there like wanting to provide healthcare to everyone (just one example) and as far as I've seen they've provided no plans for how they will make this happen. Yet for Yang everyone wants to see every detail of it. I also feel like this may be lead by organizations that don't like that he's shaking things up (apparently the DNC told him not to even mention the threat of automation because they don't want to scare people, as if putting our heads in the sand gets anything done).
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.
OP's reason for making this is mentioned in the "about" section of the page - sending physical photos to people who prefer those over something like Instagram.
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).
There are cases where sending real postcard is not feasible. E.g. traveling in mountains. Sometimes you are a little bit lazy but still want to make it at least a little bit personal.
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.
As mentioned elsewhere in the thread, we're working on a major rewrite of the Redux core docs. If you've got any specific suggestions on how we can improve them, please let me know.
When you say "no quick and easy way to get started", are you referring to code or docs?
In terms of explanations, RTK is currently documented as a separate layer on top of Redux, because that's really what it is. So yes, we do assume that folks have learned what Redux is and how to use it already, and RTK is then a faster and better way to write Redux logic instead of doing everything "by hand".
As part of the core docs rewrite, we do intend to completely redo the tutorial sequence, and we'll be introducing RTK somewhere in the tutorials and encouraging its use.
The first thing I do when teaching someone Redux is tell them that Action just means Event, and "action creator" just means an event dispatcher, which is to say, any function that dispatches an event. Naming the least-active part of the system Action is really confusing—it doesn't even describe an action, necessarily, nor force any action—and naming a function that happens to emit an event an action creator as if it's creating actions (huh? what does that mean?) is misleading.
This is specifically due to the fact that the original Flux implementation labeled these objects as "actions", and Redux was designed as a Flux Architecture implementation:
Is it too late to change it? I’ve worked at a few agencies for a lot of companies using Redux. Teaching people to think of actions as events instead of setters has been a huge pain point.
I would seriously suggest just find and replace the word action with event within Redux and the docs. Maybe have one page explaining the history behind this.
We'll be adding more pages with info on that topic as part of our ongoing core docs rewrite. I'd suggest pointing people to this style guide entry, as well as these excellent presentations that go into more detail:
> We certainly aren't changing the actual name "action" to "event" in the code or docs.
That's what I think should be done, with a page noting that historically they were called actions but events is a better name. I think it's the right move to help people understand Redux better and write better Redux code.
There are still people learning Redux for the first time today and the current docs and the name "action" seems to push them towards writing imperative code.
IMO imperative actions are the biggest issue people have using Redux.
I guess a first step in the right direction might be just redoing the docs in an event style. e.g. The counter example would use events like "clickedIncrement" and "clickedDecrement".
As long as I'm giving feedback on stuff, I really like createReducer (builder api) and createAction from Redux Toolkit. I think createSlice encourages the action = reducer anti-pattern.
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.
Great and substantive comment. Docs should be example and results driven or they're not really docs. Django and now Rails do a good job of this, in part because they're frameworks. But even for something of the size of Redux, it would be fantastic to see a basic mobile todo app with a navigation bar and a basic logged in/logged out mode built from scratch to show you how to manage state in the real world.
Thanks for the feedback. I've pasted it into our "Docs Rewrite: Overview" issue for reference [0].
Responding a bit further:
There's not much we can do about folks going back and forth between Redux and various non-Redux-y things. That's outside of our scope and ability to help with.
Teaching-wise, there's several reasons why the docs are structured the way they are right now:
- Redux itself is an independent library that is not tied to React in any way (and is used with other frameworks / UI layers as well). Our docs do mostly assume that you're using React, but the tutorials start out trying to show how you'd use Redux without any UI layer, to teach the basic concepts.
- React-Redux has been a separate library from Redux itself since it hit 1.0. While we do teach the basics of how to use React-Redux in the Redux core docs, it has its own separate repo and separate docs site. Similarly, RTK was designed as an addon layer around the Redux core, so it also has a separate repo and separate docs site, and its docs assume that you understand the basics of Redux already.
- That said, yes, the vast majority of Redux usage _is_ with React, and we are encouraging folks to use RTK as the default way to write Redux logic. So, it's very reasonable to have a docs page that shows how to jump right into using both of them as fast as possible. This is something I've already said I want to add to the docs, as a "Quick Start" page [1].
In terms of teaching flow and learning, there's various ways to approach explaining things. Dan Abramov wrote the original Redux docs content and structure, and his teaching style is very much "bottom-up, from first principles". You can see that style in pages like the current "Middleware" tutorial page [2], and his Redux videos on Egghead [3]. That approach works great for some people, but other folks just want to be shown _how_ to do something first, and learn the "why" later. It's hard to serve both groups at the same time.
One issue with teaching RTK first is that while Redux requires / expects that you use immutability correctly, RTK's use of Immer does hide the fact that immutable updates are happening in the background. It would be easy for someone who learns Redux via RTK to assume that writing mutating logic _is_ the right way to write reducers, not realize that it only works right due to the "magic" inside RTK's APIs, and then go write reducers in another project without RTK that are completely buggy as a result. I haven't yet entirely figured out how to handle that aspect, other than plastering warning notes all over the docs. That's one reason why I would prefer that folks understand the core principles first and how to do things by hand, and then switch to RTK to write the same code in simpler form.
As I said earlier, there's good reasons why we have separate libraries and separate docs sites. I can hypothetically imagine pulling things together into a combined docs site, similar to how NgRx does it [4]. But, I'm not sure how technically feasible it would be. It might require restructuring everything into a mono-repo, and I don't think I want to have to figure out how to migrate everything at this point.
All that said, yes, part of the goals for this Redux core docs rewrite is to provide a much more obvious learning path.
Finally, no, I don't think RTK is "killing the ecosystem around Redux", as the ecosystem is much broader than what RTK includes. RTK does obsolete a lot of similar libraries, but there's many other pieces out there for other use cases.
Yes, I'm a Redux maintainer. My point is that I can't do anything to prevent folks from asking "what state management approach should I use?", looking at NPM trends, reading other tutorials that espouse differing approaches, or jumping back and forth between the React, MobX, and Redux docs sites. All we can do is try to provide as much helpful info in our own docs, and even that assumes that folks even _read_ the Redux docs. I see a lot of people asking "I want to learn $TOOL, what's the best course on Udemy?", and not even looking at the actual docs for $TOOL at all. Doesn't matter how good the docs are if people don't read them :(
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.
I don't consider this a settled conclusion. Mostly because it's a false dichotomy. There are alternatives to both SSR of component sites and SPAs, and every solution has its inherent advantages and disadvantages.
UI isn't even the primary feature of an SPA, that would be offline usage.
Having more interactive elements without page loads is a feature of "DHTML", and that can be had from anything between small embedded snippets of vanilla JS to full-fledged SPA frameworks. Intermediate solutions like StimulusJS or AlpineJS seem to be getting a bit more popular, too.
But in this Fallen World, it seems we're usually getting the worst of either extreme usually. Either a long rendering time for a whole page, then delivered in one "flash" (assuming you've got a fast connection), or multiple elements popping in and out while several JSON-RPC requests are made.
You can optimize both cases, of course. Proper caching/DB views etc., or things like HTTP2/GraphQl/React Suspense etc.
But it's definitely not an either/or answer. Few things in fiddling around with computers are.
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).
Yeah, I never quite liked the currenly en vogue mixed approaches, where it's harder to draw a line, you often have to serve two masters and you feel it's mostly done that way because React developers don't want to learn anything else, despite cases where a complete server-side approach with an old-school template language might be a better fit, despite how hip functional reactive component based development is.
But about the smaller stacks other environments have: That's quite often because you either don't need additional parts (e.g. there's no desire for a huge Django template "community") and/or because other stacks are more full-fledged and thus the horizontal size is a lot smaller, with no need for umpteen state management solutions, state management solution helpers and state management solution application templates.
Dashboards could probably serve as a whole different topic. It was easy to beat the old school ones, where Perl CGIs roamed the prehistoric landscape. More modern CSS, and JS graphs alone beat the old rrdtool setups you often saw.
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).
I don't think I heard "SSR" in a context where it's just about backend HTML generation like we did in the olden days, only when it comes to reify JS views on the server. Haven't heard of an embedded JS interpreter or transpiler that does that.
When it comes to generating dynamic or static web page content, the pathological framework-aversion of the Go community strikes hard. Probably nothing that doesn't use the built-in Go templates with any sufficient user backing. This doesn't appear to be a language that can birth something like RoR.
As for the maintainability of react, I'm not so excited. It's a pretty decent templating system, and it seems easy enough to compose components, but beyond that it's each to their own, with some approaches being better than others. And redux still doesn't grab me as that great, it's just the sheer amount of developers resulted in a nice toolset. Whether it's frontend or backend, the twin async and dependency hells of JS don't manage to make me sleep any better, either.
I don't give a flying frick for age myself. Sure, there's less tooling for partials than for components, but that might have a reason.
Thank you for this very practical advice. The thought of trying to dynamically decide whether to render on the client or server side, as the author of this article did, seems so over-the-top complicated to me. Taking your advice is something doable for us mere mortals.
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.
[1] https://www.youtube.com/watch?v=TPVQ3M9b6CY