Implementation

Your implementation should follow your submitted specification and implement the functionality specified for your chosen category. Also read the general implementation requirements below.

You are allowed to make modifications to your specification while implementing your project, but these these should be documented in a separate document which should be included when you submit your implementation.

For example, you may have originally specified a feature which turned out to be really hard to implement within the given time frame. If this feature is required by the category, you can simply remove it from your specification.

If something is required by the category, you modify your specification so it is easier to implement but still provides the required functionality.

Optional implementation points

It is possible to earn optional implementation points in three separate ways which can be combined as you see fit for a maximum of 6 bonus points. Note that these points can not be used to replace the 2 mandatory points you earn from the GUI and Specification deliverables.

Web components

• 1 point: Use 1 web component that you built (does not have to be interactive).
• 2 points: Use 2 or more web components that you built, at least one must be interactive.

You must have built the web components yourselves, and the ones you built in Assignment 4 (or 5) don’t count.

The Web Component(s) must be used in at least 2 places with different content, i.e. if it is a component for showing images, it must be able to show different images and be used in at least two different places in your implementation.

Note: Bad use of web components might deduct bonus points. E.g. multiple web components that do the same thing (using one component inside another is okay though), or large and complex web components that represent major features and are only used once (e.g., a web component representing a whole page does not count, a webcomponent representing different elements in a page does, e.g. a web component representing items in a shopping cart).

Code style

• 1 point: Your code is well-structured, readable, and follows a consistent style.
• 2 points: The requirements for 1 point are met, and also follows a specific code standard like StandardJS or Google TS/JS style guide. You must indicate which standard you are following and provide a reference to an easily accessible linter and, if applicable, configuration for using it. There are also CSS style guides available, such as CSS Guidelines or Google HTML/CSS style guide.

Warning:: Some legacy JS code standards that were popular in the past, like the Airbnb JS style guide, are built on top of a largely deprecated way of building JavaScript projects (Babel), requiring so called shims and polyfills to work correctly. Avoid using such standards or their related tools for this project (or any project started after 2020).

Note that some code standards (e.g. Google) also enforce rules about documentation or vary depending on whether the source file is a JavaScript or TypeScript file. Make sure to be consistent if you want to collect optional points for both code style and documentation.

Documentation

• 1 point: Your project includes clear and concise in-code documentation explaining the structure and functionality of your code in the form of block comments. See examples on JSDoc, TSDoc or TypeDoc.
• 2 points: The requirements for 1 point are met, and the documentation is comprehensive and consistent with one of the tools mentioned above so that it can generate correct and useful documentation from it. You must indicate which tool you are using and provide instructions for generating the documentation as well as a zipped version of the generated documentation.

Note that some code standards (e.g. Google) also enforce rules about documentation or vary depending on whether the source file is a JavaScript or TypeScript file. Make sure to be consistent if you want to collect optional points for both code style and documentation.

Recommendations

There are several tools like linters (static code analyzers) and formatters with extensions to integrate with most popular code editors that can help you maintain consistent code style and catch potential issues early. Exploring this space is part of the craft of writing high-quality code and is encouraged for this project. You are no longer beginners or novices who need to prove your ability to write code with little to no tool support, so make use of these tools to improve the quality and maintainability of your project. (Note that this does not entail the use of LLM-based “AI” tools for code generation, which we strongly advise that you avioid for this project.)

Submission

Submit your implementation the same way you submitted the assignments, i.e. by zipping your project directory and submitting it in Sendlab. Remember to add a README file in the top directory of your project describing how many optional points you are aiming for (if any) and which optional criteria you are aiming to fulfill. Also include an updated specification if you made any modifications to your original specification, documenting any changes you made with a “change list” at the end.

It is quite likely that your project will be larger than Sendlab allows. In this case, upload your project in Lisam instead and submit only your README file via Sendlab (including a note about the Lisam upload).

Implementation requirements

The implementation MUST be published in the same way as the assignments, i.e. available via the php-web.edu.liu.se web server. If you just use vanilla JavaScript this is not an issue.

Category specific implementation requirements: See the category page for category specific implementation requirements such as minimum number of items/properties to customise etc.

Single page implementation

Your implementation should be contained by a single html file, i.e. do not split your GUI accross multiple .html pages. Note: Using a framework that uses multiple html files in its template system is ok.

You are allowed to use multiple CSS and JavaScript files though.

Images and artwork

For this project you will not have access to a graphical design team, so you may use relevant or neutral placeholder artwork that communicates a message that does not conflict with the final product to be. E.g. do not use images of flowers instead of clothes, or animated gif background if the final product will not have them etc.

Frameworks

Note that this restriction is new for 2026 based on experiences with the use of frameworks during previous course iterations.

We do not allow the use of frameworks for the project implementation in this course. You are allowed to use component libraries as long as they do not require a build toolchain or local server, but your code should remain vanilla JavaScript and standard CSS.

The reasons for this are twofold:

First, the TAs do not have the time to either support or fairly evaluate projects that rely on all of the many, many frameworks available. The landscape of web frameworks is constantly evolving and they often differ enough from vanilla JS to be considered almost separate languages.

Second, one main focus of this course is to understand the underlying principles and mechanics of front-end web development. Adding the specific abstractions provided by frameworks would lead to a more superficial understanding of these principles and mechanics and a weaker grasp of the fundamentals. Essentially, if you learn the general fundamentals, all frameworks will be much easier to pick up later.

Languages other than JavaScript and CSS

You may use TypeScript or vanilla JavaScript, as long as the final output is vanilla JavaScript that can run in the browser without any additional build steps, server requirements, or reliance on frameworks. If you use TypeScript annotations rather than JSDoc annotations, they must be stripped out during the transpilation process so that the resulting JavaScript is valid and executable in the browser.

Similarly, you may use CSS preprocessors like Sass or Less, but the final output must be standard and well-structured CSS that can be used in the browser without any additional build steps or server requirements.

If you use these languages, your final submission must include both TypeScript source files and the transpiled JavaScript. Similarly, both CSS files that are ready to be used in the browser and any source files used to generate them must be included. This ensures that the project can be evaluated correctly and that the TAs can reproduce your results if needed.

Also, note that the use of these languages is not officially supported and TAs may not be able to prioritize assistance or guidance for issues arising from their use.

Generative AI

We do not recommend using generative AI tools as a primary means of creating content for your project. See the course guidelines on AI usage for more information.

If you do use generative AI tools despite our recommendation, any use must be supplementary and not replace your own understanding and effort in completing the project. You are especially expected to understand and be able to explain any code generated this way to the same degree as if you had written it yourself.

You are also required to clearly indicate which parts of your work was generated by AI. This includes code, text, images, and any other content. You are responsible for verifying the accuracy and appropriateness of any AI-generated content used in your project. You must also document and hand in any and all prompts, including full chat histories of your interactions with the AI tools.

Failure to comply with these guidelines regarding the use of generative AI tools can be considered academic misconduct and may result in penalties according to LiU’s academic integrity policies including suspension from studies or other disciplinary actions.