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.

Outlines

00:00

😅 Struggling with Go and HTMX: A Developer's Dilemma

The speaker begins by expressing initial hesitance to create the video, reflecting on their two-week journey with Go and HTMX. They recount the attention their previous video, 'Goodbye JavaScript,' received and the contrasting experiences they had with Go's performance and verbosity compared to JavaScript. The speaker also acknowledges the superior error handling in Go but finds it cumbersome at times, especially when rapid prototyping is needed. They mention their comfort with Next.js and the biases that come from being a JavaScript developer, setting the stage for a detailed discussion of their dislikes and challenges with Go and Temple.

05:00

🤔 Go's Verbosity and Error Handling: A Double-Edged Sword

The speaker delves into the verbosity of Go, particularly when it comes to string interpolation and the absence of features like JavaScript's template literals. They contrast this with Go's robust error handling, which, while more explicit and safer, can become verbose and tedious. The speaker also discusses the challenges of working with databases and third-party APIs in Go, where error handling becomes crucial but also cumbersome. Despite recognizing Go's strengths in error management, they express a preference for the flexibility and rapid development capabilities of Node.js and JavaScript.

10:01

😐 Navigating Go's Package System and Temple's Syntax

The speaker discusses the rigidity of Go's package system and the challenges it presents when organizing code, especially when compared to the flexibility of JavaScript's module system. They share frustrations with Temple's syntax and the disconnect it creates within the editor environment, such as the inconvenience of navigating between template files and their compiled Go counterparts. The speaker also touches on the overhead of managing multiple file types generated by Temple, which they find clutters their codebase and detracts from the development experience.

15:03

🔧 Experimenting with HTMX and Hono: A JavaScript Developer's Perspective

The speaker shares their experience trying HTMX with Hono, a JavaScript framework, to see if the language familiarity would make a difference. They find themselves writing JavaScript in an unconventional way to achieve simple tasks, which highlights the friction they feel when using HTMX compared to the reactive data models of React or Vue. Despite HTMX's innovative approach to handling UI updates through server responses, the speaker finds it less maintainable and more complex than the state-driven approaches they are accustomed to.

20:04

😓 HTMX's Complexity in Sophisticated UIs and Debugging Challenges

The speaker elaborates on the difficulties they encountered with HTMX, especially when dealing with complex user interfaces and the need for precise debugging. They express a preference for the straightforward data model updates in React or Vue, which automatically reflect in the UI, as opposed to HTMX's approach, which requires manual management of UI state through server interactions. The speaker also mentions specific issues they faced, such as persistent loading indicators and buttons not re-enabling, which led them to contribute to HTMX's development by reporting and fixing bugs.

25:05

🛑 Embracing JavaScript and Next.js: A Return to Familiar Productivity

In the final paragraph, the speaker concludes their experimentation with various new technologies and frameworks, deciding to return to their roots as a JavaScript and Next.js developer. They reflect on the productivity and ease of implementation that Next.js and React offer, especially when compared to the challenges faced with Go, Temple, and HTMX. The speaker acknowledges the learning experiences from trying new technologies but ultimately prioritizes the efficiency and joy of coding with the tools they know best.

Keywords

💡Nextjs

Next.js is a JavaScript framework for building user interfaces and web applications. It is known for its server-side rendering capabilities and ease of use with React. In the video, the creator expresses a preference for returning to Next.js after experimenting with other technologies, citing familiarity and good developer experience as reasons.

💡Go

Go, often referred to as Golang, is a statically typed, compiled programming language designed at Google. It is known for its simplicity, performance, and efficiency in terms of memory usage. The video discusses the creator's experience with Go, highlighting its performance benefits but also verbosity in certain aspects like string interpolation.

💡HTMX

HTMX is a JavaScript library that allows developers to create dynamic and interactive websites using HTML and server-side technologies without writing much JavaScript. The script mentions the creator's dissatisfaction with HTMX due to its complexity and lack of maintainability for sophisticated UIs.

💡Error Handling

Error handling refers to the process of responding to the occurrence of various types of operational faults programmed within a software system. The video contrasts error handling in Go, which is explicit and part of the language's design, with the more implicit handling in Node.js, where developers must anticipate and manage exceptions.

💡Type Safety

Type safety is a property of a programming language that prevents type errors by enforcing rules on the types of values at compile time. The creator appreciates the type safety in Go but finds it restrictive compared to the flexibility of TypeScript, which allows for rapid prototyping and less strict type enforcement.

