DEV Community: Ubay Lahmudien

How You Load a JSON File Determines How Your Data Is Processed

Ubay Lahmudien — Tue, 04 Aug 2026 08:30:05 +0000

🇮🇩 Originally written in Indonesian.
This English version was AI-assisted and adapted for a more natural reading experience. It is not a literal translation.
open_

Introduction

As a Frontend Developer...

I think we've all built projects without a backend at some point.

Either because the project simply doesn't need one...

or because the backend hasn't been built yet. :)

In cases like that...

the data usually doesn't come from an API.

Instead, it's stored directly inside the project. Some people put it in data.ts or data.tsx, while others prefer separating it into a .json file.

That's actually pretty common.

Especially for portfolio websites, landing pages, company profiles, or those random side projects that somehow never get finished. As long as the data never changes... it can happily stay there until one day you suddenly feel like refactoring it.

ㄟ( ▔, ▔ )ㄏ

So...

the real question is no longer where the data is stored.

Instead...

how is that data actually processed? Statically... or dynamically?

Discussion

If the data is stored as an object or array inside data.ts, data.tsx, or a data/ folder full of TypeScript files...

I think we all know what happens.

That data simply becomes part of the application's source code.

But then...

what if the data is separated into a .json file instead?

Static Data and Dynamic Data

Before we continue...

let's make sure we're talking about the same thing.

To me, it's as simple as this.

Static data is data whose value is already determined beforehand and doesn't change while the application is running.

If the data changes one day, we have to modify the source code (or the file that stores it) and rebuild the application before those changes take effect.

Meanwhile, dynamic data is data whose value can change while the application is running, without requiring another build.

The changes can come from a server, a database, an API, or any other data source that's accessed while the application is running.

Now...

you probably already have a simple picture of the difference between the two.

What If the Data Is Stored in a JSON File?

Now...

another question usually comes up.

If the data is already stored as a .json file...

how do we actually load it?

...

At least...

there are two approaches that I see quite often.

And the funny thing is...

both of them are widely used. (￣▽￣*))

The first one...

store the JSON file somewhere like @/data/

and simply import it.

import projects from "@/data/projects.json";

That's it.

Yep.

Done.

Just like that. (￣▽￣)

You can use it like any other object or array.

The second approach...

put the JSON file inside the public folder.

Then, whenever you need it...

just fetch it.

const response = await fetch("/projects.json");
const projects = await response.json();

This approach is also pretty common.

Especially in projects that are expected to use a backend later.

Because once the data moves to an API, the way you retrieve it barely changes.

You're still making an HTTP request.

Using `import`

When you use import, the JSON file becomes part of the build process.

So by the time the application runs, the data is already there.

That's why you can access it just like any normal object.

Using `fetch()`

fetch() works a little differently.

The browser sends an HTTP request while the application is running.

And it doesn't have to be a REST API.

It can request a JSON file, an image, a video, or any other resource that's available through a URL.

Simply put...

as long as the resource is accessible over HTTP, fetch() can retrieve it.

Closing

If you think about it...

it's actually not the JSON file itself that determines whether the data is static or dynamic.

What really matters is how you use it inside your project.

The exact same file...

even with the exact same content...

can be processed differently depending on what your application needs.

And personally...

I think that's the interesting part.

Sometimes what looks like nothing more than "a place to store data" actually influences how the application treats that data.

Once your project starts dealing with sensitive information, though...

it's probably time to stop storing it in the frontend.

Because once something reaches the browser...

it's essentially public.

The rest...

well, let the backend handle it.

The frontend doesn't have to keep everything.

After all...

that's the backend's job.

(￣▽￣)

Don't forget a cup of coffee today ☕

Cara Mengambil File JSON Menentukan Bagaimana Data Diproses

Ubay Lahmudien — Tue, 04 Aug 2026 08:25:14 +0000

This article is also available in English_

Pendahuluan

Sebagai Frontend Developer...

rasanya kita semua pernah membuat project tanpa backend.

Entah karena memang tidak memakai backend...

atau mungkin backend-nya memang belum sempat dibuat. :)

Biasanya data tidak lagi diambil dari API.

Melainkan disimpan langsung di dalam project. Ada yang membuat data.ts, data.tsx, ada juga yang lebih suka memisahkannya menjadi file .json.

Hal seperti ini sudah cukup umum.

