hello Javascript, oh how I've missed you

Summary

In this video, the creator reflects on their two-week journey with Go, HTMX, and Temple, initially attracted by Go's performance but eventually returning to Next.js due to a better developer experience. They discuss the verbosity of Go, its superior error handling, and the frustrations with HTMX's mental model compared to React and Svelte. Despite recognizing Go's strengths, they prioritize developer experience and productivity, choosing familiarity with JavaScript and TypeScript over exploring new technologies.

Takeaways

• 🎥 The speaker transitioned back to Next.js after a two-week experiment with Go and HTMX, finding the developer experience with JavaScript more enjoyable.
• 📉 Despite Go's performance benefits, the speaker missed JavaScript's features like string interpolation and the flexibility of TypeScript.
• 🛠 Go's error handling was appreciated for its explicitness, but it also added verbosity that the speaker found cumbersome for quick prototyping.
• 🔄 The speaker encountered issues with HTMX's mental model, preferring the reactive data model of frameworks like React, Vue, and Svelte.
• 💻 The use of VS Code with Go and Temple was problematic, with the speaker experiencing a disconnect in the editor when working with templates.
• 📝 The speaker found Go's package system to be rigid, making simple tasks like file-based routing more complicated than necessary.
• 🔧 The speaker's experimentation with different stacks, including Laravel and Elixir, ultimately led to a reaffirmation of their preference for JavaScript and TypeScript.
• 🚀 The productivity and vast ecosystem of Next.js, React, and associated libraries were highlighted as significant advantages for quick feature implementation.
• 🔍 Debugging and maintaining UI states were easier with React's data-driven approach compared to HTMX's server-driven component updates.
• 🛑 The speaker faced bugs and inconsistencies with HTMX and Temple, which added to the decision to switch back to familiar technologies.
• 🔗 The speaker values the lack of context-switching between front-end and back-end development when using JavaScript/TypeScript for both, streamlining the development process.

Q & A

Why did the author initially decide to create a video about saying goodbye to JavaScript?

The author created the video 'Goodbye JavaScript' after experiencing performance issues with their Node server and discovering the superior performance and simplicity of Go and HTMX.

What was the reaction to the author's video titled 'Goodbye JavaScript'?

The video received more views than expected and notably, the Prime Engine reacted to it, which the author was excited about.

What issues did the author encounter when transitioning to Go and HTMX?

The author faced several issues such as verbosity in Go, disconnect in the editor experience with HTMX templates, and difficulties with error handling and package system rigidity.

How does the author feel about Go's error handling compared to Node.js?

The author finds Go's error handling to be significantly better than Node.js due to its explicit error returns and the ability to anticipate potential errors at function definitions.

What was the author's experience with HTMX's syntax and template handling?

The author found HTMX's syntax and template handling to be less intuitive, especially when dealing with inline templates and the disconnection in the editor when navigating between files.

Why did the author decide to switch back to Next.js?

The author decided to switch back to Next.js due to the developer experience, the familiarity with JavaScript and TypeScript, and the ease of maintaining and debugging complex UIs.

What are some benefits of using Go according to the author?

The author acknowledges that Go is simple to learn, performant, and has a good error handling system. It also compiles down to a small binary that is easy to deploy.

What challenges did the author face with HTMX in terms of UI complexity and maintenance?

The author found HTMX challenging when dealing with complex UIs due to the need to manage IDs and the lack of type safety, which made it difficult to maintain and debug.

How does the author view the mental model of HTMX compared to other frontend frameworks?

The author prefers the mental model of other frontend frameworks like React, where the UI reflects the data model updates, as opposed to HTMX's model where the backend is responsible for sending components.

What was the author's experience when trying to implement a counter with HTMX in comparison to React?

The author found it cumbersome to implement a counter with HTMX, requiring inline JavaScript and dealing with IDs, whereas in React, it would be as simple as updating the state and recomputing the UI.

Why did the author decide to stop experimenting with different tech stacks?

The author decided to stop experimenting due to the time investment required to learn new stacks and the realization that their productivity and enjoyment were higher with their familiar JavaScript and TypeScript stack.