💡Verbosity

Verbosity in programming refers to the use of more words or code than necessary to achieve a particular task. The video script mentions Go's verbosity, particularly when it comes to string formatting and error handling, which the creator finds cumbersome compared to JavaScript's more concise syntax.

💡Developer Experience

Developer experience (DX) is a measure of how easily and efficiently a programmer can work with a particular tool, framework, or environment. The video emphasizes the importance of a good developer experience, with the creator opting for technologies that enhance productivity and enjoyment while coding.

💡Performance

In the context of software, performance refers to how fast and efficiently a program runs. The script discusses the superior performance of Go in terms of memory usage and execution speed compared to Node.js, which was a significant factor in the creator's initial attraction to Go.

💡Concurrent Programming

Concurrent programming involves writing programs that can execute multiple tasks simultaneously. The video mentions Go's built-in constructs for handling concurrency, such as channels, which the creator finds more elegant and convenient than Node.js's approach using workers.

💡Ecosystem

In software development, an ecosystem refers to the community, tools, libraries, frameworks, and platforms that support a particular programming language or technology. The creator expresses a preference for the JavaScript ecosystem due to its vast array of packages and the ability to quickly implement features without context switching.

💡Indie Hacker

Indie Hacker is a term used to describe an individual or small team that creates and operates a software product independently. The video's creator identifies with this mindset, valuing the ability to quickly prototype and ship projects, which influenced their decision to return to familiar technologies like JavaScript and Next.js.

Highlights

Creator's transition from JavaScript to Go and HTMX, and eventual return to Next.js due to developer experience preferences.

Go's performance advantages and simplicity in creating bundles compared to Node.js, but verbosity in string interpolations.

Go's superior error handling compared to Node.js, with explicit error returns and handling at function calls.

The frustration with Go's verbosity, especially when dealing with simple tasks like writing to a database and wanting to panic on errors.

The creator's preference for JavaScript's flexibility in quickly prototyping without strict type enforcement.

The benefits of Go's compiled binaries for easy deployment, contrasting with the interpreted nature of JavaScript.

The rigidity of Go's package system and the difficulty in organizing code across different directories and packages.

The creator's dissatisfaction with HTMX's approach to frontend development, preferring React's data-driven UI updates.

HTMX's lack of type safety and the difficulty in maintaining UI state, especially with complex applications.

The challenges with HTMX's mental model of having backends responsible for UI components, leading to unmaintainable code.

The creator's unsuccessful attempts to enjoy HTMX after trying it with different backends like Go and Hono.

The productivity and ease of use of JavaScript and Next.js ecosystems, especially for quickly integrating third-party packages.

The creator's realization of the limitations of trying new stacks and the decision to focus on their strengths with JavaScript.

The comparison of different backend frameworks like Laravel and Elixir, and the creator's preference for flexibility over built-in functionality.

The creator's decision to embrace their identity as a JavaScript developer and the commitment to focus on Next.js for future projects.

Reflection on the learning process and the value of exploring different technologies despite returning to familiar tools.

The importance of developer experience and productivity in choosing the right technology stack for project success.

Transcripts

so I feel kind of dumb making this video

and I was honestly just going to like

not even make this video and just let my

slow transition back to nextjs but I

figured maybe you all can just hear my

perspective on the go htx journey I went

on for two weeks so two weeks ago I made

a video called goodbye Java Script it

got a lot more views than I was

expecting and also the prime engine

reacted to it which I was actually

psyched about I appreciate you reacting

to my video but with that all being said

and all the complaining that I did in

that video about like the performance of

my node server eating up memory and how

go is like so much more performant and

just simpler to create a bundle with as

I started coding with go and HTM X and

Temple there's just so much stuff I ran

into and I realized that I would rather

have a hit in performance if I have a

good developer experience and so this

video I'm going to talk about some of

the things I ran into when coding with

go Temple HTM X and things that I'm just

like I don't really like this i' rather

just switch back to nextjs maybe it's

because just a JavaScript developer and

I'm familiar with nextjs and so my

opinions are probably going to be biased

secondly it's also because I'm using vs

code a lot of these complaints are

because I'm using vs code and not neov

but let me just list out some of the

things that bothered me about go and

Temple and and I would say these

concerns like impacted me enough where I

just felt a relief cing in nextjs again