Apalagi kalau project-nya hanya sebatas portofolio, landing page, company profile, atau project gabut pengisi waktu luang yang entah kapan akan dilanjutkan lagi. Yang jelas, datanya tidak akan berubah sampai suatu hari muncul niat untuk refactor.

ㄟ( ▔, ▔ )ㄏ

Nah...

yang jadi pertanyaan bukan lagi di mana datanya disimpan.

Tapi...

bagaimana data itu diproses? Secara statis atau justru secara dinamis?

Pembahasan

Kalau datanya disimpan sebagai object atau array di dalam data.ts, data.tsx, atau folder data/ yang isinya penuh file TypeScript...

rasanya kita semua sudah tahu.

Data tersebut sudah menjadi bagian dari source code aplikasi.

Lalu...

bagaimana kalau data tersebut dipisahkan menjadi file .json?

Data Statis dan Data Dinamis

Sebelum lanjut ke sana...

kita samakan dulu pemahamannya.

Menurut saya, sesederhana ini.

Data statis adalah data yang nilainya sudah ditentukan sejak awal dan tidak berubah selama aplikasi berjalan.

Kalau suatu hari datanya berubah, kita harus mengubah source code atau file yang menyimpan data tersebut, kemudian melakukan build ulang agar perubahan itu ikut digunakan.

Sedangkan data dinamis adalah data yang nilainya dapat berubah ketika aplikasi sedang berjalan, tanpa harus melakukan proses build ulang.

Perubahannya bisa berasal dari server, database, API, atau sumber data lain yang diambil saat aplikasi sedang berjalan.

Nah...

sekarang mungkin kalian sudah punya gambaran sederhana mengenai perbedaan keduanya.

Bagaimana Jika Menyimpannya Sebagai File JSON

Nah...

sampai di sini mungkin muncul pertanyaan lain.

Kalau datanya sudah menjadi file .json...

cara mengambilnya bagaimana?

...

Setidaknya...

ada dua cara yang paling sering saya temui.

Dan lucunya, dua-duanya sama-sama sering dipakai. (￣▽￣*))

Yang pertama...

file JSON disimpan di folder @/data/ atau di mana saja

lalu cukup di-import.

import projects from "@/data/projects.json";

Selesai.

Ya.

Sudah.

Begitu saja. (￣▽￣)

Tinggal dipakai seperti object atau array pada umumnya.

Cara kedua...

file JSON diletakkan di folder public.

Lalu ketika dibutuhkan...

tinggal fetch.

const response = await fetch("/projects.json");
const projects = await response.json();

Cara seperti ini juga cukup sering saya temui.

Apalagi kalau project tersebut suatu saat akan memakai backend.

Karena ketika nanti datanya dipindahkan ke API, cara mengambilnya hampir tidak banyak berubah.

Masih sama-sama menggunakan request HTTP.

Menggunakan `import`

Saat menggunakan import, file JSON akan ikut diproses ketika aplikasi di-build.

Jadi ketika aplikasi dijalankan, datanya sebenarnya sudah siap digunakan.

Makanya kita tinggal mengaksesnya seperti object biasa.

Menggunakan `fetch()`

Kalau fetch() sedikit berbeda.

Browser akan melakukan request HTTP ketika aplikasi sedang berjalan.

Tidak harus ke REST API.

Bisa juga ke file JSON, gambar, video, atau resource lain yang memiliki URL.

Sederhananya...

selama resource tersebut bisa diakses melalui HTTP, fetch() bisa mengambilnya.

Penutup

Kalau dipikir-pikir...

ternyata bukan file JSON yang menentukan apakah data tersebut bersifat statis atau dinamis.

Yang menentukan justru bagaimana kita menggunakannya di dalam project.

File yang sama...

bahkan isi yang sama...

bisa saja diproses dengan cara yang berbeda sesuai kebutuhan aplikasi.

Dan menurut saya, di situlah menariknya.

Kadang yang kita anggap hanya "tempat menyimpan data", ternyata juga ikut memengaruhi bagaimana aplikasi memperlakukan data tersebut.

Kalau memang project-nya mulai memiliki data yang bersifat sensitif, sebaiknya jangan lagi menyimpannya di frontend.

Karena apa pun yang sudah dikirim ke browser, pada dasarnya sudah menjadi konsumsi publik.

Sisanya...

ya biarkan backend yang bekerja.

Frontend tidak perlu ikut menyimpan semua hal.

Toh itu memang urusan backend

(￣▽￣)

oke... terimakasih

Don't forget a cup of coffee today ☕

