nhaliday + client-server   25

REST is the new SOAP | Hacker News
hn  commentary  techtariat  org:ngo  programming  engineering  web  client-server  networking  rant  rhetoric  contrarianism  idk  org:med  best-practices  working-stiff  api  models  protocol-metadata  internet  state  structure  chart  multi  q-n-a  discussion  expert-experience  track-record  reflection  cost-benefit  design  system-design  comparison  code-organizing  flux-stasis  interface-compatibility  trends  gotchas  stackex  state-of-art  distributed  concurrency  abstraction  concept  conceptual-vocab  python  ubiquity  list  top-n  duplication  synchrony  performance  caching 
4 weeks ago by nhaliday
The Definitive Guide To Website Authentication | Hacker News
hn  commentary  q-n-a  stackex  programming  identification-equivalence  security  web  client-server  crypto  checklists  best-practices  objektbuch  api  multi  cheatsheet  chart  system-design  nitty-gritty  yak-shaving  comparison  explanation  summary  jargon  state  networking  protocol-metadata  time 
5 weeks ago by nhaliday
Advantages and disadvantages of building a single page web application - Software Engineering Stack Exchange
- All data has to be available via some sort of API - this is a big advantage for my use case as I want to have an API to my application anyway. Right now about 60-70% of my calls to get/update data are done through a REST API. Doing a single page application will allow me to better test my REST API since the application itself will use it. It also means that as the application grows, the API itself will grow since that is what the application uses; no need to maintain the API as an add-on to the application.
- More responsive application - since all data loaded after the initial page is kept to a minimum and transmitted in a compact format (like JSON), data requests should generally be faster, and the server will do slightly less processing.

- Duplication of code - for example, model code. I am going to have to create models both on the server side (PHP in this case) and the client side in Javascript.
- Business logic in Javascript - I can't give any concrete examples on why this would be bad but it just doesn't feel right to me having business logic in Javascript that anyone can read.
- Javascript memory leaks - since the page never reloads, Javascript memory leaks can happen, and I would not even know where to begin to debug them.


Disadvantages I often see with Single Page Web Applications:
- Inability to link to a specific part of the site, there's often only 1 entry point.
- Disfunctional back and forward buttons.
- The use of tabs is limited or non-existant.
(especially mobile:)
- Take very long to load.
- Don't function at all.
- Can't reload a page, a sudden loss of network takes you back to the start of the site.

This answer is outdated, Most single page application frameworks have a way to deal with the issues above – Luis May 27 '14 at 1:41
@Luis while the technology is there, too often it isn't used. – Pieter B Jun 12 '14 at 6:53


Server-side HTML rendering:
- Fastest browser rendering
- Page caching is possible as a quick-and-dirty performance boost
- For "standard" apps, many UI features are pre-built
- Sometimes considered more stable because components are usually subject to compile-time validation
- Leans on backend expertise
- Sometimes faster to develop*
*When UI requirements fit the framework well.

Client-side HTML rendering:
- Lower bandwidth usage
- Slower initial page render. May not even be noticeable in modern desktop browsers. If you need to support IE6-7, or many mobile browsers (mobile webkit is not bad) you may encounter bottlenecks.
- Building API-first means the client can just as easily be an proprietary app, thin client, another web service, etc.
- Leans on JS expertise
- Sometimes faster to develop**
**When the UI is largely custom, with more interesting interactions. Also, I find coding in the browser with interpreted code noticeably speedier than waiting for compiles and server restarts.


1. SPA is extremely good for very responsive sites:
2. With SPA we don't need to use extra queries to the server to download pages.
3.May be any other advantages? Don't hear about any else..

1. Client must enable javascript.
2. Only one entry point to the site.
3. Security.

focused on .NET

A SPA comes with a few issues associated with it. Here are just a few that pop in my mind now:
- it's mostly JavaScript. One error in a section of your application might prevent other sections of the application to work because of that Javascript error.
- SEO.
- separate front-end application means separate projects, deployment pipelines, extra tooling, etc;
- security is harder to do when all the code is on the client;