so let's talk about some of these things

and you guys can leave comments I know

you guys are going to leave comments and

be angry because I'm not um embracing go

fully let's talk about the good about go

I'm not writing go off I think go is a

very simple language to learn I think

it's very performant like I mentioned

before but at the same time it's very

verbose um I miss my string

interpolations like I'm noticing I have

to do a lot of format you know print F

let's see where I'm doing that print

FS okay I'm doing a lot of format print

FS just to interpolate a string it's not

that big of a deal but it's enough where

I'm like dude it's just kind of annoying

that I can't just say like user

subscribed email okay this is more

concise than this and when you write

this enough throughout your application

you start missing it in nextjs okay not

a big deal it's not a deal breaker but

again it's just the little things and

the little things add up let's talk

about the error handling and go I think

the error handling and go is Light Years

better than node when you are calling a

node function you have no idea if it

could even throw an exception and you

need to make sure you are putting TR

catches at least somewhere up higher in

your application so you can handle when

whatever arbitrary function you call

throws an exception it's very like uh

obscure you don't know what the function

is going to do and go the errors are

returned and so when you call a function

usually you know just by looking at the

function definition that hey this thing

could potentially error out you probably

want to handle it now granted this can

be ignored like I don't actually have to

handle the errors right so just like

wrap this whole thing in a try catch

bubble the air up to the user tell the

user to try again that type of sloppy

coding right so there is a lot of

benefit to the error handling in go and

I'm definitely going to give it the win

there but I will say that it gets a

little verbose at times and I'm like

dude if I can't write to my

database like I just want this thing to

error out like right here I just want

this thing to panic now granted there

are some errors that you actually want

to check and make sure that like hey

if this was just like a connection reset

error or a connection timed out error

when trying to write to my database or

trying to make a fetch request to a

third party API then yeah maybe I could

just wrap it and retry logic in my Go

app and do something different based on

the error but there's something nice

about node.js and like I can just hack

stuff together and like if it just

throws an error whatever like the UI

will show an alert saying try again and

again this is from a Indie hacker

standpoint this isn't I'm working at a

Fortune 500 company I need to make sure

every single error is handled this is

more of the context of my mindset of

what I want to achieve in my spare time

after work handling all these errors is

just something I just don't care about

but again I'm going to give go the win

on that because I do think it's a better

way to handle errors I hear Russ is also

really great at that too um stuff like

this parsing an INT it's just so Bose

now granted I am new to go and there

might be better ways to do this but like

the fact that I'm passing in an email

and then I just need to convert it to a

string and then this could potentially

throw an error so now I need to say oh

if it throws an error I need to panic

granted I don't even know if fiber is

going to return the correct status code

when this thing errors so I don't think

I'm doing this right either I should

probably have like a higher order

function that's wrapping all this to

catch errors and maybe change the status

code and return that U I think the

proper way to do this would be like c.

status of I don't know 500 or something

I'm sorry it's fiber dot I don't know

bad request so that's what I should be

doing instead

but I feel like it would just be nicer

if instead maybe I could just like not

catch these errors but I think if I do

this then like this thing won't Panic

like it'll just call this and this would

probably throw an error at some point

and then like I I don't know anyway let

me move on from that because my lack of

go is a shining through and you guys are

going to call me out in the comments but

I just don't care let's go to the temple

syntax Temple there's something about

Temple that I just don't like right when

I'm making an

endpoint often I wish I could just write

a simple template right here like I just

want to inline a little alert and send

it back but what Temple you end up doing

is you have to have these Temple

files and the one thing that I hate the

most about Temple especially in VSS code

is when I command click on a template it

takes me to my compiled generated go

file which is completely pointless to

load up and so then I end up going over

here and I'm like okay well I open the

wrong file let me click on this one

and let me try to find the function I

was originally trying to look for okay

here it is and that disconnect in my

editor is enough for me to say I do not

want to use Temple okay it's small stuff

like that where it's like I would rather

just use

jsx because it's just it just works

better now again this is where I'm

saying neoven may have solved this issue

but it's just stuff like this and then

you look over here and you're like you

have a temple file and then you have a

go file and there's also some text files

in some of these that the temple file

sometimes generate I don't know why

there's no txt files now but they were a

second ago so now you have like all

these random files in your code base

that kind of just

pollute what you're trying to do it's

like I don't care about these files and

sometimes when I'm collapsing them they