Why Many Frontend Developers Use Next.js for work, but Vue.js for Personal Projects

Ubay Lahmudien — Sat, 18 Jul 2026 09:59:03 +0000

🇮🇩 Originally written in Indonesian.
This English version was AI-assisted and adapted for a more natural reading experience. It is not a literal translation.
_open

Introduction

Lately, I've been having quite a few discussions with frontend developers about the frameworks they use.

My question is actually pretty simple.

"When you're building a web frontend, what framework do you usually use?"

Almost everyone gave more or less the same answer.

"It depends on the project."

And honestly, I agree.

There's no framework that's always the best choice for every situation.

However, as the conversation went on, they started sharing their own experiences and preferences.

Well...

That's when I started noticing an interesting pattern.

Among the developers I talked to, quite a few of them mentioned that they usually use Next.js / React for work, while Vue.js is what they often choose for personal projects.

The interesting part is...

I never actually asked,

"What do you use at work?"

"What do you use for personal projects?"

That explanation came up naturally as they explained why they preferred certain frameworks.

At first, I thought it was just a coincidence.

But after hearing the same pattern from several different people...

I got curious.

Why do so many developers who are comfortable with both frameworks end up separating how they use them?

(・_・;)

Disclaimer

This isn't based on an official survey or research.

It's simply an interesting pattern I noticed after talking with several frontend developers.

Discussion

Vue.js

Looking at today's frontend ecosystem, Vue.js is clearly not a small framework.

Its community is large.

Its documentation is great.

Its ecosystem is also quite mature.

That said, compared to React and Next.js, its community is still smaller.

Then another question comes to mind.

If that's the case...

Why do so many developers still choose Vue.js for personal projects?

From the answers I heard, the main reason wasn't performance.

And it wasn't because other frameworks were bad either.

Instead, it came down to the development experience.

Vue projects often feel easier to read.

Single File Components (.vue) keep the template, logic, and styles organized in one place.

When coming back to an old project after a long time, many developers feel it's easier to understand the code again.

Besides that, for solo projects, Vue feels lightweight.

You don't have to think about a lot of concepts that you don't actually need yet.

You can simply focus on building the application.

(づ￣ 3￣)づ

Well...

This made me wonder again.

If Vue feels more comfortable to work with...

Why not use it for work as well?

Next.js

Speaking of Next.js...

Well...

It's hard to deny.

Its ecosystem is huge.

Almost everything already has a library or solution available.

If you run into a problem...

There's a good chance someone else has already faced it.

Tutorials are everywhere.

Articles are everywhere.

Videos are everywhere.

And GitHub repositories are abundant.

