dan_can_code

I have found this to be almost universal when it comes to reading / writing documentation, not just Google.

I have come to the understanding that to write good documentation, you should write it as soon as you have learned it, or at least, try and explain in a similar way in the way you learned (which is not easy at all). I feel the issue stems from abstraction. Once you become somewhat an expert in a topic or develop a deeper understanding of said topic, you automatically abstract away the information that lead you to that understanding in the first place.

Otherwise you end up reading or writing documentation with a bunch of assumptions for knowledge and understanding, which are not only not stated but may not be available to the person trying to get to grips with the technology. A bit of a digression from the post, but I don't feel this is just a Google thing.

Thanks for getting back to me. I wasn't expecting a response. As you've mentioned below it is now off which is great. It was just a very jarring, personally I feel its best to allow users to make their own opinions of the experience, I don't find the dark mode experience that bad at all. The text is white and the background is black. Good enough for me!

Nothing to do with the content but the pop up for 'lack of dark mode optimisation' on this website is more annoying than the actual lack of dark mode optimisation

Parasite.

The movie (for me) is such a reflection of globalisation, capitalism and the hard truths of the lives of the people at the bottom as well as the top. I really enjoyed its portrayal of class in our modern society and how we, as humans in this society, can be 'parasitic' towards each other. The poor want the riches of the top, and the rich use the poor to enable their high living lifestyles. It really changed my perspective.

I disagree. JavaScript historically has always offered backward compatibility.

> Backwards compatibility is important because of the large number of browsers deployed and the wide variety of versions of those browsers [0]. This may be the reasoning behind offering backwards compatibility.

Also, according to the GitHub page [1] the fallbacks are WebGL2, and WebGL 1, and if neither of those work, only then will it use the CPU when in the browser. I find this to be quite acceptable. After all, it is JavaScript!

[0] https://stackoverflow.com/questions/4937245/why-is-javascrip... [1] https://github.com/gpujs/gpu.js/wiki/Quick-Concepts#fallback

That doesn't cover the 'on any device' requirement.

> because research suggests that going to the dark side ain’t all that.

So what? It's personal preference. A few studies aren't going to affect how most people rationalise it to themselves, because, who cares?

The insurance industry in the UK is a great example of this.

Manual data entry for claims via the phone and a system called 'TAM'.

There are roles such as 'claims handlers' who's job is to repeat what is said over the phone into TAM.

Cut out the claims handler and present the claimant with a form, and their jobs are gone.

Thanks for the info. I look forward to learning from it. I will try the 'on the job' approach as that's how I learn most effectively. :-)

I absolutely agree, were it something commercial these things would need to be considered.

Are there any tools you recommend looking into, were I to take the next step? I don't plan on depending on CapRover to fill gaps in my knowledge for too long, but for now this product really is a good start for me.

Then I will have to learn then. I feel most productive and comfortable working on a hobby project if I don't need to spend all of my time dotting the i's and crossing the t's with cli and configuration files. I just want to build. I don't see the value investing my time learning the ins and outs of tooling that I will use maybe a few times when it makes minimal impact, as it comes with an opportunity cost for me elsewhere. That's just me though, I have no gripes with people who love to tinker with their set ups. It just isn't my thing.

This tool looks really cool. The section where it listed reasons for using it really struck a chord with me. I am not the most comfortable using all the Linux tools when it comes to setting up servers / system administration. This product looks to be a really good bridge between devs who dev primarily, and those with skills in deployment. Super cool. Thanks for sharing, I will be using this!

Thanks for sharing this! As a dev who would like to improve my awareness of design, this collection of resources will definitely help me learn.

Maybe xfce can see past the trivial issues with javascript for more benefits elsewhere within Gitlab for managing their project(s).

Thanks for sharing Daniel. I'm not sure if you're aware but netlify and vercel offer free domain hosting for Javascript / JAMstack projects. They both also offer pretty decent free CI/CD workflows, but I'm not sure how that works with custom images or anything.

$28M seems like an awful lot for a static site generator. The issue I see Gatsby facing is that the poor developer experience will catch up with them, regardless as to whether they expand their ecosystem (plugins etc). If the developer experience isn't improved, I doubt their money will convince '1%' of all websites development teams to make the switch. Especially if this thread is a good approximation of the mood towards developing with gatsby.