just automatically open back up again

but overall I mean like if that wasn't

an issue I think Temple's pretty good I

mean like you have the type safety I can

pass whatever types to this thing and

it's going to error out if I'm passing

the wrong types so some other complaints

when I was using Temple I found that

when I navigated between Pages sometimes

the temple proxy which is something I'm

using to basically force my browser to

reload when I save a temple file or when

I save a go file I'm using Temple

generate watch with this proxy and that

is basically treating like a live reload

sometimes this whole thing would just

block up my tab like my Chrome tab would

freeze up I have to close it and then I

have to open a new one I open an issue

on the temple GitHub I believe that's

been been fixed by the maintainer of

Temple but it's just like enough of

running into these little small issues

where you're like okay there's another

tick off the Box why I don't want to use

this granted if someone else ran into

that bug and this got fixed before I

picked it up maybe I wouldn't be so

frustrated with it but if you run into

enough frustrations with trying out a

stack you're like I just don't care

about this stack anymore the great thing

about nextjs and V and all these other

things is that like typically they've

done a very very good job just making

the hot module reloading work perfectly

fine um like with nextjs I save a file

and typically I go back to my UI and

it's automatically refreshed by the time

I switch screens my page is already

refreshed with my change granted I could

just have a bad setup but again like

that's another problem with using these

type of stacks is that you end up like

packing all these things together

yourself trying to figure out your own

solution to a problem that I'm sure

every other developer who's doing the

stack has solved already like I

mentioned some good things about go I

love how it compiles down to a binary

and the binary is super small and I can

deploy that super easily anywhere that's

awesome I like that I do like the type

safety and go um sometimes when I'm

coding with go I feel like it's just

missing something like it's just it's

too rigid I don't know how to explain

this it just feels sometimes very rigid

and I'm coming from typescript where you

can throw Ines on anything but again

coming from the Indie hacker standpoint

I just want to quickly prototype

something and typescript definitely

takes the win with that because if I'm

not in the mood to type stuff or create

a type or if I just want to throw on a

union type somewhere I can do that in

typescript very easily right you might

argue well that's bad coding again I'm

coming from an indie hacker mindset of I

just want to move fast prototype

something throw it away refactor it make

it better later and that's just a

trade-off between like a strongly type

or strictly type language versus

typescript which is I don't know what

you call that it's just a monstrosity

but it works right and it get that

flexibility to like turn off typing when

you truly just want to like I have this

this idea and I need to implement it and

I don't want the type system telling me

no stop your whole thought process

because you need to actually put a type

on this parameter here it's like no I

don't care I already know it's an app

let me call a method on it you know

anyway that is a complete side tangent

so some good things is I am using fiber

and I do feel like fiber was super fast

and it feels like I'm writing expressjs

or like any other type of you know micro

backend framework where I can just do

routes and middlewares and stuff like

that so it I felt familiar in that

aspect and uh it was pretty nice I won't

complain about that now granted I didn't

really prepare for this video I'm just

kind of going off the top of my head the

things that I like the things I didn't

like and so there's no structure to this

but one thing that started to annoy me a

lot is how rigid the package system is

in go and what I mean by that is that

like it feels very rigid that the

package you're in has to match the

directory that you're in okay I tried to

do like a file based route approach here

where I'd have like a dashboard page a

login page a log out page an unsubscribe

page stuff like that and inside the

dashboard page I'm like well I just want

to go ahead and just put a couple of

like

components um inside a subfolder so I

can easily find them when I'm just like

navigating this but when you do that

you're forced to basically make these be

in a package that like matches the name

of the folder and then you have to like

remember well you have to make this

public because although this is a

dashboard only component you got to make

it public so that I can actually import

it from

another page or route that lives on my

dashboard and so I feel like the

packaging system is very strict or rigid

in the sense that like you have to

basically either put everything in the

same folder or you just basically do

what I just did and like you have to

like put make some stuff public and then

you find yourself going through here and

just like changing the capital case of

all this stuff as you're moving stuff

around it just feels like busy work

versus I don't know it just feels a lot

more flexible in typescript and node

where like I can just import that thing

like here's a function I just want to

import it from this file that lives who

knows where I don't care just give me

that file that's all I want to invoke

and then if I want it to be a private

module or a private function I literally

just don't export it so that everything

in this file can have access to that so

that's kind of something that I miss

about no but again that's just more of a

mindset shift I have to get used to how