(´･ω･`)

On top of that, React and Next.js have become some of the most common technologies in the industry.

As a result, many frontend developers are already familiar with them.

For companies, that's obviously an advantage.

If the team grows, finding new developers becomes much easier.

If someone leaves the team, the handover process is usually much smoother.

Not to mention that many new libraries tend to appear in the React ecosystem first.

So...

It's not simply because Next.js is a better framework.

It's because its ecosystem and industry adoption are already incredibly mature.

Closing

Well...

Maybe by this point, you already know where this discussion is heading.

Or maybe you've already come up with your own answer.

(￣▽￣)

Looking back at everything we've discussed...

I don't think this is really about which framework is better.

It all comes down to the needs of the project.

And of course...

Every framework has its own strengths and weaknesses.

It's simply a matter of understanding what your application actually needs.

If you're already comfortable using one framework for everything...

Then just keep using it.

After all, what matters most is that your application is maintainable and enjoyable to build.

If you're comfortable with multiple frameworks...

Then choose whichever one fits the situation best.

Or...

Maybe trying a different framework in your personal projects is simply part of an enjoyable learning journey.

Because, in my opinion...

Personal projects are the best place to experiment.

There's no rule saying you have to use a particular framework.

As long as it fits your needs and you enjoy the process...

I think it's all perfectly fine.

(づ￣ 3￣)づ

So...

What do you think?

Do you also separate frameworks depending on the situation?

Or do you prefer sticking with one framework for everything?

I'd love to hear your thoughts and experiences.

Who knows...

Maybe there's another perspective I haven't come across yet.

( •̀ᴗ•́ )و

Kenapa Banyak Frontend Developer Memakai Next.js untuk Pekerjaan, tapi Vue.js untuk Personal Project?

Ubay Lahmudien — Sat, 18 Jul 2026 09:25:24 +0000

This article is also available in English_

Pendahuluan

Beberapa waktu terakhir saya sering berdiskusi dengan beberapa frontend developer mengenai framework yang mereka gunakan.

Pertanyaan saya sebenarnya sederhana.

"Kalau membuat frontend web, biasanya pakai framework apa?"

Hampir semuanya memberikan jawaban yang kurang lebih sama.

"Tergantung kebutuhan."

Dan saya setuju.

Tidak ada framework yang selalu menjadi pilihan terbaik untuk semua kondisi.

Namun, setelah pembahasannya berlanjut, mereka mulai menceritakan pengalaman dan preferensinya masing-masing.

Nah...

Di sinilah saya mulai menemukan pola yang menarik.

Dari beberapa developer yang saya ajak berdiskusi, cukup banyak yang mengatakan bahwa mereka lebih sering menggunakan Next.js / React untuk pekerjaan, sedangkan Vue.js lebih sering digunakan untuk personal project.

Padahal saya tidak pernah bertanya,

"Kalau kerja pakai apa?"

atau

"Kalau project pribadi pakai apa?"

Penjelasan itu muncul begitu saja ketika mereka mulai menjelaskan alasan di balik framework yang mereka pilih.

Awalnya saya mengira itu hanya kebetulan.

Tapi setelah mendengar pola yang sama dari beberapa orang...

Saya jadi penasaran.

Kenapa banyak developer yang sudah menguasai keduanya justru memilih memisahkan penggunaannya?

(・_・;)

Disclaimer

Tulisan ini bukan hasil survei atau penelitian resmi. Ini hanyalah pola yang saya temui dari beberapa frontend developer yang sempat saya ajak berdiskusi.

Pembahasan

Vue.js

Kalau melihat ekosistem frontend saat ini, Vue.js jelas bukan framework yang kecil.

Komunitasnya besar.

Dokumentasinya bagus.

Ekosistemnya juga sudah cukup matang.

Namun memang harus diakui, jika dibandingkan dengan React dan Next.js, komunitasnya memang masih lebih kecil.

Lalu muncul pertanyaan.

Kalau begitu...

Kenapa masih banyak yang memilih Vue.js untuk personal project?

Dari beberapa jawaban yang saya dengar, ternyata alasan utamanya bukan karena performa.

Bukan juga karena framework lain kurang bagus.

Melainkan karena pengalaman saat mengembangkan project.

Struktur project di Vue terasa lebih mudah dibaca.

Single File Component (.vue) membuat template, logic, dan style berada di tempat yang jelas.

Ketika project sudah lama tidak dibuka, banyak developer merasa lebih cepat memahami kembali alur kodenya.

Selain itu, untuk project yang dikerjakan sendirian, Vue juga terasa ringan.

Tidak perlu terlalu banyak memikirkan berbagai konsep yang sebenarnya belum dibutuhkan.

Tinggal fokus membuat aplikasinya.

(づ￣ 3￣)づ

Nah...

Di sinilah saya kembali bertanya.

Kalau memang Vue terasa lebih nyaman...

Kenapa tidak sekalian dipakai untuk pekerjaan?

Next.js

Kalau berbicara soal Next.js...

Ya...

Memang susah untuk dipungkiri.

Ekosistemnya sangat besar.

Hampir semua kebutuhan sudah ada library-nya.

Kalau menemui masalah...

Kemungkinan besar sudah ada orang lain yang pernah mengalaminya.

Tutorial ada.

Artikel ada.

Video ada.

Referensi GitHub juga melimpah.

(´･ω･`)

Selain itu, React dan Next.js juga menjadi teknologi yang sangat umum di industri.

Akibatnya, cukup banyak frontend developer yang sudah menguasainya.

Bagi perusahaan, kondisi seperti ini tentu menguntungkan.

Kalau suatu saat tim bertambah, proses mencari developer baru menjadi lebih mudah.

Kalau ada pergantian anggota tim, proses handover juga biasanya lebih sederhana.

Belum lagi banyak library baru yang biasanya hadir lebih dulu di ekosistem React.

Jadi...

Bukan semata-mata karena framework ini lebih hebat.

Tetapi karena ekosistem dan dukungan industrinya memang sudah sangat matang.

Penutup

Nah...

Mungkin sampai di sini sebagian dari kalian sudah tahu ke mana arah pembahasannya.

Atau bahkan sudah memiliki jawaban kalian sendiri.

(￣▽￣)

Kalau melihat kembali pembahasan tadi...

