Goodbye javascript (for now)

Summary

The speaker discusses their concerns with increasing memory usage in Next.js applications, possibly due to image optimization with Sharp. They explore the idea of 'doing more with less' in web development, comparing the memory footprint of different frameworks like Next.js, Hono, Bun, and Go with Fiber. The speaker highlights the efficiency and performance of Go, suggesting it as a potential alternative to JavaScript-based solutions for its lower memory usage and built-in features. They also touch on the potential of HTMX to reduce client-side interactivity complexity, advocating for a shift towards simpler, more efficient coding practices.

Takeaways

• 📈 The speaker has been investigating memory usage issues in Next.js applications, particularly with image optimization using Sharp.
• 🔍 They are exploring the idea of achieving more with less, in terms of code, dependencies, and complexity in the software industry.
• 💡 The speaker's work involves AWS, cloud computing, and infrastructure as code, where they've noticed that complexity can sometimes outweigh the deployment's actual needs.
• 🛠️ They have refactored some applications from Next.js to other technologies like Hono and Bun to reduce memory usage, with varying degrees of success.
• 📉 A comparison of memory usage between different implementations shows that a Go and Fiber implementation uses significantly less memory than JavaScript-based ones.
• 🚀 The speaker considers Go to be a strong alternative due to its performance, low memory footprint, and ability to compile into a single executable.
• 🤔 There's a contemplation about the necessity of client-side interactivity and whether it justifies the overhead of JavaScript frameworks and libraries.
• 🌐 HTMX is highlighted as a potential solution for achieving frontend functionality with less JavaScript, by leveraging server-side rendering and HTML.
• 🛑 The speaker expresses a desire for a shift in mindset towards simplicity and efficiency, questioning the need for complex ecosystems in common web development tasks.
• 🔧 They advocate for evaluating whether the same functionality can be achieved with fewer dependencies, less memory, and reduced third-party services.
• 🔄 Despite the exploration of new technologies, the speaker will continue to produce content on Next.js and other JavaScript frameworks, acknowledging their value in certain contexts.

Q & A

What issue with Next.js applications prompted the speaker to investigate memory usage?

The speaker noticed that their Next.js applications were consuming increasing amounts of memory over time, which led them to investigate the cause and consider ways to optimize performance.

What does the speaker suggest as a potential cause for the memory consumption issue in Next.js applications?

The speaker suggests that the image optimization process using Sharp might be contributing to the memory consumption issue in Next.js applications.

What philosophy is the speaker advocating for in the software industry?

The speaker is advocating for a philosophy of 'doing more with less,' which means achieving better performance, more features, or other benefits using less code, fewer dependencies, and reduced complexity.

What alternative to Next.js did the speaker try for their applications?

The speaker tried using Hono and Bun for their applications as an alternative to Next.js to see if it would help with the memory usage issue.

How does the memory usage of the Hono and Bun implementation compare to the Go and Fiber implementation?

The Hono and Bun implementation has a memory usage of around 150 megabytes, whereas the Go and Fiber implementation uses significantly less memory, starting at 6 megabytes and going up to 11 megabytes after deployment.

What benefits does the speaker see in using Go for their projects?

The speaker sees benefits in using Go such as lower memory usage, the ability to build a fully functioning REST API without external dependencies, and the inherent performance and concurrency features built into the language.

What is the speaker's opinion on the current state of the JavaScript ecosystem?

The speaker feels that the JavaScript ecosystem is bloated and often requires too many external tools and dependencies to achieve what could be done more efficiently with other languages like Go.

What is the speaker's view on the use of HTMX for front-end interactivity?

The speaker finds HTMX appealing because it allows for achieving front-end interactivity with less complexity and without the need for extensive JavaScript code, by leveraging server-side rendering with Go.

What is the speaker's recommendation for new developers or small teams looking to build web applications?

The speaker recommends considering the use of Go for its performance and simplicity, but also acknowledges that for quick prototyping or in certain contexts, using Next.js can still be beneficial.

What is the speaker's perspective on the continuous updates and changes in the JavaScript ecosystem?

The speaker expresses frustration with the constant updates and changes in the JavaScript ecosystem, which can lead to instability and additional work to keep up with the latest tools and practices.

Outlines

00:00

📈 Memory Usage and Optimization Concerns