go works with packages and stuff and

it's kind of like well you just have to

do it that way that's just how it works

overall when it comes to go my final

opinions are if you came to me and said

hey Cody we need you to build the most

performant backend you can do how would

you do it don't worry about the front

end you never have to touch front end

code again I would pick go honestly I

would still pick go I think having this

type of strict language where everything

is typed and you have like these

built-in constructs for doing channels

it just has a better concurrency model

than node.js in my opinion like in a in

another video I just did the other day I

kind of talked about node workers and

node workers are just like a nightmare

compared to like pushing to a channel

right it's just so convenient and

elegant and go of like I just need to do

some work on a queue here just push into

a channel that'll get picked up by some

other process it's just nice so like I

said if you came to me and said you are

in charge of like building out a

complete rest API or just backend

microservices you don't ever have to

worry about a front end and you're on a

larger team I would say go is probably a

really good choice but if you said hey

Cody you're a oneman team I need you to

work on three different projects and I

need you to context switch between them

possibly multiple times a day that's

when I'm like okay I'm probably going to

pick nextjs or some type of

allinclusive uh framework that uses

typescript on the front end in the

backend granted I know people hate

typescript they say that typescript

should never run in the back end but in

my op opinion there are a lot of

benefits of not having the context

switch between two ecosystems whether

you agree with it or not but when your

back in as written and go you then have

a completely different mindset you have

to think about a different package

manager a different like make files it

depends on how you're doing like your

builds and your runs and then you have

your front end that's using a completely

other set of tools and ecosystem like I

don't know es build or Turbo pack and

nextjs and esm modules for me in my

brain

not having the context switch between

two different languages and two

completely different ecosystems is a

huge win especially if you have to

maintain multiple projects at the same

time and you have to switch between them

often throughout the day uh my goals on

this channel and everything I do on my

channel is just on the side I just do

this with some extra free time after

work I'm trying to do that whole Indie

hacker thing where I build a project I

try to launch it I try to get some users

if it doesn't work I move over to

another project sometimes I'll work on

two or three different projects in a day

and I'll just ship one feature for one

product move on to the next ship another

feature having a separated front end and

backend is hard enough to get all set up

and automated with cicd and then add on

top of that your back ends in a

completely different language and

ecosystem that's not complexity that I'm

willing to uh trade off all right let's

move on to HTM X HTM X overall I mean

from the get- go I'll say no I don't

like HTM X I think the idea is pretty

cool but I think the mental model with

all these frontend Frameworks like view

spell to react the model is you have a

data model and when that data model

updates your UI reflects that data model

and I think that is a lot easier to

reason about at least for in my brain

then your backend is responsible for

sending over the components when your

front end does certain actions and the

reason I find that very painful is that

you have like

IDs that are spread out through all your

components and then when you click a

button or submit a form your your

backend has to like keep that in mind of

like your controller needs to know okay

now we need to send over a different

template and then we have to basically

Target different IDs in the front end to

swap out like an alert or show uh you

know I think somewhere over here I show

like an error and then the backend has

to basically keep those IDs in its head

again like there's no type safety with

any of this stuff so I have to like find

certain IDs and then like use ataban

swaps to throw an error alert somewhere

on the page or swap out some content

down here and I just find this very

unmaintainable granted I've only been

playing around with this for like 2

weeks and so maybe I just haven't drank

the Kool-Aid enough but coming from

react and spelt and view I just don't

think this is a long-term maintainable

solution um especially if your UI starts

getting more and more complex over time

now granted I do think there's some

really nice things in HTM X for example

like the indicators are pretty cool like

when I submit a button I can just

basically say fine my indicator that

lives in this button I have like a

component here that basically loads up

an indicator and then I have an htx

indicator here which shows a spinner and

I mean that's like one line right I just

have to add one attribute to my dom to

have the indicator automatically show

but kind of looking at this code it's

like some of the things I ran into is

like when I'm trying to get the UI back

into the same state that I need it to be

in to debug sometimes you might have a

page and it takes submitting a form and

then the backend does something and then

the form changes to a state then inside

that new state there was a tab that you

clicked so it takes like three actions

to get back to the same state as it was

and the only way to get to that state is

by doing all these actions manually

versus in View and spelt and react I

mean you have like this this data model

you go in here you flip some flags and

now you're UI is in the exact state that

you need it to be as you're doing

development and debugging that is just