- completely interact in the front-end with the user and only load data as needed from the server. So better responsiveness and user experience;
- depending on the application, some processing done on the client means you spare the server of those computations.
- have a better flexibility in evolving the back-end and front-end (you can do it separately);
- if your back-end is essentially an API, you can have other clients in front of it like native Android/iPhone applications;
- the separation might make is easier for front-end developers to do CSS/HTML without needing to have a server application running on their machine.

Create your own dysfunctional single-page app: https://news.ycombinator.com/item?id=18341993
I think are three broadly assumed user benefits of single-page apps:
1. Improved user experience.
2. Improved perceived performance.
3. It’s still the web.

5 mistakes to create a dysfunctional single-page app
Mistake 1: Under-estimate long-term development and maintenance costs
Mistake 2: Use the single-page app approach unilaterally
Mistake 3: Under-invest in front end capability
Mistake 4: Use naïve dev practices
Mistake 5: Surf the waves of framework hype

The disadvantages of single page applications: https://news.ycombinator.com/item?id=9879685
You probably don't need a single-page app: https://news.ycombinator.com/item?id=19184496
MPA advantages:
- Stateless requests
- The browser knows how to deal with a traditional architecture
- Fewer, more mature tools
- SEO for free

When to go for the single page app:
- Core functionality is real-time (e.g Slack)
- Rich UI interactions are core to the product (e.g Trello)
- Lots of state shared between screens (e.g. Spotify)

Hybrid solutions
Github uses this hybrid approach.

Ask HN: Is it ok to use traditional server-side rendering these days?: https://news.ycombinator.com/item?id=13212465

The SEO issues with SPAs is a persistent concern you hear about a lot, yet nobody ever quantifies the issues. That is because search engines keep the operation of their crawler bots and indexing secret. I have read into it some, and it seems that problem used to exist, somewhat, but is more or less gone now. Bots can deal with SPAs fine.
I try to avoid building a SPA nowadays if possible. Not because of SEO (there are now server-side solutions to help with that), but because a SPA increases the complexity of the code base by a magnitude. State management with Redux... Async this and that... URL routing... And don't forget to manage page history.

How about just render pages with templates and be done?

If I need a highly dynamic UI for a particular feature, then I'd probably build an embeddable JS widget for it.
q-n-a  stackex  programming  engineering  tradeoffs  system-design  design  web  frontend  javascript  cost-benefit  analysis  security  state  performance  traces  measurement  intricacy  code-organizing  applicability-prereqs  multi  comparison  smoothness  shift  critique  techtariat  chart  ui  coupling-cohesion  interface-compatibility  hn  commentary  best-practices  discussion  trends  client-server  api  composition-decomposition  cycles  frameworks  ecosystem  degrees-of-freedom  dotnet  working-stiff  reddit  social 
7 weeks ago by nhaliday
Ask HN: Learning modern web design and CSS | Hacker News
Ask HN: Best way to learn HTML and CSS for web design?: https://news.ycombinator.com/item?id=11048409
Ask HN: How to learn design as a hacker?: https://news.ycombinator.com/item?id=8182084

Ask HN: How to learn front-end beyond the basics?: https://news.ycombinator.com/item?id=19468043
Ask HN: What is the best JavaScript stack for a beginner to learn?: https://news.ycombinator.com/item?id=8780385
Free resources for learning full-stack web development: https://news.ycombinator.com/item?id=13890114

Ask HN: What is essential reading for learning modern web development?: https://news.ycombinator.com/item?id=14888251
Ask HN: A Syllabus for Modern Web Development?: https://news.ycombinator.com/item?id=2184645

