recentpopularlog in

nhaliday : web   152

« earlier  
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 
november 2019 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 
november 2019 by nhaliday
javascript - ReactJS - Does render get called any time "setState" is called? - Stack Overflow
By default - yes.

There is a method boolean shouldComponentUpdate(object nextProps, object nextState), each component has this method and it's responsible to determine "should component update (run render function)?" every time you change state or pass new props from parent component.

You can write your own implementation of shouldComponentUpdate method for your component, but default implementation always returns true - meaning always re-run render function.

...

Next part of your question:

If so, why? I thought the idea was that React only rendered as little as needed - when state changed.

There are two steps of what we may call "render":

Virtual DOM render: when render method is called it returns a new virtual dom structure of the component. As I mentioned before, this render method is called always when you call setState(), because shouldComponentUpdate always returns true by default. So, by default, there is no optimization here in React.

Native DOM render: React changes real DOM nodes in your browser only if they were changed in the Virtual DOM and as little as needed - this is that great React's feature which optimizes real DOM mutation and makes React fast.
q-n-a  stackex  programming  intricacy  nitty-gritty  abstraction  state  frontend  web  javascript  libraries  facebook  frameworks  explanation  summary  models 
october 2019 by nhaliday
What does it mean when a CSS rule is grayed out in Chrome's element inspector? - Stack Overflow
It seems that a strike-through indicates that a rule was overridden, but what does it mean when a style is grayed out?

--

Greyed/dimmed out text, can mean either

1. it's a default rule/property the browser applies, which includes defaulted short-hand properties.
2. It involves inheritance which is a bit more complicated.

...

In the case where a rule is applied to the currently selected element due to inheritance (i.e. the rule was applied to an ancestor, and the selected element inherited it), chrome will again display the entire ruleset.

The rules which are applied to the currently selected element appear in normal text.

If a rule exists in that set but is not applied because it's a non-inheritable property (e.g. background color), it will appear as greyed/dimmed text.

https://stackoverflow.com/questions/34712218/what-does-it-mean-when-chrome-dev-tools-shows-a-computed-property-greyed-out
Please note, not the Styles panel (I know what greyed-out means in that context—not applied), but the next panel over, the Computed properties panel.
--
The gray calculated properties are neither default, nor inherited. This only occurs on properties that were not defined for the element, but _calculated_ from either its children or parent _based on runtime layout rendering_.

Take this simple page as an example, display is default and font-size is inherited:
q-n-a  stackex  programming  frontend  web  DSL  form-design  devtools  explanation  trivia  tip-of-tongue  direct-indirect  trees  spreading  multi  nitty-gritty  static-dynamic  constraint-satisfaction  ui  browser  properties 
october 2019 by nhaliday
Advantages and disadvantages of building a single page web application - Software Engineering Stack Exchange
Advantages
- 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.

Disadvantages
- 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

https://softwareengineering.stackexchange.com/questions/201838/building-a-web-application-that-is-almost-completely-rendered-by-javascript-whi

https://softwareengineering.stackexchange.com/questions/143194/what-advantages-are-conferred-by-using-server-side-page-rendering
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.

https://softwareengineering.stackexchange.com/questions/237537/progressive-enhancement-vs-single-page-apps

https://stackoverflow.com/questions/21862054/single-page-application-advantages-and-disadvantages
=== ADVANTAGES ===
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..

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

https://softwareengineering.stackexchange.com/questions/287819/should-you-write-your-back-end-as-an-api
focused on .NET

https://softwareengineering.stackexchange.com/questions/337467/is-it-normal-design-to-completely-decouple-backend-and-frontend-web-applications
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.
- CORS.
- 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
https://news.ycombinator.com/item?id=20384738
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

https://www.reddit.com/r/webdev/comments/cp9vb8/are_people_still_doing_ssr/
https://www.reddit.com/r/webdev/comments/93n60h/best_javascript_modern_approach_to_multi_page/
https://www.reddit.com/r/webdev/comments/aax4k5/do_you_develop_solely_using_spa_these_days/
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  project-management 
october 2019 by nhaliday
Codepip | Learn to code by playing games
I don't really like frontend stuff tbh so this kind of stuff might be path of least resistance to me learning it
puzzles  games  learning  frontend  web  DSL  programming  javascript  tutorial  init  form-design  dynamic  money-for-time  working-stiff 
october 2019 by nhaliday
When to use margin vs padding in CSS - Stack Overflow
TL;DR: By default I use margin everywhere, except when I have a border or background and want to increase the space inside that visible box.

To me, the biggest difference between padding and margin is that vertical margins auto-collapse, and padding doesn't.

https://stackoverflow.com/questions/5958699/difference-between-margin-and-padding
One key thing that is missing in the answers here:

Top/Bottom margins are collapsible.