much easier in my opinion um there's

other stuff over here like this HX

include I have a subject an HTML and a

text these are just arbitrary inputs on

this page that I want to include when

someone clicks this button and it does a

post request to this endpoint to me this

just doesn't seem like a good approach

right there's just arbitrary IDs on

these inputs we're just saying include

them when the form submits yeah I don't

know I'm just not a fan like I I I tried

to give HTM x a solid try I truly did um

I tried to come in here with like a cool

mindset of like oh this is awesome I can

like have buttons do stuff and call end

points and the end points return back

some arbitrary stuff it just feels more

difficult like it feels like there's

more friction to build something simple

compared to when I'm using like and so

somewhere through this journey um I was

like you know what maybe it's just go

and Temple that's really distracting me

from HTM X maybe HTM X is actually

pretty cool and so what I did was I

built an entire application using HTM X

in hono okay so here's another

application I said you know what let's

just move away from go for a little bit

and give htx another try using hono

which is in JavaScript which is what I'm

familiar with and then I end up writing

some weird stuff like this where when I

type into an input box I I want a

counter to basically decrement as the

user types into this text area and you

end up writing some weird stuff like

this granted if you're an htx expert or

an Alpine expert there might be a super

easy way to do this but just by using

HTM X alone the fact that I'm like

writing JavaScript code like

this I would much rather there be some

State called remaining characters or

some deriv State and react where I can

just get the input value do the length

on it and just like subtracted by 10,000

and then just render that out and I

actually did that over here right I have

a remaining characters over here and

they kind of show you what I mean I'm

actually rewriting this application back

in nextjs because I just I cannot

swallow HTM there's something about it I

cannot just agree with it um maybe you

love it but I just can't so again this

is easier to reason about for me and so

this is the code basically I just do

10,000 minus what the current length is

of my form value

and then I display

it it's like the little things like that

which it's very nice to have view or

react or spelt where you have like this

data model and then all you need to do

is just update that data model recompute

it and then all of a sudden your UI is

going to reflect that state

automatically versus if you want to get

that with HTM X you end up writing some

vanilla javascripts maybe doing it

inline wasn't the best approach but if

you don't do it in line what you end up

doing is you put it in some script tag

down below and then that becomes even

harder to maintain because now the

script tag has to reference this text

area using an ID and then you're like

going back and forth between like random

IDs and stuff and then keep in mind

there's no type safety right so like I

don't know what IDs are on the page that

I can even reference or are being used

and so now you just have a bunch of IDs

that are like oh look at this I have an

ID called remaining I better make sure I

never remove this ID because then this

functionality will break it's just

easier to see with typescript that

hey that thing is derived from this and

this thing depends on this but overall I

mean I think the idea of HTM X is pretty

cool like the the swapping the ability

to basically call an endo the endpoint

returns from H you can swap it out on

the page really really cool especially

for a really basic

application um but I feel like as your

apps get a little bit more complex or

you have multiple things that need to

happen on a page it's just harder to

maintain and again this is like another

thing where I started using htx I legit

ran into various bugs related to like

indicators and buttons not not

re-enabling when I switch pages and then

I opened like pull requests to the htx

library and the maintainer actually

fixed those bugs so there's two bugs

that I pointed out and I complained

about on Twitter the maintainer fixed

them but it just goes to show that's

like bro I just picked this up within

like a week and I've I'm hitting bugs in

Temple I'm hitting bugs in HTM X and I'm

curious are other people not building

uis that are sophisticated because like

if I'm hitting this day one

because if I'm hitting issues with like

loading indicators staying up or buttons

not disabling either I'm using HT Max

the completely wrong way or like people

are not actually building sophisticated

software with HTM X but again those are

just more hurdles that I run into oh

look here's another idea a random error

ID I'm assuming that somewhere on the

back end this is going to swapped out

with an error so yeah I don't know I'm

just not a fan of it but yeah I tried to

give it two solid tries again I only do

this part-time I only do this in my

spare time if I had a whole month of

playing around with htx maybe my

opinions would change a little bit maybe

I would not be so harsh on it but I just

don't have that much time to like really

investigate these tools um but at least

I am investigating it I feel like a lot

of people online were hyping up htx and

no one actually uses it like no one

actually built anything with it um I'm

actually trying to build something with

it and I'm realizing I don't want to

build with it anymore all right I don't

even know what else to talk about I mean

I talked about go I talked about Temple

and how I don't like it I talk about htx

how I don't like that so at this point

I'm okay just swallowing the fact that

I'm just going to become a nextjs

developer I'm just going to be a

JavaScript Dev you back and devs can

make fun of me for just wanting to be a

JavaScript Dev but I have been coding a

JavaScript for almost 10 years now in

typescript and at this point I am so

used to coding in typescript and having

like in toin type safety and having like

the flexibility to move fast like any

package you'd ever need like you're

going to find it and react and you can

probably implement it in like 30 minutes

to an hour like no joke for everything

in Project planner AI which is another

application that I worked on using next

Chas and comvex everything you see in

this

application literally like oh we need to

have some con Bon board we just went and

found some arbitrary

package brought it in and now we have

combon functionality like it took us

like 30 minutes to an hour to get a

basic conon board set up and then we

just spend a little bit more time adding

like drag drop functionality and

honestly I just don't think it's

possible to achieve this level of

productivity using go or HTM X like

there's probably not libraries and

packages already set up for you where

you can just bring them in import a

module throw in a random component

somewhere and then you have like drag

and drop functionality out of the box

again like I said like when you have

more sophisticated uis like we have a

bunch of cards these cards can be

searched over these cards can be

filtered over these cards can have

multiple different filters on at the

same time I can turn on and off manual

ordering of these cards when you have

state and then you have actions that

drive the view from that state it's such

an easier mental model to like Implement

nice sophisticated uis oh we can even

swap between tables and cards just by

clicking a button I'm not saying that

you can't implement this with go and HTM

X and Temple I'm just saying I have not

found a stack out there that gives me

the same level of productivity as nextjs

does and react does and this whole

ecosystem that I've been using on my

channel for a while I've tried using

laravel earlier this year uh there's a

whole like Fiasco about laravel I made

fun of it and I decided to try it out

and then I end up just missing

typescript I ended up missing my auto

completion of my editor my in type

safety I felt like the intellisense was

not good again the recommendations were

well you should stop using VSS code and

switch over to something else it's like

I don't want to have to learn a new

editor just to use your stack like

laravel is pretty cool I would say larel

has a a bunch of bakedin functionality

which can be very appealing to a lot of

people but I don't know I just like the

flexibility of like I want to install

some random orm package and not have to

use what laravel prescribes me and when

I say I tried laravel like I legit

cloned or I forked kify I made a PO

request I tried to fix some

functionality with the registration page

I made this PO request and I got merged

and I'm actually excited about that um

Andre who shout out to him for doing

coolify like this is a really cool

product he says he's not even aware of

the old function I used so it's like I

picked up larel in a day or two and I'm

using stuff that the person who's

maintaining this project doesn't even

know about and I'm not saying that to

like bash Andre I'm saying that to say

that I'm not just like saying oh I tried

larabel like I legit read through the

documentation I learned some some stuff

I applied it to the UI that I was trying

to fix um and overall I mean it's just

like it works I just it's not for me

another project I tried forking and

playing around with was Tech romany's

dble zero this is a emailer that I kind

of talked about in my project before

he's using Elixir I read through this I

tried to play around with it the Elixir

syntax is just very interesting like I

just something about it I just don't

like I guess what I'm getting at is over

the past like month or so I've been

trying to push into different directions

of like let's try a little bit of

laravel let's try a little bit of Elixir

let's try a little bit of go let's try a

little bit of HTM x uh in Temple and

stuff like that and at the end of the

day it's like I'm kind of done trying bu

new stuff like I've just come to pallet

the fact that I'm just an xjs JavaScript

developer and I'm able to ship stuff

very fast with it and I'm okay with that

and that's what I'm going to stick with

and I'm going to stop wasting your time

switching between various stacks and I'm

going to go back to what I know and what

I enjoy and what I actually love coding

with and that is typescript and

JavaScript so sorry for wasting your

time and hyping you up on go if you guys

got excited but I'm going to switch back

to my normal SCH content maybe I'll do

some Go stuff once in a while like this

isn't the first Adventure Time I've done

with go if you scroll back I was doing

like a distributed key value store with

go a long time ago and played around

with that for about 2 weeks and I

learned a little bit about kubernetes

and stuff so uh so yeah um I don't know

what I'm even saying at this point hope

you guys enjoyed watching have a good

day happy coding and uh yeah let's just

get back to nextjs and actually shipping

stuff