Have you tried to implement interaction-rich applications such as calendars or text editors with server-side rendering? You won't be able to recreate the UX an SPA can afford, regardless of revenue.
Widgets require JS, of course. Javascript was born to sprinkle some of it on top of an HTML page, not to make a whole meal out of it. This is what GP is arguing about and I tend to agree. Single Page Apps are not worth the effort in my experience, apart from very niche use cases.
The velocity proposition and fantastic developer experience of writing JS in the backend and frontend and data layer is overrated and misleading. It's everything but.
I don't think anyone would take fault with using a SPA for a text editor. What most people are criticizing is using a SPA for a page that serves mostly non-interactive content. And that is the majority of the web, after all.
On whatever page you're using websockets, you're basically doing what an SPA does. If you click something and the page sends and receives a message via websockets and then updates the DOM, congratulations, you have something that's the same level of complexity as a SPA.
Your original post says that this style of interaction only exists to "fleece VCs". But it seems you're doing that, with an additional added layer of complexity on top (namely the server-rendered pages).
I'm guessing you implement the interactivity with <script> tags or something in your html/template templates, skipping the pain of npm and bundlers. I'm not sure that's the hard part of SPAs, though. Just an annoying one. The hard part is synchronizing the state of the frontend and backend over a communications channel.
Except not really, because one is architecturally simple and relatively easy to grok/hack, and the other is big and complex and built specifically for operating at a massive scale and multi-team environment.
We're talking ~200 combined LOC of idiomatic Go+TS & a couple popular libraries vs. an entire SPA framework and its various DSLs.
State synchronization over a long distance is always going to be a balancing act of performance vs. reliability vs. security. It's never simple and outsourcing those decisions to a framework is not always the correct choice as it may bite you later.
Similarly, some years ago I prototyped an ESC/POS client (?) for a Bluetooth thermal printer. It was implemented as a Chrome Extension/Chrome App pair, because only Apps were allowed to use Chrome's proprietary Bluetooth API back then. Extension and App communicated via postMessage IIRC. I was shocked how well that hack actually worked. Google then sunset Chrome Apps, and Web Bluetooth never happened.
You're exactly right - if you're writing readme's all the time, you'd have templates ready to go.
I only write readme's maybe once every few months or perhaps once a year, and having a template (interactive like this one, or otherwise) that someone else has thought about is super useful to me.
I actually do create a few README files every month (cos of Microservices), but I still don't understand why someone would use a tool to generate README files.
I wrote a README.md template because I started a bunch of projects of my own in the last month but I haven't used it so far and it is not more than a bunch of headers plus a license boilerplate.
Any hot swappable ergonomic board will be fine. Hot swappable means the switches can be pulled out of the sockets on the circuit board. Otherwise, you'd have to desolder the switches.
Edit: Do not worry, assembling a keyboard from parts is childs play. There's not a lot that can go wrong, just be careful not to damage the circuit board, and check that it fits the case.
Thanks for responding to me... I went into a deep dive, since I didn't know that was a possibility. Unfortunately, there are no full-size split hot-swappable ergonomic boards.
I can deal with a separate numpad, and I can use shortcuts to replace media/brightness/volume keys, but you can take away my arrow keys when you can pry them out of my cold, dead hands ;-) I'm not ready to go the chording route of something like the ErgoDox.
I found the Cloud Nine C989M, not hot-swappable, but ANSI layout only, no ISO, so it's out of bounds.
The Keebio has the Quefrency, which I can kit out with a separate numpad and wrist rests, but that's not hot swappable, and 1.5 to 2x the Matias Ergo Pro.
I think for now, it'll have to be the Matias, and maybe later I'll decide it's worth the investment to go chorded, or invest 4x what I'm used to (as opposed to 2x)
You can just substitute "framework" with any abstraction, eg "operating system", "graphics driver", "programming language". Might as well have been called the looking-under-the-hood movement.
My guess is they’re saying if you have a population of 20, you have 20 chances of mutation. If you have a population of 200M, you have 200M chances of mutation. Size matters.
Following that logic China and India should be a lot more problematic than Brazil. As a matter of fact, both of those countries "mismanage" Covid-19 as well.
Yes, and for a fixed mutation chance, the bigger the population, the greater the likelihood that a mutation will happen. Say a mutation has a 1 in 1000 chance of happening. For a disease that infects 1000 people, you would expect 1 person to end up with some mutation. If the same disease infects 1,000,000 people, you would expect 1000 mutations to occur.
You generally become better with more practice though, right? Whole 10,000 hours thing? Surely someone who spends more time developing will be better at it.
Now of course this doesn’t matter past a certain point — people could spend all their time working on something that doesn’t help them grow.
Then once you have those 10,000 hours of actual growth, you are probably close to a Senior developer level. Which after 5 years in an office job working 40 hour weeks, you’re there anyways.
But at the earlier levels of developers, it seems that working on projects outside of work would definitely help you improve faster!
I've seen this on Reddit a fair bit too but there's this sort of anti "10x-er" attitude. It makes logical sense to me that if someone spends more time practising a skill, then they would be more proficient and thus worth paying more. Yet there's a lot of pushback against that thought process because it is biased or something. Obviously there's more to a candidate than purely 'coding' skill but I find it weird that a company would want to explicitly avoid an indicator of time spent honing skill X purely because it discredits other people. I guess in an idealistic world it makes sense but the real world never quite lives up to the ideals.
I've found that a lot of hiring is explicitly biased against skill. The root cause is mostly the hirer wanting "people like me". Or, at least, not discriminating against "people like me".
I'm sure a lot of people who hire developers think of themselves as people who could write open source but don't have the time.
This also accounts for why stuff like leetcode persists (the hirers were successfully selected by that process), why top colleges are often preferred and even why the profession is predominantly white/male.
> You generally become better with more practice though, right? Whole 10,000 hours thing?
Except that 10000 hours thing is non scientific nonsense.
To improve, you have to practice right way. If you code for 8 hours at work, coding 2 further hours wont make you improve more. Similarly, if you want to improve in music or running, just playing songs or jogging means you will hit plateau pretty fast. After that, you have to train on correct selection of exercises.
At that point reading some theory will have much bigger impact, because yoi are doing something new. And even exercising will likely make you improve more due to what it does to body then further 2 hours of the same.
> I'm pretty sure almost nobody actually codes 8 hours at work.
The non-coding parts of work are necessary on oss projects too. In any case, programmers work being mostly coding + code review is pretty normal.
> Those two hours will be of a very different nature to "work coding" and this can lead you to learn things you wouldn't pick up at work.
That is nowhere near guaranteed and more likely to not be true. In particular, if you focus on maintaining the same software, it will be more of the same after a while.
> IME a far greater % is coding. There's also a lot of OSS people involved who don't code who help out with the other stuff.
It was not my experience. In work, the proportion of coding was bigger then when I maintained open source one. Mostly because company paid people to do other stuff. In OSS, afaik, it is was more of rare to have dedicated tester or to get already analyzed input. Also, the planning, organization, documentation, keeping tickets clean, decision making and so on are all on you. The ratio of project work is the same.
> It'll still be different to what you do at your day job and will necessitate picking up a different set of skills and a different perspective.
Maybe yes, maybe not. And after a while of maintaining the same software, you already maxed out what you learned. Moreover, you can learn new stuff without having side project. It has advantages, because then you dont have to finish and polish stuff. You just learn or try what interests you.
Lastly, side project is really not that dissimilar then working on the job - meaning job+side amounts to 10 hours a day work basically. It means your hourly effectivity will go down exactly like all studies on crunch predicts. You will get tired and slow.
as someone heading towards 5 years developing, I'm not sure it's as straightforward as you think (and if it is, I'd love advice on how to improve). In my career so far my work has roughly gone in phases of backend, frontend, devops/infrastructure. I've been able to improve my soft skills of learning how different organizations work, learning how to network and collaborate, learning how to learn, etc, and improve my technical skills of development, learning about best practices, etc, based on the particular technologies I work with at a given time. But I haven't had the chance to just spend 5 years progressively leveling up my java backend or javascript frontend skills. As a result I don't think I would qualify for a senior developer level quite yet. But by that token, perhaps I'm also not the best person to say whether or not this is the typical path for a sr dev or not
