DockYard Blog

> An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy.

Most of the time I find the initial delay loading/parsing the js to be more problematic than the often tiny speed increase of subsequent loads.

Furthermore, these days it takes minimal to no tweaking to get server-side rendered pages to load fast enough to barely notice the difference (in particular if the client-side is retrieving and parsing JSON in the background through an API request). Perhaps non-webdevs are even less likely to notice this stuff.

> If done well you can totally run offline.

That's definitely an advantage, but most SPAs I encounter don't offer offline functionality, or it's entirely unnecessary to offer it.

> Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.

In some cases that's definitely an advantage. But it's entirely feasible to build an API-based backend and use that API internally for server-side rendering. If you want an app that plays nice with search engines you have to do this anyways.

> This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.

That doesn't make sense…

One possible solution to this problem is the Free, Open Source Software community continuing to work toward more sophisticated tech that can bridge the gap between popular server-side languages for Web Dev and native platforms. PhoneGap was a failure because it was JS running on the phone, rather than compiling to something faster and with a more “native feel”. React Native is, IMHO, not that much better (and the React ecosystem has ridiculous fragmentation and churn). Flutter seems cool, but Dart is not a popular server-side language (and from what I heard anecdotally, Flutter also has API complexity and churn).

Personally, I think Elixir is a natural choice for this kind of task (disclosure: I am incredibly biased in my love for Elixir).

Macro-based DSLs are not beloved by all, but they can take you pretty far with minimal overhead, since you can theoretically target multiple platforms without even having to ship a custom runtime to the phone. Aside from the language itself, there is a great community, less fragmentation and churn, and a tendency to build thoughtful, robust libraries and frameworks with good docs.

For inspiration, take a look at Mitch Hanberg’s Temple project[0] which compiles valid Elixir code to something that eventually gets turned into HTML.

DockYard is also doing really cool, bleeding edge stuff with LiveView Native[1], even if it’s a bit early to predict how viable it will be for large, complex apps.

If we can have a way to build efficient,…

I’ve worked on e-commerce recs. Typically you would represent each product with a vector. Then finding similar products becomes a nearest-neighbour search over these vectors. Depending on your use-case it’s feasible now to do this search in the db using pgvector, or using something like solr/elastic which both support vector search in recent releases. You could also use something like faiss or one of the many nearest-neighbour libraries or dedicated vector search engines. (Since you are working with Elixir, you might find ExFaiss interesting [1][2][3]).

But I would say that for recommendations, searching the vectors is the easy part. The main work in getting good recommendations is generating a good set of product vectors in the first place. The quality of the recommendations is directly related how you generate the vectors. You could use one of the many open-source language models to generate vectors, but typically that approach isn’t very good for product recommendations. It will just give you items that are textually similar, and this usually doesn’t give good product recommendations.

To get good product recommendations you’d probably want to build a custom embedding that captures some notion of product similarity during training using some signals you get from user behaviour. E.g. things like products clicked in the same session, or added to cart at the same time, gives a signal on product similarity that you can use to train a product embedding for…

I would say it's about developer happiness while coding and that all the decisions made by Jose and the core team tend to have been the correct decision. So taking Phoenix as an example you look at the framework and every time they find a problem i.e. Presence instead of saying that's a difficult problem and moving on they fix said problem in a really scalable way [1].

The same could be said for things like data processing with Flow [2] or even things like Ecto (semi official database wrapper) or even third party libraries like say ex_money [3].

Then you start looking at the packages and language and see that there are rarely thousands of bugs or that the infrastructure (mix, hex, docs etc.) is really nice to use and that the language is really stable, yet still provides you with useful but clear abstractions. Or that you can spin off processes and tasks inline without too much worry, or that you can use 20+ years of Erlang libs transparently, or that it's immutable and has the best concurrency primitives of any system available, or that it allow you to supervise processes and let them crash if needed without bringing down your app, or that you can transparently get multi machine out of the box, or that message passing is build in as the default way to scale the system. Or pattern matching or |> or the amazing community.

[1] https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections and…

DockYard | Multiple Job Openings | Full-Time | Remote (United States)

Current openings:

- HTML/CSS Specialist (Engineering)

- Ember Developer (Engineering)

- Ruby on Rails Developer (Engineering)

- Content Manager

- Project Manager

Listings and Application for all positions here:
https://hire.withgoogle.com/public/jobs/dockyardcom

DockYard is a software consultancy that helps companies design, engineer, and iterate on their most important digital products. Our team is smart, relatable, and deeply knowledgeable about modern application architecture and UX. We work alongside teams building beautiful, functional web applications with an eye toward the future. We're driven by creating exceptional user experiences, whether that be through Progressive Web Apps, well functioning data applications, or innovative front end design.

We specialize in Ember, Elixir/Phoenix, UX/UI and Progressive Web App development. You can learn more about at us https://www.dockyard.com

Consider these two scenarios.

1. SPA with asynchronous server communication. A button switches to a spinner the moment you click it, and spins until the update is safe at the server. Error messages can show up near the button, or in a toast.

2. LiveView where updates go via the server. The button shows no change (after recovering from submit "bounce" animation) until a response from the server has come back to you. To do anything better, you need to write it yourself, and now you're back in SPA world again.

There's a reason textarea input isn't sent to a server with the server updating the visible contents! Same thing applies to all aspects of the UX.

EDIT: https://dockyard.com/blogs/optimizing-user-experience-with-liveview talks about this. That'll handle things like buttons being disabled while a request is in flight, but it won't e.g. immediately add new TODO items to the classic TODO list example.