Saya rasa tidak ada framework yang benar-benar lebih unggul dari yang lain.

Semuanya kembali lagi ke kebutuhan.

Dan tentu saja...

Setiap framework memiliki kelebihan dan kekurangannya masing-masing.

Tinggal bagaimana kita menganalisis kebutuhan dari aplikasi yang akan dibuat.

Kalau memang sudah nyaman menggunakan satu framework untuk semua kebutuhan...

Ya pakai saja.

Toh yang paling penting aplikasinya tetap bisa dikembangkan dan di-maintain dengan baik.

Kalau memang menguasai lebih dari satu framework...

Ya tinggal pilih mana yang paling cocok untuk kebutuhan saat itu.

Atau...

Mungkin justru mencoba framework lain saat mengerjakan personal project bisa menjadi bagian dari enjoyable learning.

Karena menurut saya...

Personal project adalah tempat yang paling bebas untuk bereksperimen.

Tidak ada aturan yang mengharuskan kita menggunakan framework tertentu.

Selama sesuai kebutuhan dan kita menikmati prosesnya...

Menurut saya, semuanya sah-sah saja.

(づ￣ 3￣)づ

Lalu...

Bagaimana menurut kalian?

Apakah kalian juga memisahkan framework berdasarkan kebutuhan seperti ini?

Atau justru menggunakan satu framework untuk semua project?

Saya penasaran dengan pengalaman dan sudut pandang kalian.

Siapa tahu, ada alasan lain yang belum pernah saya dengar.

( •̀ᴗ•́ )و

Mencoba Merancang Ulang Web Portofolio

Ubay Lahmudien — Wed, 24 Jun 2026 04:59:58 +0000

Ubay Lahmudien – Kediri, 7 Februari 2026

Tujuan & Latar Belakang

Anda sudah tahu bahwa CV dan portofolio itu selalu berjalan beriringan. Seiring waktu, portofolio kita juga akan terus bertambah.

Sebagai seorang programmer, biasanya di awal belajar kita sering disuguhi tutorial membuat web sederhana. Lalu di akhir course, hampir selalu diminta membuat web portofolio yang berisi CV singkat dan kumpulan project.

Awalnya, saya sempat bertanya,

"Masih perlu nggak sih bikin web portofolio sendiri?"

Soalnya, kalau dilihat, LinkedIn itu sudah cukup lengkap. Data CV ada, portofolio bisa ditampilkan, bahkan bisa langsung dipakai untuk melamar kerja. Rasanya sudah cukup.

Tapi setelah berdiskusi dengan teman dan juga tanya jawab dengan ChatGPT, saya sadar kalau web portofolio itu bukan cuma soal dokumen lamaran. Web portofolio bisa jadi identitas kita. Ketika kita membuatnya sendiri, kesan jati diri kita lebih terasa.

Akhirnya saya sahut,

"Oke kalau begitu."

Sebenarnya, saya sudah pernah membuat web portofolio sejak awal terjun ke dunia coding, waktu masih ikut bootcamp. Tapi kalau dilihat sekarang, desainnya terasa kurang nyaman atau jelek menurut saya. Sulit dibaca, bikin capek mata, dan tampilannya terlalu kaku karena waktu itu saya tidak terlalu memperhatikan tema.

Dulu, fokus saya cuma satu: kelihatan keren.

Saya pakai banyak animasi, shadow yang berlebihan, warna-warna menyala, sampai efek glass yang terlalu ramai. Secara visual mungkin menarik, tapi pesan utamanya malah jadi tidak tersampaikan dengan baik.

Sekarang, dengan bertambahnya pengalaman dan ilmu yang saya dapat, satu kata untuk itu.

`Rombak!!!`

Kenapa?

Supaya lebih mudah dibaca, lebih nyaman dilihat, dan tujuan utamanya benar-benar sampai ke pembaca. Bukan sekadar pamer efek, tapi menunjukkan siapa saya dan apa yang bisa saya buat.

"Kenapa dirombak (⚆_⚆)? Diperbaiki saja kan bisa?"

Kalau Anda seorang programmer, pasti tahu rasanya melihat kode yang pernah dibuat di awal-awal belajar IT.

ಠ_ಠ

Begitulah rasanya.

Terlalu sakit.

Terlalu pedih.

Untuk dibaca.

Apalagi diperbaiki.

Perancangan

Apa yang dibuat?

Tentu Web Porto.

Web yang bagaimana?

Sederhana dan simpel.
Jelas.
Tidak rumit.