However, it's much too easy to join in with the typical HN cynicism to shiny new things. Maybe Gatsby will surprise us and become a contender within the CMS space before long.

My pleasure, Colin. I am too lazy to use brackets and hashes in my writing is all - glad it works for you, regardless.

I think from the context of your writing - it was fine. I found it pretty clear it was from your 'personal' view. As they say however, all publicity is good publicity - I look forward to any more content you will be posting!

Joplin looks really interesting - thank you for the recommendation!

I have given them a go - but I had some privacy concerns. I may look into this again, thank you.

I agree, bear is great. I miss it - I no longer have an iPhone and am Windows dependent :-(. I have made the best use of OneNote as I can - but the ease of categorisation of thoughts within the bear app will always be the best imo.

What point are you making? The linked blog post just defines simple and easy. I am not sure how this relates to your previous comment regarding dependencies.

> In essence simplicity is about reducing then amount of waste in development and increasing the longevity (service life) of the system we build.

I would argue the implementation of nextjs in the context of static, react-based a blog falls under this definition in your linked blog post. Unless I'm missing something?

Regardless of the dependencies, the point that it is the 'simplest, most elegant way to generate a static version of a React-based website' applies. Next.js is ridiculously simple to get up and running with - even for JS rookies.

As another user mentioned, Next.js has a 'next build' command that creates a HTML build at build time. But it also provides server-side rendering by default.

Next.js also provides a very useful function: getStaticProps. This function will be called at build time - and will provide your (now static) build with dynamic data! It's pretty cool.

> Three hours of package bumps

It takes less than ten seconds to type `npm update`.

This is so strange - I am on course to build my own developer blog with a similar stack (minus TypeScript, and syntax highlighting).

I am also using a CMS instead of just plain markdown - in this instance it is NetlifyCMS.

Netlify CMS is the perfect go-between of a fully-fledged CMS, and a much too basic static site with just markdown - I dislike the experience of writing markdown and would rather use an editor.

With NetlifyCMS - the blogging flow is as follows:

- User logs into NetlifyCMS

- User updates content

- Content is 'pushed' to the repo as a commit.

- CI / CD picks up changes on master branch

- CI/ CD publishes changes

- The site is updated!

The example code can be found here: https://www.netlifycms.org/docs/nextjs/

It is extremely simple to get up and running - but also offers great flexibility if, as the author has stated, you wish to use your website to demo components - visualise data, anything custom really!

The only difference with my implementation is instead of using the `public/` folder, I created an 'admin' folder within 'pages', with an index.js file for the HTML contents, as referenced here: https://www.netlifycms.org/docs/nextjs/#adding-netlify-cms. The only reason being, I didn't want to have to specify '/admin/index.html' every time i want to edit the content.

My only gripe with this blog post - is its insuniation that it is 'ideal'. I think its pretty clear from the post, it is only 'ideal' for the author. Unfortunately, the HN community has taken the opportunity to rip apart the authors opinion - which is disappointing. Thanks for the content, Colin!

I also struggle but find that if I choose a few libraries and tools that I would like to make use of, I try and build a project around them - doesn't have to be anything in particular, just a kind of playground for the cool libraries and tools.

I'm just curious, but why do you recommend this? Is it so you can have a name for yourself in your chosen passion? Is it to show you are competent?

Hi Stephen,

Thanks for sharing this. I am a mid / senior engineer trying to work smarter and I believe this newsletter will help me with thinking about problems in the correct context and asking myself the right questions.

I really appreciate the resources attached to this particular topic (the list of questions) as it is something I have personally struggled with in the past in my career.

Do you by any chance have a sneak preview on topics you will be addressing in the near future? I have just been made redundant so am taking the opportunity to learn as much as I can before I get into my next role.

Thanks again!

I suppose this is a good and a bad thing. It's good in a sense that if remote companies wish to attract better talent, they just have to out-pay Facebook. It would be bad if all tech companies decided to pay everyone less however, following Facebooks lead. It will be interesting to see how this plays out.

I did happen to use that - but when you click on the topics it asks for a log in. I'm not well versed in the financial world so I was hoping this tool would be a little more transparent.