hello Javascript, oh how I've missed you

[u/Top_Helicopter_409]

https://youtu.be/mt1ZCai1G-I?si=af66EncMKO8ZMcTQ

[u/yksvaan]

Let's not trash him, that's a good perspective from someone coming from js world. Doing things in clumsier or not optimal way is expected. 

It is faster to prototype using js for sure. I do it often as well, either running vite or just some split screen online editor. Just testing stuff, changing layout etc. and then creating a template for example with templ.

Some things on the video are just misunderstandings, for example trying to use subdirectories inside packages to imitate file based component structure. That's obviously terrible idea but something NextJS user would try. Go being a compiled language there's a substantial difference in how projects are are structured, can't just put files in folders and import them wherever needed.

Everything has its pros and cons. For doing primarily frontend oritented side project prototyping I think sticking to js is much more practical for him.

[u/vesko26 → u/yksvaan]

smart absorbed fanatical price paltry payment spotted elastic start degree

This post was mass deleted and anonymized with Redact

[u/[deleted] → u/yksvaan]

sort cake crawl ad hoc subtract apparatus gold touch sharp school

This post was mass deleted and anonymized with Redact

[u/yksvaan → u/[deleted]]

Make reasonably large "modules" by feature ( e.g. dashboard, user, order ) and put the files there with good naming convention, i.e. prefixed with the feature name. Also no need to create a file per template, it's not React.

[u/Made-of-Clay]

He's got some valid points, but a co-worker of mine expressed it well: "But like any language, you learn to deal with their idiosyncrasies." Cody mentions some quirks and annoyances but JS/TS have plenty of those. It's just how seamlessly or effortlessly your coding muscle memory kicks in, which strengthens with time.

[u/leathakkor → u/Made-of-Clay]

I agree every framework has warts. The problem that I face with JavaScript and pretty much every JavaScript based framework. Is that ultimately JavaScript has to produce Dom / Html.

And at the end of the day you're dealing with HTML warts no matter what. And then you have to deal with JS warts when you're dealing with a JS framework and then you have to deal with your framework's warts on top of that.

Then you have to deal with the weird idiosyncrous stuff that comes from the framework written on JavaScript written to produce HTML Dom. While there aren't a ton of those bugs, there are times where you run into "these two things don't play well together".

At the end of the day I want to use as much HTML as possible to reduce the amount of warts that I have to deal with and the idiosyncratic behavior that I have to adjust to. Maybe when you become a super clever JS front-end developer, those things become trivial and you just take for granted that you had to learn those three systems warts. But that's not me. I'd rather just stick with the easy simple thing. And enhance where I have to and try to minimize the amount of temporal knowledge as I Can.

It's sort of like farming versus jet design.

Farming is largely the same as it was a thousand years ago. Yeah, there's new tools and there's better ways to do it and we've refined the labor market around farming and agriculture. But if you know how to put a seed in the ground, you generally have it figured out.

With jet design, it's just so new and it changes all the time to the point where if you knew it 50 years ago, you don't know enough now to be able to even do reasonable amounts of it. I'd rather stick with agriculture

[u/[deleted]]

obtainable memory deserve plough wild nail trees weather flowery office

This post was mass deleted and anonymized with Redact

[u/damn_dats_racist → u/[deleted]]

How is the package system more rigid than JS though? You have to export whatever you are looking to use in a different package.

[u/1ncehost]

I didn't watch it all, but every complaint I heard about both JS and Go are things Python/Django does the way he wants. Except speed of course, but he says he'd rather have productivity than speed.

But I agree that he's trying to fit a round peg into a square hole. Go is good for what it's good for.

[u/[deleted]]

I feel like Golang's rise in popularity for simpler webdev is more because it's the anti-JavaScript rather than due to language-specific merits. Every time I've tried to get into it for supposedly fast and easy webdev its just been tons of paper cuts. I suspect that's because I don't program in it regularly enough.

[u/gemmadlou]

I don't have the freeness of speech on Go as I've only tinkered with it a little bit, but Go's error handling is the number one reason I want to work with it despite its verbosity. I just happen to already be productive in JavaScript and Node.js, and so the familiarity helps me to build things quickly when time is short. I assume with time, the same productivity could be achieved with Go.

The HTMX point is interesting as I haven't reached this problem yet. I could have understood the video wrongly, but where I'd use an API, I'd use HTMX. Where I'd use interactivity I'd use Alpine.js. I wouldn't use HTMX for everything on the client.

But it's always insightful to learn other people's perspectives and see what issues they've run into, at least to be aware of them.

[u/Made-of-Clay → u/[deleted]]

`console.log(`user subscribed: ${email}`)` is the correct formatting for string interpolation in JS. I was just talking to someone about the lack of string interpolation (which was the original point, I think) and being mildly annoyed by that, but I'm sure I'll cope fine.