Kebutuhan pada web

SEO Friendly.
Mudah dibaca.

Konsep

Sebelumnya, hanya sekadar info.

Saya lebih suka dengan backend dibanding frontend.

Dalam sebuah pengembangan produk, desain produk adalah bentuk muka dari sebuah produknya nanti. Dari situlah kesan pertama akan muncul, apakah terlihat rapi atau tidak.

Namun tidak dengan saya.

Saya sangat frustrasi ketika harus membuat desain di Figma. Menurut saya, itu lebih susah ketimbang ngoding.

Jadinya saya hanya melihat referensi-referensi web milik orang-orang di Dribbble, Pinterest, dan lain-lain. Dari yang saya lihat, saya gabungkan konsepnya, saya olah, dan akhirnya terpikirkanlah sebuah keyword.

Minimalist
Flat
PowerPoint

Ya, memang itu.

Minimalist = tidak terlalu ramai.

Flat = kesan profesional.

PowerPoint = tidak bertele-tele dan langsung ke inti.

Warna

Setelah mendapatkan konsep itu, saya mencari warna yang cocok dengan cara yang sama.

Di Pinterest punya banyak sekali postingan tentang palette warna.

Saya kombinasikan warna-warna yang didapat, lalu saya masukkan ke Coolors untuk melihat apakah perpaduannya cocok atau tidak.

Kalau cocok, tinggal convert ke format yang saya butuhkan. Mau CSS, Tailwind CSS, dan lain-lain, sudah tersedia.

Teknologi

Melihat saya butuh SEO Friendly, yang pertama terpikir adalah Server Side Rendering (SSR).

Tapi kalau harus membuat project vanilla (HTML, CSS, dan JavaScript)...

Ya... cukup malas.

Terlalu banyak repetitive code, sulit membuat berbasis component yang bisa dipakai berulang kali di halaman berbeda.

Akhirnya pilihan jatuh ke framework React, yaitu Next.js.

Kenapa?

Karena bisa SSR dan juga CSR.

Untuk framework CSS-nya, saya pakai Tailwind CSS.

"Kenapa bukan Bootstrap yang jauh lebih simpel?"

Karena saya tidak terbiasa dengan Bootstrap.

Atau lebih tepatnya...

Saya tidak bisa memakainya. (‾◡◝)

Dari awal memang saya sudah memakai Tailwind CSS. Jadi ketika mencoba Bootstrap, saya cukup pusing untuk mempelajarinya.

Kenapa begitu?

Maaf, saya tidak bisa membandingkan Tailwind CSS dan Bootstrap karena saya memang hampir tidak pernah menggunakan Bootstrap.

Penutup

Mungkin untuk saat ini begitu yang ingin saya bahas.

Nanti akan saya ceritakan lagi saat proses pembuatannya dimulai. Mungkin akan ada perubahan konsep seiring saya mengerjakan proyek.

Atau...

Mungkin juga bisa mangkrak karena tugas-tugas kampus.

aah...~~~~

Semoga saja saya sempat membuatnya.

Thanks.

Terima kasih.

Tambahan

Jangan lupa secangkir kopi hari ini! ☕

DEV Community: Ubay Lahmudien

How You Load a JSON File Determines How Your Data Is Processed

Introduction

Discussion

Static Data and Dynamic Data

What If the Data Is Stored in a JSON File?

The first one...

The second approach...

Using import

Using fetch()

Closing

Cara Mengambil File JSON Menentukan Bagaimana Data Diproses

Pendahuluan

Pembahasan

Data Statis dan Data Dinamis

Bagaimana Jika Menyimpannya Sebagai File JSON

Yang pertama...

Cara kedua...

Menggunakan import

Menggunakan fetch()

Penutup

Why Many Frontend Developers Use Next.js for work, but Vue.js for Personal Projects

Introduction

Discussion

Vue.js

Next.js

Closing

Kenapa Banyak Frontend Developer Memakai Next.js untuk Pekerjaan, tapi Vue.js untuk Personal Project?

Pendahuluan

Pembahasan

Vue.js

Next.js

Penutup

Mencoba Merancang Ulang Web Portofolio

Tujuan & Latar Belakang

Rombak!!!

Perancangan

Apa yang dibuat?

Web yang bagaimana?

Kebutuhan pada web

Konsep

Warna

Teknologi

Penutup

Tambahan

Using `import`

Using `fetch()`

Menggunakan `import`

Menggunakan `fetch()`

`Rombak!!!`