Goodbye javascript (for now)
Summary
TLDRThe 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
π 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.
π 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.
π 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.
Mindmap
Keywords
π‘Memory Usage
π‘Next.js
π‘Image Optimization
π‘Serverless
π‘Infrastructure as Code
π‘Hona
π‘Bun
π‘Go
π‘Performance
π‘Simplicity
π‘HTMX
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
Browse More Related Video
Basics of Time Complexity and Space Complexity | Java | Complete Placement Course | Lecture 9
What You Need to Know Before Learning NextJS
NextJs in 7 Minutes π₯
hello Javascript, oh how I've missed you
Pure React vs Next.js | Whatβs Happening in React?
How Much Memory for 1,000,000 Threads in 7 Languages | Go, Rust, C#, Elixir, Java, Node, Python
5.0 / 5 (0 votes)