The speaker discusses their increasing focus on memory usage, particularly in Next.js applications, which they've noticed consume more memory over time. They attribute this partly to image optimization with Sharp. The speaker reflects on the broader industry question of whether more can be achieved with less—less code, fewer dependencies, and reduced complexity. They share their experience with AWS, serverless architecture, and infrastructure as code, noting that sometimes the complexity of these technologies can overshadow the simplicity of the actual deployment. The speaker introduces an icon generator application built with Next.js, which generates significant revenue but also high memory usage, leading them to explore alternatives like Hono and Bun for better performance and lower memory footprint.

05:02

🛠 Exploring Go for Performance and Efficiency

The speaker continues by sharing their exploration with Go, motivated by the desire to achieve more with less. They compare memory usage between different implementations of a mailing list application, highlighting the stark difference between a Bun and Hono version versus a Go and Fiber version. The Go version demonstrates significantly lower memory usage, which leads to cost savings and better performance. The speaker emphasizes Go's ability to serve more requests per second and its advantage of having built-in features like channels for concurrent processing, without the need for additional dependencies. They also touch on the developer experience in Go, including auto-formatting and automatic importing, and the benefits of a single binary deployment in Docker, which contrasts with the JavaScript ecosystem's reliance on build tools and bundlers.

10:03

🚀 Embracing HTMX for Client-Side Interactivity with Less Complexity

In the final paragraph, the speaker discusses their growing interest in HTMX, a lightweight JavaScript library that enables rich, interactive user experiences with minimal code. They reflect on the potential of achieving high levels of client-side functionality without the bloat associated with larger JavaScript frameworks. The speaker acknowledges the hype around HTMX and considers using it alongside Go for future projects. They express a mindset shift towards simplifying development, reducing dependencies, and focusing on shipping functional code without the overhead of constantly updating and managing complex ecosystems. The speaker concludes by reassuring the audience that they will continue to produce content on Next.js and other technologies but encourages a broader mindset of efficiency and simplicity in software development.

Keywords

💡Memory Usage

Memory usage refers to the amount of RAM that a running application consumes. In the video's context, the speaker is concerned about the increasing memory usage of their Next.js applications over time, which they suspect might be due to image optimization with the Sharp library. This issue is central to the video's theme of achieving more with less, as it highlights the need for efficiency in resource consumption.

💡Next.js

Next.js is a popular React framework for building user interfaces. The speaker uses Next.js in several of their applications and discusses its memory consumption issues. Next.js is part of the broader discussion on whether the JavaScript ecosystem is bloated and if alternative technologies could offer better performance with less complexity.

💡Image Optimization

Image optimization is the process of minimizing the file size of an image to improve loading times and reduce bandwidth usage without significantly affecting the image quality. The speaker mentions that image optimization with Sharp might be contributing to memory issues in their Next.js applications, illustrating the trade-off between performance and resource usage.

💡Serverless

Serverless computing is a cloud-computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers. The speaker mentions their work with AWS and serverless architectures, which are part of the complex systems they are evaluating for efficiency and simplicity.

💡Infrastructure as Code

Infrastructure as Code (IaC) is the management of infrastructure using code and software development practices. The speaker refers to using Terraform for IaC, which is part of their broader exploration of complex cloud setups and the quest for simplification in deployment processes.

💡Hona

Hona is a minimalistic framework for building server-side applications. The speaker refactored one of their applications to use Hona to reduce memory usage, demonstrating an example of 'doing more with less' by adopting a simpler technology to achieve the same functionality.

💡Bun

Bun is a new JavaScript runtime that aims to be fast and efficient. The speaker discusses using Bun in their applications and compares its memory usage to other technologies, questioning whether the benefits of newer technologies outweigh their potential drawbacks in terms of performance and stability.

💡Go

Go, also known as Golang, is a statically typed, compiled programming language designed at Google. The speaker considers Go as an alternative to JavaScript for its performance benefits and lower memory footprint, as demonstrated by their comparison of a Go implementation versus a JavaScript one.

💡Performance

Performance in this context refers to how well an application or system executes in terms of speed and resource usage. The video's theme revolves around improving performance by reducing complexity and resource consumption, as evidenced by the speaker's exploration of different technologies and their impact on memory usage and execution speed.

💡Simplicity

Simplicity is the concept of making things as simple as possible without reducing functionality. The speaker advocates for a mindset shift towards achieving more with less, which includes using simpler code, fewer dependencies, and less complex systems to improve performance and reduce resource usage.

💡HTMX

HTMX is a JavaScript library that allows you to create dynamic and highly interactive websites using standard HTML and server-side templates. The speaker considers HTMX as a way to achieve client-side interactivity with less JavaScript, aligning with the video's theme of reducing complexity and dependencies.

Highlights

The speaker has been investigating memory usage issues in Next.js applications, particularly with image optimization using Sharp.

