triskweline
Joined 14 years ago
Joined 14 years ago
http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly3-slides/
I'd say 95% of the apps we build are now based on Unpoly, the rest on React.
We now believe SPAs are not a good default for the type of apps we're building. We're still reaching for SPAs when requirements demand high-frequency user input and optimistic rendering, e.g. for a chat or online game.
YMMV!
The old demo app focused on the downsides of classic multi-page apps (MPAs), i.e. the reason the world moved to SPAs all these years ago. In an MPA clicking a link loses all transient state, like focus, scroll positions and unsaved form state. This can all be solved with updating fragments instead of full pages, while still keeping rendering logic on the server.
Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay.
More details can be found here: http://triskweline.de/unpoly2-slides/#78
Feel free to install a screen reader and play with the demo app (https://demo.unpoly.com/).
What stopped us was not so much the lack of libraries, but programming ergonomics. E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. Also mocking was difficult in tests.
Elixir is a great project with a friendly community, it just didn't work for us. YMMV so by all means try it out if you're interested!
spfjs lets you target multiple containers with a single update, e.g. in YouTube the video area and the sidebar with related content.
[1]: https://unpoly.com/
[1]: https://unpoly.com
The problem with test suites is that, as they grow and age, it becomes harder and harder to understand why tests are testing what they test. When a years old test fails because 5 is not 7, you cannot really fix it unless you understand why it was supposed to equal 7 in the first place.
Cucumber is a way to describe requirements at a higher level of abstraction. They provide rationale on top of mere assertions of behavior. This is worth the small overhead of writing step definitions.
I guess you can get the same by heavily commenting your tests. But you cannot enforce this easily in a team.
Happy to answer any questions you might have.