80 seems good to me.

This may not be news to developers, but might be useful for broader company discussions.

Comments URL: https://news.ycombinator.com/item?id=23391730

Points: 4

# Comments: 1

Or what if I start taking notes on some random subject for fun, and eventually I write and sell a book based on them? All of a sudden I need to start paying a yearly fee?

It's not a prohibitive amount of money, but I'd be much happier with paying a one-time fee for the current version, then buying future versions if I choose to.

Yes, and there is some correlation between age and seniority. If companies are so eager to hire senior developers, they might consider the preferences of candidates who have been working long enough to fit that description.

You decide that B has to compete with A on talent, but A doesn't have to compete with B on price.

Does that make strategic sense?

Companies: "I don't have to pay you $big_city rates because you live in $small_town and nobody there will offer you $big_city rates."

Candidates: "I don't have to accept $small_town rates because I work remotely and can work for a company in $big_city."

OTOH, your applicant pool is limited only to the time zones and legal jurisdictions you're willing to hire from. If you're office-based, it's limited to those who can reasonably commute there.

Agreed. But the reverse is also true: it's harder for people to interrupt you.

Yes and no. The larger the number of dependencies you have, and the larger number of maintainers that are behind them, the more chances you have of one of them containing malicious code.

I think you're pretty safe from Phoenix or Rails or NodeJS getting owned because so many people work on them. But one of the thousand small packages you use may belong to someone careless or malicious.

However, 1) you can add custom JS using LiveView's hooks, which might be enough for very simple offline behavior and 2) many SPAs don't work offline either.

If offline support is a major part of your app's design, LiveView isn't a good fit. But you could still use Phoenix Channels (the building block underneath LiveView) to provide fast push updates to your client. See the channels docs for an idea of how they work - https://hexdocs.pm/phoenix/channels.html

I would caveat that in a couple of ways.

First, suppose you have a web app where some requests involve heavy number crunching and others don't. In web frameworks where 1 request ties up 1 OS thread, a burst of heavy requests could gobble up all your available connections. Phoenix would use one cheap BEAM process per request, and the BEAM's preemptive scheduler would ensure that other requests are answered in a timely way and that all the heavy ones continue to make steady progress. So although the heavy requests might be completed more slowly than in another language, the overall system would remain more responsive.

Second, if you have need for heavy computation or data structures that work better with mutability, it's possible to (eg) use Rustler (https://github.com/rusterlium/rustler) to implement that part in Rust. See https://github.com/rusterlium/rustler for a story about doing this.

To expand on your workload description: things like waiting for a database query or an API result are smoothly handled in this paradigm; the process goes to sleep for a bit whle another request is processed.

If your workflow is like a delivery truck which makes a lot of stops, "faster trucks" doesn't help much with throughput. "More trucks" is better.

See the architecture of Phoenix Channels (which powers LiveView and other websocket-based solutions in Phoenix): https://hexdocs.pm/phoenix/channels.html