Ask HN: Modern day web development for someone who last did it 15 years ago: https://news.ycombinator.com/item?id=20656411
hn  discussion  design  form-design  frontend  web  tutorial  links  recommendations  init  pareto  efficiency  minimum-viable  move-fast-(and-break-things)  advice  roadmap  multi  hacker  games  puzzles  learning  guide  dynamic  retention  DSL  working-stiff  q-n-a  javascript  frameworks  ecosystem  libraries  client-server  hci  ux  books  chart 
8 weeks ago by nhaliday
its-not-software - steveyegge2
You don't work in the software industry.


So what's the software industry, and how do we differ from it?

Well, the software industry is what you learn about in school, and it's what you probably did at your previous company. The software industry produces software that runs on customers' machines — that is, software intended to run on a machine over which you have no control.

So it includes pretty much everything that Microsoft does: Windows and every application you download for it, including your browser.

It also includes everything that runs in the browser, including Flash applications, Java applets, and plug-ins like Adobe's Acrobat Reader. Their deployment model is a little different from the "classic" deployment models, but it's still software that you package up and release to some unknown client box.



Our industry is so different from the software industry, and it's so important to draw a clear distinction, that it needs a new name. I'll call it Servware for now, lacking anything better. Hardware, firmware, software, servware. It fits well enough.

Servware is stuff that lives on your own servers. I call it "stuff" advisedly, since it's more than just software; it includes configuration, monitoring systems, data, documentation, and everything else you've got there, all acting in concert to produce some observable user experience on the other side of a network connection.
techtariat  sv  tech  rhetoric  essay  software  saas  devops  engineering  programming  contrarianism  list  top-n  best-practices  applicability-prereqs  desktop  flux-stasis  homo-hetero  trends  games  thinking  checklists  dbs  models  communication  tutorial  wiki  integration-extension  frameworks  api  whole-partial-many  metrics  retrofit  c(pp)  pls  code-dive  planning  working-stiff  composition-decomposition  libraries  conceptual-vocab  amazon  system-design  cracker-prog  tech-infrastructure  blowhards  client-server 
may 2019 by nhaliday
Latency Numbers Every Programmer Should Know
systems  networking  performance  programming  os  engineering  tech  paste  cheatsheet  objektbuch  street-fighting  🖥  techtariat  big-picture  caching  magnitude  nitty-gritty  scaling-tech  let-me-see  quantitative-qualitative  chart  reference  nibble  career  interview-prep  time  scale  measure  comparison  metal-to-virtual  multi  sequential  visualization  trends  multiplicative  speed  web  dynamic  q-n-a  stackex  estimate  accuracy  org:edu  org:junk  visual-understanding  benchmarks  latency-throughput  client-server  thinking  howto  explanation  crosstab  within-group  usa  geography  maps  urban-rural  correlation 
may 2016 by nhaliday
The Setup / Russ Cox
I swear by the small Apple keyboard (in stores they have one that size with a USB cable too) and the Evoluent mouse.


I run acme full screen as my day to day work environment. It serves the role of editor, terminal, and window system. It's hard to get a feel for it without using it, but this video helps a little.

Rob Pike's sam editor deserves special mention too. From a UI standpoint, it's a graphical version of ed, which you either love or hate, but it does two things better than any other editor I know. First, it is a true multi-file editor. I have used it to edit thousands of files at a time, interactively. Second, and even more important, it works insanely well over low-bandwidth, high-latency connections. I can run sam in Boston to edit files in Sydney over ssh connections where the round trip time would make vi or emacs unusable. Sam runs as two halves: the UI half runs locally and knows about the sections of the file that are on or near the screen, the back end half runs near the files, and the two halves communicate using a well-engineered custom protocol. The original target environment was 1200 bps modem lines in the early 1980s, so it's a little surprising how relevant the design remains, but in fact, it's the same basic design used by any significant JavaScript application on the web today. Finally, sam is the editor of choice for both Ken Thompson and Bjarne Stroustroup. If you can satisfy both of them, you're doing something right.


