Recent submissions

Comment · 7 months ago
This glazes over the torrent of poorly developed ideas you need to deal with in every organization.
Comment · 3 years ago
Author here. Yes, we stuck with it and evolved the concept into Unpoly 2 and soon Unpoly 3:

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!

Comment · 3 years ago
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.

Comment · 3 years ago
Comment · 6 years ago
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!

Comment · 8 years ago
With pjax you choose a selector that is updated. This is usually a <div> in your layout that houses the main page content.

spfjs lets you target multiple containers with a single update, e.g. in YouTube the video area and the sidebar with related content.

Comment · 8 years ago
Comment · 8 years ago
Unpoly currently depends on jQuery. Work is being done to remove that dependency eventually, but that will take time.
Comment · 8 years ago
Comment · 9 years ago
Comment · 9 years ago
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.

Comment · 9 years ago
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.
Comment · 9 years ago
Author here. Unpoly is my attempt at bridging the gap in user experience between classical, server-side applications and modern single-page applications (SPAs).

Happy to answer any questions you might have.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton