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.
Author here. The link is a 6 years old presentation. The demo app has since been rewritten.
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.
Our Ruby / Rails agency tried implementing a project in Elixir. After 3 weeks we stopped the experiment and re-did everything in Ruby.
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!
Unpoly [1] lets you achieve the same effect without having to wrap your content in a JSON transport envelope. There are no two cases for static and dynamic navigation. The HTML you already have is used for transport, fragments are targeted with CSS selectors.
We're heavy users of Cucumber at our development agency. I've never seen non-technical users write Cucumber scenarios either, but we find them very useful for another reason.
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.
There are server-side libraries like Unpoly (https://unpoly.com/) that give you most of the benefits of heavyweight JavaScript frameworks, but without the complexity and code duplication.
Author here. Unpoly is my attempt at bridging the gap in user experience between classical, server-side applications and modern single-page applications (SPAs).
We built something similar with Up.js [0].
Rather than wrapping some responses in JSON, Up.js doesn't require any server-side changes. Fragments are selected client-side via CSS selectors.
Although the development shop I work at (makandra) has a constant demand for new engineers, we would never hire someone out of a ten week program.
To give you an idea about what kind of juniority is attractive to a shop like ours: We run our own in-house internship program which takes 9 months. It requires CS degree plus some previous experience (private pet projects are OK) to enter.
The intern is paid living expenses and has vacation like other employees. The goal of the program is to hire the intern as a permanent junior developer after 9 months. Junior starting salary is also a far cry below 100K USD, but then again we don't have to live in San Francisco.
A task tracker / outliner with a Vim-like editing mode that I built for myself a few years back. It gained a lot of popularity through HN and Lifehacker.
I eventually rewrote the application and offered extra features and mobile support for paying subscribers. It now pays for date night with my wife.