After reading Who is it for? page I get that Inertia.js tries to solve the problems of modern SPAs in JavaScript realm. Regardless of choosing the backend language and framework, building an API on it and make it consumable by JSON, ProtoBuf or GraphQL, I don’t see any added benefits that Inertia.js brings to the table. Let me explain:
-
State Management
The Elm Architecture or TEA is a rock-solid replacement for almost all the state management problems in modern SPAs. Its design and implementation is so simple and powerful that tools like Redux and Vue influenced by it! Thanks @evancz
-
Search Engine Optimization
It’s a known issue that SPAs built for public-facing web applications lack the proper support of major search engine crawlers, but key players like Google provides some sort of indexing based on web standards in your application. Besides this, there are some projects in the Elm community which address this issue like elm-starter, elm-static or elm-pages. Thanks @lucamug @dillonkearns -
Routing
This could be an issue in JavaScript SPAs but not in Elm! Why? Url Parsing is one if the best parts of the Elm standard library. Just have a look at elm-browser and elm-url APIs. Note that there’s a missing page in the official guide which is completed by a community member in his blog post. Thanks @alexkorban
In summary, when I try to solve problems in JavaScript realm and translate it back into Elm, I often ask myself whether It’s a good idea or not. Not that Elm always provide the best solutions for each and every web application requirements, but I try to compare my solutions with Structure section on the Elm guide. It’s always a good reference for me. Thanks @rtfeldman