How otniel113/pertamaxcalculator works
1. Project type
- This is a single-page, client-side web application for budgeting against a Pertamax price increase.
- The repo is very small and appears to be entirely static: index.html, style.css, and script.js, with no backend, database, or build pipeline.
2. User-facing purpose
- The app helps a user compare their fuel budget before and after the Pertamax (RON 92) price change in June 2026.
- It supports three main calculations: remaining days for the same money, required money for the same number of days/liters, and a new monthly budget estimate.
3. Presentation layer
- index.html is the app shell and likely contains the form inputs, labels, result containers, and the overall page structure.
- style.css handles all visual presentation: layout, spacing, typography, and the simple calculator-style UI.
4. Interaction and computation layer
- script.js is the main application logic.
- It likely reads user inputs such as current fuel price, budget amount, and consumption assumptions, then computes the updated values after the price change.
5. Core data flow
- The user enters a baseline budget and fuel price assumptions in the UI.
- JavaScript converts those inputs into derived values for:
- how many days the current budget lasts,
- how much budget is needed to keep the same usage period,
- and the revised monthly budgeting figure.
- Results are then written back into the page without a server round trip.
6. Calculation boundary
- The important architectural boundary is between raw user inputs and derived budgeting outputs.
- The app seems to treat Pertamax price as a configurable parameter, which means the core calculation logic should be reusable for different regional prices.
7. Runtime model
- Everything runs in the browser using standard web technologies.
- There is no indication of external APIs, authentication, persistence, or asynchronous data fetching, so the app should be viewed as an offline-capable static calculator.
8. Deployment model
- The README shows it is deployed as a static site at a public URL.
- That implies the architecture is likely just file hosting, with index.html as the entry point and the CSS/JS loaded directly by the browser.
9. Functional subsystems
- Input capture: gathering prices, budgets, and consumption duration.
- Calculation engine: converting those values into the three comparison modes described in the README.
- Output rendering: displaying the new days, money required, and monthly budget results.
10. Likely diagram shape
- A useful architecture diagram would show:
- User interacting with the browser UI,
- HTML/CSS as the presentation shell,
- JavaScript as the logic layer,
- and computed budget results flowing back to the UI.
- No server-side boxes are needed unless you want to show static hosting as the delivery mechanism.
11. Key constraint
- Since the app is purely client-side, all business logic and all result generation happen on the user’s device.
- That makes the app simple, fast, and dependency-light, but also means no centralized storage of inputs or calculations.
12. Repository summary
- In architectural terms, this repo is a small static calculator app with a clean separation between markup, styling, and computation.
- Its entire purpose is to transform a few fuel-budget assumptions into updated monthly spending guidance after a price increase.
Main entry points: index.html Index · style.css Styles · script.js Script
Components 8
Client-side app
Static browser-delivered calculator UI and logic.
- Index · Main page structure and UI containers.
index.html - Styles · Visual styling for the calculator interface.
style.css - Script · Reads inputs, performs calculations, and updates the page.
script.js - Inputs · Budget, fuel price, and usage assumptions entered by the user.
- Calculator · Derives remaining days, required money, and revised monthly budget.
- Results · Displays the computed comparison values back in the UI.
Other components
- User · Enters fuel budget assumptions and reads the comparison results.
- Browser · Executes the app entirely on the client side.
Connections 10
- User → Browser: uses · User interacts with the app in the browser.
- Browser → Index: loads · Browser loads the static entry page.
- Index → Styles: styles · Page pulls in the shared stylesheet.
- Index → Script: scripts · Page loads the application logic.
- Script → Inputs: reads · Script reads user-entered assumptions from the form.
- Inputs → Calculator: feeds · Input values are transformed into budget comparisons.
- Calculator → Results: writes · Derived values are rendered into the result containers.
- Script → Results: updates · Logic updates the visible output after each calculation.
- Styles → Results: formats · Styles control the appearance of the result display.
- Styles → Inputs: formats · Styles control the appearance of the form controls.