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!
> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order.
That's not generally true in the language. Were you trying to pattern match options in your own functions? Newbies to the language can get excited about the pattern matching feature and try to apply it in places where it's not right (well I may be projecting there).
> Also mocking was difficult in tests.
This is true. Were you using Mox? Mox makes things considerably easier at the cost of some boilerplate, with the added benefit that you can run concurrent mocks. You also have to not think of mocks in elixir like Ruby, they are very different.
I'm sorry I wish someone more experienced with Elixir could have helped onboard you.
> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order.
This would've been fixed by creating a map from the passed in list, which would remove the order dependency but still keep the ergonomics of a keyword list, or just querying the keyword-list with `Keyword.*` functions. Not that big of an issue, to be honest, and not a showstopper. There are much bigger issues with the language, but Ruby doesn't offer any upsides in those cases either.
> Interesting, what exactly was difficult? You just replace one function with another.
I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.
This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang).
It's a pity that the elixir community doesn't make this clearer, because I'm seeing "not being able to Mock" be a common complaint.
It probably depends more on where they are coming from. Mox has more overheads for sure than options in Ruby or Javascript. Its more like mocking in Java or C++; where you declare an interface(behaviour), program against that, and then use dependency injection to load the mock or real code at the right time. I'd been working with Elixir for several years when I first tried using Mox and it still took awhile to get my head around it and figure out how to integrate it into our project. I would not be surprised to hear that newer teams really struggle with it.
> I would not be surprised to hear that newer teams really struggle with it.
I completely agree. Not having an expert Elixirist able to help me: It took me a full six months of fooling around with Mox (and a cryptic feature announcement in the 1.8 release) to really dig into and grok it. At this stage in my elixir experience, I have even PR'd a feature that's been integrated into Mox, so it's not completely incomprhensible, it's a super-well-written library.
Honestly, It's a totally (alien/from-the-future)-technology (in both the good and bad senses) library. The bad senses could be almost trivially fixed with an in-depth, free, online video masterclass or, hell, even a conference lecture on it, and blog posts. More people that really know how it works should blog about how amazing Mox is. Unfortunately, I suspect that the people who are using Mox to its fullest extent are too busy pushing code to prod, ha.
>and why you're supposed to use Mox, which solves that problem
I never used that Mox and never had a need to. I just use `Mock` which allows `passthrough` as I stated in another comment, what other clarity is needed I don't understand. Can you give any example of the problem you can not solve instead of pitiness?
You can't run concurrent tests doing direct mock injection in that fashion, because the mock is global. If you use Mox (or similar), your mocks are tied to your test.
Erm, yes this is why you mock it. I still fail to see the problem, here is an example how you mock a function: https://hexdocs.pm/mock/Mock.html
Inside `with_mock` code will only access mocked function. In case you want to call original function in some condition - you have `passthrough` available inside a new function which will call the original one. So what is the problem exactly?
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.
Thanks for the heads up. I've worked with Intercooler before and while it is a really nice framework, I've always felt it was missing a few critical things. Unpoly looks cool. Do you know if it has a dependency on jQuery still, like Intercooler does? Or does it run independently?
Hello, I've been watching intercoolerjs also, and thinking of using it in a future project. What are the few critical things missing have you experienced ?
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.
Nothing is stopping you from using functions with descriptive names without cucumber. Cucumber forces you to write functions (steps) however you can still create bad descriptions just like function names. Cucumber just allows you to define functions using a different syntax than the language your using. I don't see any wins here.
That has been my recommendation when people started talking about Cucumber at my compnay. Write a library that has super descriptive names like "EnterTextIntoPriceField(400)" and you get the same benefit Cucumber gives you but you have real programming language if needed.
Our biz people can't write useful requirements so I doubt they can write meaningful Cucumber scripts either.
I worked for a very large company that started rolling out cucumber. It didn't go anywhere - Product owners simply did not have the technical ability to write cucumber tests.
I think that they add way too much complexity. It doesn't make sense to try to write technical software tests at such a high level of abstraction.
When you try to test something at a really high level along the lines of "As a user, when I click on X, I want Y to happen" the low level technical ramifications of this can be enormous.
There is a huge amount of underlying complexity which the one-line sentence simply cannot capture and which is prone to change and needs to be tested separately... Probably not in a way that a non-technical manager would understand unfortunately.
Ultimately the tests are not granular enough to be useful as tests for developers and they have too much overhead to be useful as documentation for non managers.
