agarv
The Bug by Ellen Ullman
Radicalized by Corey Doctrow
Valuable Humans in Transit and Other Stories by qntm
[1] https://en.wikipedia.org/wiki/Color_difference [2] https://dithermark.com
[1]https://app.dithermark.com/ [2]https://imgur.com/a/AiQa14B
https://www.fool.com/investing/2021/02/03/google-revenue-pro...
While there are generally less "native" camera lenses for mirrorless systems, one less well known/publicized advantage of using them is that you can use film camera lenses. While you do not get autofocus and there might be vignetting at the corners (which I personally like anyway), you can get a good quality lens for a good price by doing this. It also can be cool if you are trying to recreate a "vintage" look, or just going for something weird or unusual. All that is required is a cheap adapter that you costs around $5 on ebay. Two of my personal favorite lenses to use are the Jupiter 9 (the whole Jupiter series are Soviet copies of Carl Zeiss lenses) that I got for $175, and the SLR magic 3517E which I got for $37. This video has a general overview: https://www.youtube.com/watch?v=aQLi4g-wyDA
1. Clear separation of concerns for front-end and back-end teams. With SPAs, the work is clearly divided into front-end and back-end parts, with the back-end team working on the server side code and the front-end team working on the static assets (HTML, JS, CSS). Both sides only communicate through a clearly defined API (e.g. REST, GraphQL, SOAP) which allows both teams to work independently of each other, and means that if there are bugs or problems, there is less confusion on which team is causing them and thus which team needs to fix them. Compare that with server side rendering using an MVC framework such as Rails. The migration and model code "obviously" belongs to the back-end team, and the static assets (JS, CSS) and views/templates belong to the front-end team, but what about the controllers and routing? Both teams are going to need to work on those parts of the codebase, and that's going to increase the need for inter-team communication and confusion on which team owns what. For example, I interviewed at a company where the front-end team was US based and the back-end team was outsourced to India, and they were moving to a SPA so the teams could work more independently. Previously they had used JSP, which meant the front-end team had to write HTML and then send it to the back-end team and then they had to coordinate how the back-end team was going to re-write the HTML as a JSP template.
2. Cheaper mobile and desktop apps. While it seems HN is very negative about non-native apps, it's not hard to see the business case of quickly and cheaply converting your website into a mobile or desktop app using something like Electron, Cordova or a web view. Even if you do plan to make a native app, the SPA and native app can reuse the same APIs, reducing the amount of work for your back-end and QA teams.
3. Flexibility in changing back-ends. While less common than the other two cases, if you decide to change your back-end code (such as Twitter moving from Ruby to Scala) if your app is an SPA you only need to recreate the APIs and don't have to rewrite all your templating code (this is less of a problem if you use a more "neutral" cross-platform template language like Handlebars). For me personally, I'm moving all my personal projects to Elixir/Phoenix from PHP, Rails or Java, and because I used server side rendering I had to convert all my templating code to EEX.
https://en.wikipedia.org/wiki/Scott_Johnson_(composer)#John_... https://www.youtube.com/watch?v=IPlY4X5hrYk