I use Unison to sync files between my various computers. Dropbox seems to be the hot new thing, but I like that Unison doesn't ever store my files on someone else's computers.


I want to be working on my home desktop, realize what time it is, run out the door to catch my train, open my laptop on the train, continue right where I left off, close the laptop, hop off the train, sit down at work, and have all my state sitting there on the monitor on my desk, all without even thinking about it.
programming  hardware  plan9  rsc  software  recommendations  techtariat  devtools  worse-is-better/the-right-thing  nostalgia  summer-2014  interview  ergo  osx  linux  desktop  consumerism  people  editors  tools  list  google  cloud  os  profile  summary  c(pp)  networking  performance  distributed  config  cracker-prog  heavyweights  unix  workflow  client-server 
july 2014 by nhaliday

related tags

ability-competence  abstraction  accretion  accuracy  advice  africa  aggregator  allodium  amazon  analysis  anonymity  api  applicability-prereqs  atoms  backup  benchmarks  best-practices  big-picture  blowhards  books  browser  build-packaging  business  c(pp)  caching  calculator  career  chart  cheatsheet  checking  checklists  client-server  cloud  code-dive  code-organizing  commentary  communication  comparison  compensation  compilers  complement-substitute  composition-decomposition  compression  concept  conceptual-vocab  concurrency  config  consumerism  contradiction  contrarianism  correlation  cost-benefit  coupling-cohesion  cracker-prog  critique  crosstab  crypto  cycles  d3  dan-luu  data  data-science  database  dataviz  dbs  debugging  degrees-of-freedom  demographics  design  desktop  detail-architecture  developing-world  devops  devtools  diogenes  discipline  discussion  distributed  distribution  dotnet  DSL  duplication  dynamic  econ-metrics  ecosystem  editors  efficiency  engineering  ergo  essay  estimate  examples  expert-experience  explanation  exploratory  facebook  flux-stasis  form-design  frameworks  frontend  frontier  functional  games  gender  geography  google  gotchas  graphics  grugq  guide  hacker  happy-sad  hardware  hci  heavyweights  hn  homo-hetero  howto  human-capital  identification-equivalence  idk  IEEE  increase-decrease  init  integration-extension  interface-compatibility  internet  interview  interview-prep  intricacy  ios  jargon  javascript  jobs  knowledge  latency-throughput  learning  let-me-see  libraries  links  linux  list  lol  low-hanging  magnitude  management  maps  measure  measurement  metabuch  metal-to-virtual  metrics  minimum-viable  mobile  models  money  move-fast-(and-break-things)  multi  multiplicative  network-structure  networking  nibble  nitty-gritty  no-go  nostalgia  objektbuch  opsec  org:com  org:edu  org:junk  org:med  org:ngo  os  osx  paradox  pareto  parsimony  paste  people  performance  plan9  planning  pls  poll  pragmatic  presentation  privacy  pro-rata  profile  programming  progression  project  protocol-metadata  puzzles  python  q-n-a  quantitative-qualitative  questions  rant  realness  recommendations  recruiting  reddit  reference  reflection  repo  responsibility  retention  retrofit  rhetoric  roadmap  rsc  saas  scale  scaling-tech  search  security  self-control  sentiment  sequential  shift  shipping  simulation  slides  smoothness  social  software  speed  stackex  startups  state  state-of-art  stories  street-fighting  structure  summary  summer-2014  sv  synchrony  synthesis  system-design  systems  tech  tech-infrastructure  techtariat  thinking  time  time-series  time-use  tools  top-n  traces  track-record  tradecraft  tradeoffs  transitions  trends  tutorial  types  ubiquity  ui  unintended-consequences  unit  universalism-particularism  unix  urban-rural  usa  ux  vcs  video  visual-understanding  visualization  wealth  web  whole-partial-many  wiki  within-group  workflow  working-stiff  world  worse-is-better/the-right-thing  yak-shaving  🖥 

Copy this bookmark: