Re:Ask HN: Why did Frontend development explode in complexity?
by Terretta on Monday January 02, 2023 @05:52PM
(#34224837)
My first CTO job working for someone else in late 90s, I got the job by showing them a web-based re-implementation of Outlook that leveraged POP/IMAP server-side. Form and functionality was essentially indistinguishable from the Windows app.
This was Outlook 8, in 1999, for Netscape and IE 4.
Needless to say, I don't really buy the current complexity trends either above or below the waterline, and certainly agree with your #3.
If you couldn't build a 12 factor app using, say, HTML4/5, AJAX, and PHP, Rails, ASP.net, or (ahem) ColdFusion and a SQL server, that works on, say, 3+ webservers and 2+ DB servers, I'd argue "architects" have no business "architecting" an application leveraging today's SPA stacks on K8s. They probably don't understand enough to know what things are made of, how they work, or the characteristics likely to need support under usage.
These are the client-side building blocks:
- HTML (or XHTML) and CSS for presentation
- The Document Object Model (DOM) for dynamic display of and interaction with data
- JSON or XML for the interchange of data (optional XSLT for XML manipulation)
- The XMLHttpRequest object for asynchronous communication
- JavaScript to bring these technologies together
Server-side, the know-how to:
- manage stateless load balancing and parallelism;
- handle HTTP verbs, HTTP return codes, and XML or JSON;
- use pooled connections to a SQL cluster;
- and leverage something like memcache or similar to avoid using those SQL cluster connections except as write through cache.
A tech stack built like this can handle a billion hits a month of dynamic e-commerce traffic (products, carts, accounts, purchases) with a hardware layer 7 switch (load balancer and SSL), 4 Pentium IIIs running nginx and PHP, and a pair of SQL servers.
This was Outlook 8, in 1999, for Netscape and IE 4.
Needless to say, I don't really buy the current complexity trends either above or below the waterline, and certainly agree with your #3.
If you couldn't build a 12 factor app using, say, HTML4/5, AJAX, and PHP, Rails, ASP.net, or (ahem) ColdFusion and a SQL server, that works on, say, 3+ webservers and 2+ DB servers, I'd argue "architects" have no business "architecting" an application leveraging today's SPA stacks on K8s. They probably don't understand enough to know what things are made of, how they work, or the characteristics likely to need support under usage.
These are the client-side building blocks:
- HTML (or XHTML) and CSS for presentation
- The Document Object Model (DOM) for dynamic display of and interaction with data
- JSON or XML for the interchange of data (optional XSLT for XML manipulation)
- The XMLHttpRequest object for asynchronous communication
- JavaScript to bring these technologies together
Server-side, the know-how to:
- manage stateless load balancing and parallelism;
- handle HTTP verbs, HTTP return codes, and XML or JSON;
- use pooled connections to a SQL cluster;
- and leverage something like memcache or similar to avoid using those SQL cluster connections except as write through cache.
A tech stack built like this can handle a billion hits a month of dynamic e-commerce traffic (products, carts, accounts, purchases) with a hardware layer 7 switch (load balancer and SSL), 4 Pentium IIIs running nginx and PHP, and a pair of SQL servers.
A billion hits a month.