portfolio-2025: a Vue and Three.js developer portfolio template

What the site actually contains

The repository is a personal portfolio site with project case studies, lightweight 3D and shader demos, and bilingual copy in English and German. The stack is stated in one line: Vue 3 with the script setup syntax, TypeScript and Vite, motion through GSAP and Lenis, 3D through three.js, audio through Howler, and GLSL compiled through vite-plugin-glsl. The combination of a full WebGL stack with a portfolio information architecture is the point, since the demos are there to show the work rather than to be the work. The primary language of the repository is TypeScript, the licence field is a custom one GitHub cannot classify with the terms in license.md, and the last push was on 2026-08-11. There are no GitHub releases, so the site is deployed from the repository rather than distributed as a package.

Five scripts, and the dev server pins its port

The script list is short and the details are the useful part. The dev script runs the Vite dev server on port 3000 with strictPort set, so if something else already holds that port the server fails rather than quietly moving to 3001, which is the behaviour you want when a proxy or a screenshot script is pointed at a fixed address. The build script runs vue-tsc and then produces the production bundle into dist. The preview script serves that production build locally, the typecheck script runs vue-tsc in build mode without emitting, and there are two environment helpers, one copying the .env.example to .env if it does not exist and one removing it. The separation of the typecheck from the build is worth noticing, since it means you can check types in a pre-commit hook or in continuous integration without producing a bundle, and the manifest pins TypeScript to the 5.9 series while the rest of the tooling tracks current versions.

Content is TypeScript files, and the slugs have to line up

The content layout is where a fork of this project will cost you the most time. Projects live under a directory per language, with a file per project holding the copy, the tags, the media and the links, and the slugs must align with the project ids in a separate index file in the same directory. That constraint is the thing to know before you start, because a file added without a matching entry in the index will not appear, and there is no error message telling you so. Previews and the listing live in their own subdirectory under the same tree, and the tag variants and labels are kept in a single component file that is used by both the tag component and the content types, which is a small but good decision, because it means changing how a tag looks is one edit rather than a search through the content. The i18n helpers live under their own directory in the source tree, and the shared SCSS mixins are in the styles directory, with WebGL and GLSL code under the three directory where it applies.

One environment variable, and it controls attribution

The .env.example file contains a single line, VITE_SHOW_ATTRIBUTION set to true, and that single flag is the mechanism behind the attribution requirement in the licence. The readme asks that, if you use the project or substantial parts of its source as the base for your own portfolio or work, attribution must be preserved, and it lists three specific things to keep: the existing credit comments in the source code, the attribution section in the readme, and a visible reference to the original project or repository in derivative works. It names the original portfolio as david-hckh.com, and adds that commercial reuse or redistribution of substantial portions without permission is prohibited. So the environment variable is how the site shows that credit, and turning it off to remove it is a decision the licence explicitly does not allow.

The rendering stack, and what each piece is doing there

Looking at the dependencies tells you which problem each library is solving. GSAP is the animation engine and Lenis is the smooth scroll that GSAP then animates against, so a page that moves under the cursor is usually that pair working together. three.js is the WebGL layer, with the GLSL shaders compiled at build time by vite-plugin-glsl rather than fetched as separate files at runtime. Howler is the audio layer, and there is a sounds directory at the repository root holding the assets it plays, with the type packages for Howler and three.js in the dev dependencies. Vue is the component framework and the 3D is layered on top of it rather than replacing it, with the WebGL and GLSL code living in its own source directory and applied where the project needs it. The result is a site where the interesting rendering work is deliberately isolated, which is the arrangement that makes a project like this reusable by someone else.

What you have to replace before it is your portfolio

Everything visible in the site is placeholder until you fill it in, and the list is short enough to be a checklist. The project files under the content directory hold the copy, the tags, the media and the links for each case study, and there are two sets of them, one per language, so a bilingual site doubles the writing. The media referenced from those files has to exist. The tag variants file defines the look of each tag, so the tags you use have to be added there. The previews directory holds the listing imagery. The sounds directory holds the audio that Howler plays. The environment file has the attribution flag. And the visual work itself, the three directory of scenes and shaders, is the part you either keep or replace depending on whether you want the same aesthetic. The repository layout is otherwise conventional, with an index.html at the root, a public directory for static assets, three separate tsconfig files splitting the app, the node config and the base, and a vite config.

Editorial conclusion

portfolio-2025 suits a developer who wants a portfolio with the 3D and motion work already in it, and who is prepared to write their own case studies into a TypeScript content structure rather than a CMS. It does not suit a team that needs a portfolio they can update without touching the code, and it does not suit anyone who wants to use the project commercially without asking, because the licence prohibits that outright. Before you start, look at the content layout, since every project needs a file per language and the slug has to match an entry in the project ids file, and read the attribution rules, because they are specific about what has to survive in a derivative work.

Frequently asked questions

Official sources

1. davidhckh/portfolio-2025 on GitHub
2. Issues
3. Project website
4. README