So if you have a 20px margin at the bottom of an element and a 30px margin at the top of the next element, the margin between the two elements will be 30px rather than 50px. This does not apply to left/right margin or padding.
--
Note that there are very specific circumstances in which vertical margins collapse - not just any two vertical margins will do so. Which just makes it all the more confusing (unless you're very familiar with the box model).

[ed.: roughly, separation = padding(A) + padding(B) + max{margin(A), margin(B)}, border in between padding and margin]
q-n-a  stackex  comparison  explanation  summary  best-practices  form-design  DSL  web  frontend  stylized-facts  methodology  programming  multi 
october 2019 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 
october 2019 by nhaliday
58 Bytes of CSS to look great nearly everywhere | Hacker News
Author mentions this took a long time to arrive at.
I recommend "Web Design in 4 Minutes" from the CSS guru behind Bulma:

https://jgthms.com/web-design-in-4-minutes/
[ed.: lottsa sensible criticism of the above in the comments]
https://news.ycombinator.com/item?id=12166687
hn  commentary  techtariat  design  form-design  howto  web  frontend  minimum-viable  efficiency  minimalism  parsimony  move-fast-(and-break-things)  tutorial  multi  mobile  init  advice 
october 2019 by nhaliday
Python Tutor - Visualize Python, Java, C, C++, JavaScript, TypeScript, and Ruby code execution
C++ support but not STL

Ten years and nearly ten million users: my experience being a solo maintainer of open-source software in academia: http://www.pgbovine.net/python-tutor-ten-years.htm
I HYPERFOCUS ON ONE SINGLE USE CASE
I (MOSTLY*) DON'T LISTEN TO USER REQUESTS
I (MOSTLY*) REFUSE TO EVEN TALK TO USERS
I DON'T DO ANY MARKETING OR COMMUNITY OUTREACH
I KEEP EVERYTHING STATELESS
I DON'T WORRY ABOUT PERFORMANCE OR RELIABILITY
I USE SUPER OLD AND STABLE TECHNOLOGIES
I DON'T MAKE IT EASY FOR OTHERS TO USE MY CODE
FINALLY, I DON'T LET OTHER PEOPLE CONTRIBUTE CODE
UNINSPIRATIONAL PARTING THOUGHTS
APPENDIX: ON OPEN-SOURCE SOFTWARE MAINTENANCE
tools  devtools  worrydream  ux  hci  research  project  homepage  python  programming  c(pp)  javascript  jvm  visualization  software  internet  web  debugging  techtariat  state  form-design  multi  reflection  oss  shipping  community  collaboration  marketing  ubiquity  robust  worse-is-better/the-right-thing  links  performance  engineering  summary  list  top-n  pragmatic  cynicism-idealism 
september 2019 by nhaliday
selenium - What is the difference between cssSelector & Xpath and which is better with respect to performance for cross browser testing? - Stack Overflow
CSS selectors perform far better than Xpath and it is well documented in Selenium community. Here are some reasons,
- Xpath engines are different in each browser, hence make them inconsistent
- IE does not have a native xpath engine, therefore selenium injects its own xpath engine for compatibility of its API. Hence we lose the advantage of using native browser features that WebDriver inherently promotes.
- Xpath tend to become complex and hence make hard to read in my opinion
However there are some situations where, you need to use xpath, for example, searching for a parent element or searching element by its text (I wouldn't recommend the later).
--
I’m going to hold the unpopular on SO selenium tag opinion that XPath is preferable to CSS in the longer run.

This long post has two sections - first I'll put a back-of-the-napkin proof the performance difference between the two is 0.1-0.3 milliseconds (yes; that's 100 microseconds), and then I'll share my opinion why XPath is more powerful.

...

With the performance out of the picture, why do I think xpath is better? Simple – versatility, and power.

Xpath is a language developed for working with XML documents; as such, it allows for much more powerful constructs than css.
For example, navigation in every direction in the tree – find an element, then go to its grandparent and search for a child of it having certain properties.
It allows embedded boolean conditions – cond1 and not(cond2 or not(cond3 and cond4)); embedded selectors – "find a div having these children with these attributes, and then navigate according to it".
XPath allows searching based on a node's value (its text) – however frowned upon this practice is, it does come in handy especially in badly structured documents (no definite attributes to step on, like dynamic ids and classes - locate the element by its text content).

The stepping in css is definitely easier – one can start writing selectors in a matter of minutes; but after a couple of days of usage, the power and possibilities xpath has quickly overcomes css.
And purely subjective – a complex css is much harder to read than a complex xpath expression.
q-n-a  stackex  comparison  best-practices  programming  yak-shaving  python  javascript  web  frontend  performance  DSL  debate  grokkability  trees  grokkability-clarity 
august 2019 by nhaliday
Computer latency: 1977-2017
If we look at overall results, the fastest machines are ancient. Newer machines are all over the place. Fancy gaming rigs with unusually high refresh-rate displays are almost competitive with machines from the late 70s and early 80s, but “normal” modern computers can’t compete with thirty to forty year old machines.

...

If we exclude the game boy color, which is a different class of device than the rest, all of the quickest devices are Apple phones or tablets. The next quickest device is the blackberry q10. Although we don’t have enough data to really tell why the blackberry q10 is unusually quick for a non-Apple device, one plausible guess is that it’s helped by having actual buttons, which are easier to implement with low latency than a touchscreen. The other two devices with actual buttons are the gameboy color and the kindle 4.

After that iphones and non-kindle button devices, we have a variety of Android devices of various ages. At the bottom, we have the ancient palm pilot 1000 followed by the kindles. The palm is hamstrung by a touchscreen and display created in an era with much slower touchscreen technology and the kindles use e-ink displays, which are much slower than the displays used on modern phones, so it’s not surprising to see those devices at the bottom.

...

Almost every computer and mobile device that people buy today is slower than common models of computers from the 70s and 80s. Low-latency gaming desktops and the ipad pro can get into the same range as quick machines from thirty to forty years ago, but most off-the-shelf devices aren’t even close.

If we had to pick one root cause of latency bloat, we might say that it’s because of “complexity”. Of course, we all know that complexity is bad. If you’ve been to a non-academic non-enterprise tech conference in the past decade, there’s a good chance that there was at least one talk on how complexity is the root of all evil and we should aspire to reduce complexity.

Unfortunately, it's a lot harder to remove complexity than to give a talk saying that we should remove complexity. A lot of the complexity buys us something, either directly or indirectly. When we looked at the input of a fancy modern keyboard vs. the apple 2 keyboard, we saw that using a relatively powerful and expensive general purpose processor to handle keyboard inputs can be slower than dedicated logic for the keyboard, which would both be simpler and cheaper. However, using the processor gives people the ability to easily customize the keyboard, and also pushes the problem of “programming” the keyboard from hardware into software, which reduces the cost of making the keyboard. The more expensive chip increases the manufacturing cost, but considering how much of the cost of these small-batch artisanal keyboards is the design cost, it seems like a net win to trade manufacturing cost for ease of programming.

...

If you want a reference to compare the kindle against, a moderately quick page turn in a physical book appears to be about 200 ms.

https://twitter.com/gravislizard/status/927593460642615296
almost everything on computers is perceptually slower than it was in 1983
https://archive.is/G3D5K
https://archive.is/vhDTL
https://archive.is/a3321
https://archive.is/imG7S

linux terminals: https://lwn.net/Articles/751763/
techtariat  dan-luu  performance  time  hardware  consumerism  objektbuch  data  history  reflection  critique  software  roots  tainter  engineering  nitty-gritty  ui  ux  hci  ios  mobile  apple  amazon  sequential  trends  increase-decrease  measure  analysis  measurement  os  systems  IEEE  intricacy  desktop  benchmarks  rant  carmack  system-design  degrees-of-freedom  keyboard  terminal  editors  links  input-output  networking  world  s:**  multi  twitter  social  discussion  tech  programming  web  internet  speed  backup  worrydream  interface  metal-to-virtual  latency-throughput  workflow  form-design  interface-compatibility  org:junk  linux 
july 2019 by nhaliday
How much would it cost to crawl 1 billion sites using rented AWS servers/bandwidth? - Quora
The best way IMHO to do such a crawl would be to recruit a group of say 100-1000 of your friends, and their friends, and write a simple distributed app running in background on their machines, when they sit idle or are lightly used. This way you will be amortizing their monthly broadband bills, with their monthly quotas (e.g. Comcast 250GB) largely unused anyway. I would think that you can get dozens of Mbps of cross bandwidth in such a network, which could do the job in a matter of months.

BTW, if you really meant 1 billion sites, as opposed to pages, multiply the above bills by 100x (average number of pages per site).

--

There is no need for you to crawl. Someone has already done the job for you. Common Crawl https://commoncrawl.org/ is a periodic crawl of the internet, and the results are stored in Amazon S3. You can directly use the results without any charge for any kink of analysis you want to do.
q-n-a  qra  quixotic  programming  engineering  search  minimum-viable  internet  web  huge-data-the-biggest  howto  init  advice  money  cost-benefit  strategy  scaling-tech  system-design  move-fast-(and-break-things) 
may 2019 by nhaliday
:feed v1 - /fora/posts/~2017.4.12..21.14.00..fe17~
The goal of this demo was to show that building a Twitter replacement actually isn't that hard at all; and it can be done almost entirely on the frontend. As shown, you don't even have to use React/Redux. But that's probably the way to go if you want to build the real thing.
techtariat  urbit  software  decentralized  twitter  social  internet  web  programming  tutorial  project  gnon 
april 2017 by nhaliday
« earlier      
per page:    204080120160

Copy this bookmark:





to read