A shift in philosophy is proposed: achieving more with less code, fewer dependencies, and reduced complexity.

The speaker's work involves AWS, serverless architectures, and infrastructure as code, but notes the complexity can outweigh the deployment benefits.

An icon generator application built with Next.js is highlighted, noting its high memory usage despite being a simple app.

Refactored applications from Next.js to other technologies like Hono and Bun to reduce memory usage.

A comparison of memory usage between Hono, Bun, and a Go implementation shows significant differences, with Go using much less memory.

The speaker questions the need for high memory usage in single-page applications and explores alternatives to JavaScript for better performance.

Go is presented as a potential solution for achieving high performance with less memory and fewer external dependencies.

A mailing list project refactored to Go demonstrates lower memory usage compared to its JavaScript counterparts.

The simplicity of deploying a Go application as a single binary is contrasted with the complexity of JavaScript build tools.

The speaker discusses the benefits of Go's standard library, including built-in tools for formatting and importing that streamline development.

Channels in Go are highlighted as a feature that prevents blocking of API requests, unlike Node.js.

The speaker criticizes the need for additional tools like esbuild in the JavaScript ecosystem and praises Go's simplicity in deployment.

A Dockerfile example is provided to illustrate the minimal size and performance of a Go application container.

HTMX is introduced as a potential solution for achieving client-side interactivity without JavaScript, leveraging Go's server-side rendering capabilities.

The speaker reflects on a decade of web development and expresses a desire for simpler, more maintainable codebases.

A call to action for developers to consider whether they can achieve the same functionality with less code and complexity is made.

The speaker reassures that they will continue to produce content on Next.js and other JavaScript frameworks despite their current focus on Go.

Transcripts

so if you all follow me on Twitter you

might have seen me posting a lot more

charts and graphs about memory usage and

the reason I'm kind of getting into that

rabbit hole is because I noticed a lot

of my nextjs applications just start

eating up memory over time and I think a

lot of this is because of the image

optimization was sharp but it kind of

just got me thinking of like should we

be trying to achieve more in this

industry by using less and by less I

mean like less code less dependencies

less complexity now I was say a lot of

the stuff I do at work is related to AWS

and cloud computing we do like

serverless Dynamo DB Dynamo streams to

elastic search infrastructure as code

with terraform and it's like the

complexity sometimes starts to get so

much greater than the actual thing

you're trying to deploy out to

production right which kind of reminded

me of this ideology of like can we

achieve more either that's like more

performance more features more Whatever

by doing less or writing less or hending

on this so here's icon generator this is

like one of my first real applications I

deployed with nextjs that actually gets

me I think $1,000 a month from revenue

which is pretty nice but you can see

here it's having around like 400

megabytes of usage which kind of seems

like a lot of uh usage uh maybe there's

a bunch of caching going on behind the

scenes which is why it's like so high

but I was seeing kind of similar

performance with other things I was

deploying right so for example here's

another application that I used to have

in nextjs it's like one page and I was

inspecting the memory usage which I

don't think I have it anymore with the

nextjs version but we can look at

something else that's also one page my

WDC starter kit okay this used to be a

nextjs as well and at times I've saw it

go all the way up to like 300 400

megabytes of memory and it just kind of

got me thinking of like why is it that a

single static page needs so much memory

cuz it really shouldn't and so what I

did is I refactored the starter kit to

instead use hona and then also I have

another application that I kind of

worked on this used to be in nexj as

well saw the same things where like the

memory used to just kept getting higher

I refactor this use hona and Bun okay so

let's kind of look at the difference

right so this is now hovering about 1 15

what you're looking at right here is the

hona implementation I'm pretty sure and

if we go over to no glass with node

let's look at the memory usage of this

hovering around 105 granted there's not

much traffic hitting this site at all

but this is better it's not great I mean

I still think this is quite a lot of

memory usage for a single application

with very very little

traffic here's bun you can see that when

I first deploy it it's like 44 Megs and

then again that just slowly starts

climbing and climbing and climbing and

then I did a deployment that went back

down to something lower and then it

starts climbing and climbing and

climbing and granted in the grand scheme

of things like Railway only charges you

like not that much money for like memory

usage but overall when I have like this

many projects deployed out and all of

them slowly start creeping up in memory

usage either because it's like a garbage

collection issue or there's memory leaks

inside of nextjs or inside of the

services I don't know if buns production

ready or not it just got me thinking of

like why not just do something else why

not just use go use rust use C if this

is the state with JavaScript um like why

not just use something that's actually

like performant from out of the box so

some of the investigation I've been kind

of looking into is using go go is

another thing that I've used on my

channel a couple times I kind of just

played around with it but now I'm at the

point where I actually might go more uh

all in on go at this point now granted I

just released a starter kit that uses

nextjs and I still think nextjs is a

great way of like you're a solar preneur

or small team you just need to get

something out there yeah you can move

very very fast with nextjs and I would

still probably someone came to me and

said hey I need something built I would

probably use nextjs but in the grand

scheme of things I think we need to have

a a philosophy or mind set change a

little bit and try to achieve more with

less so let's look at the project that I

refactored to go and I believe it's

called um if I go to the promo site I

have two implementations of a mailing

list okay so one is in go and fiber and

one is in bun and hona so let's look at

the bun and hona one if you go over here

this is eating up 150 megabytes of

memory for a very very simple page where

literally I'm seeing this across the

board so maybe this is a railway issue

maybe Railway has overhead to your

services but let's look at the go and

fiber implementation you're going to be

blown away this is using 11 megabytes of

memory when I first deploy it it uses

six and then it goes up to 11 megabytes

of memory which is good because a how

much do I get charged for running a

service that's 11 megabytes of memory I

get charged Pennies on Railway versus

bun and hona I'm going to get charged

more now secondly the code between the

go implementation and the bun

implementation is very similar right

there's like it's almost like the same

code just written in different syntax

and so if you are trying to get more

performance by writing the same code why

wouldn't you just do that okay so that's

kind of like what I'm doing here and

yeah I mean it's it's great now you can

even get this lower people keep saying

that I should be using the standard

librar and go instead of fiber but the

point is is like you're able to achieve

this type of performance in this low

memory usage out of the box box with not

even having to thinking about caching

like I'm not caching anything like I

don't even have to think about CDN or

caching or any of optimizations like

this literally just doesn't use memory

on your machine but let's be honest I

think the go implementation could

probably serve a lot more requests per

second than anything in the node or

JavaScript ecosystem so now that I have

you hooked with this very obvious like

argument of why you should probably just

use go I mean like look at this I'll

even zoom in for you look how nice that

is 6 megabytes the other argument for go

is that you can basically achieve a

fully functioning rest

API with bringing in no external

dependencies okay you can just use the

things that are built into the go

standard library and build out a rest

API now grant that with bun and hona I

mean you don't have that many

dependencies but again you're like

depending on bun which in my opinion

it's it's too early to like really adopt

it I'm sure it has like underlying

issues and honestly I think it just

needs more time to cook I would probably

still use node on anything serious but

on side projects you just want it to be

fast yeah I mean probably use bun and

hona but again like look at this

comparison you might not care and I

think that's the point I'm trying to

drive at is you should care the same

amount of code in terms of developer

experience in fact I think go actually

has a really good developer experience

like you literally can just like save a

file it autof formats for you

automatically you don't have to install

prettier again doing more with less it's

built into the go standard Library like

format stuff for you already bringing in

these packages you don't have to like

right click on anything and say import

go will just automatically import stuff

when you save files some things that are

built into the box that you're not going

to have with nextjs is channels so if

you have used node you'll notice that if

you have a longer running thing that

really eats into CPU time it's going to

block the entire thread in node.js so if

you imagine you have like a for Loop

inside like a back and endpoint that

does like a million records that has a

loop through a million records you're

potentially going to block every single

request from hitting your node API is

that something that you actually want to

think about probably not right with go

you have channels and channels basically

spin things up and run them in their own

threads I do think it's more Nuance to

that um but everything runs in its own

thread so you don't have to worry about

like me blocking the entire thread for

every API request because you have these

constructs that are built directly into

go that allow you to just like push

things into a channel and process them

now grant that stuff like PHP laravel

has like Q's built in which I think

achiev something similar Elixir and

earling is also really great with that

type of stuff another thing I want to

show you is if you've ever deployed

nodejs to production in particular to

like

serverless most of the times they're

bringing in like es build so they can

bundle your node application like

actually bundle your API code and get

that deployed out so it's not as

large so again you're bringing in more

external things that are not baked into

JavaScript or typescript itself just so

that you can get this stuff running on

AWS which I think is a code smell I

think it's a smell with the design of

the ecosystem with typescript with

JavaScript and instead let me just show

you this this Docker file okay I have

this Docker file which runs through it

builds up this go binary and again when

go finishes running it just gives you

one single binary with all the code

that's necessary inside of that binary

okay so with this multi-stage Docker

file I build a go binary and I also have

like my public assets and then I create

a Docker image from scratch scratch if

you don't know what the scratch is is

basically an image that has nothing on

it so it's like zero bytes it's it's

super small super performant and so I

can just grab that node binary and my

public assets and put them in this empty

Docker image and then run that binary

and at the end of this like when you

actually build this we're talking like

maybe a megabyte or less of how big this

image is because it only contains those

two things which is nice because this is

literally built into go it compiles your

code into a single executable which in

no JS like I'm just tired of like having

to deal with es build I'm tired of

dealing with web pack and then at some

point it was using like snow build or

snow pack and then we started using like

Grunt and gulp it's just a NeverEnding

cycle of like BS dare I say that to

basically cover up the smells of the

ecosystem versus I think go is just

designed from the get-go of like this is

good engineering and by the way I do

want to point out that I have a nextjs

starter kit if you do still want to use

nextjs even though I've been bashing the

entire ecosystem where I'm basically

making videos to walk you through all

the code base of the starter kit the

starter kit is all free MIT um but I do

plan to make a bunch of videos to

explain this code base um again no hate

towards nextjs I have actually made some

decent money using nextjs so I'm not

going to write write it off but I just

wanted to give that little plug right

there um since you're still listening

hopefully now I think another thing that

really triggered my mindset change a

little bit was htx I I know htx seems

like a meme but the more you think about

it like the fact that if you write go

and you can achieve this much

performance increase by just switching

to go you are going to take a hit in

terms of your client side

interactivity and if you end up having

to pull in view or spell or react or

next or whatever to achieve client side

functionality it just doesn't feel right

now one of the things that makes htx so

appealing again is that all the heavy

lifting and power of go can generate

your templates and send them over from

the back end to the front end now this

isn't new I mean we've been doing this

forever in the industry but the idea is

that like can you achieve more with less

can you achieve the same or close to the

same frontend client side

functionality without having to write

any JavaScript at all and I think htx

kind of provides that now currently

that's kind of the mindset and ideology

I want to kind of follow for a little

bit right now um I just just want to

experiment like can I achieve a nice

enough user experience where I still

have all the benefits of using go I

still have all the benefits of showing

Spinners and interaction and dynamically

swapping out things on the page without

having to bring in all this bloat that's

associated with typescript and the

JavaScript ecosystem now now I'll be

completely honest this thing was hyped

up maybe like a year ago by like

primagen and a bunch of other people and

I think it's kind of cooled off since

then but I'm am honestly thinking about

using HTM X and go for a lot of my

content in the future so if you want to

stick around on my channel and still

learn about typescript the nextjs I will

still publish that type of content

because I don't want to just completely

kill off all my channel but again this

is more of like a mindset change that's

happened to me I've been coding for

almost 10 plus years and I'm just to the

point where it's like I just want to be

able to ship code and not worry about

next js's 50 caching rules or worry

about using unstable no store unstable

cash or another version update with

nextjs that's going to break something

or change the way we have to do stuff or

react 19 bringing out a new compiler I

have to think about and use it's like

what if I could just put two tags on an

HTML element and when you click it

automatically have this button show an

indicator and then when it's done my go

API sends over HTML which I can swap out

in the front end and Achieve 90% of the

same functionality that I have seen all

throughout my career most of the stuff

that I've used angularjs and angular and

react and view for it's literally here's

a form submit it process some data send

some data back like that is literally

what I've been doing for 10 plus years

and your mileage may vary like if you're

on a project that's building like eraser

IO or you're building excal drol then

yeah you're going to have to get more

into the JavaScript side of things but

for most of what I built in this

industry and what a lot of people build

as well is literally here's a form

submit it process it send something back

and again I think we need to start

thinking in the mindset of can we

achieve 90% or 95% of the interactivity

that our designers ask for or that our

business ask for by using like 50% less

code or 50% less complexity or 75% less

third- Party Services because the more

you keep tacking on to this it's just

like a gear Cog that you keep adding

gears and the moment one of those gears

breaks or becomes deprecated you end up

spending more time trying to update that

stuff or swap it out instead of actually

shipping functionality so that's my talk

um again don't be scared I'm still going

to make nextjs content I have like two

legit projects using nextjs so I'm not

going to just abandon them like like

project planner AI completely written

with nextjs so yeah I'm not going to

just abandon it but I just wanted to

kind of put that idea into your head

especially if you're like a beginner to

have that mindset can you achieve the

same functionality with using less

dependencies using less memory using

less complexity less thirdparty Services

less Cloud providers and still achieve

what you need okay have a good day happy

coding