←back to thread

XSLT – Native, zero-config build system for the Web

(github.com)
392 points _kush | 2 comments | 27 Jun 25 05:00 UTC | HN request time: 0.423s | source
Show context
p0w3n3d ◴[27 Jun 25 07:12 UTC] No.44394429[source]▶
Ok, so it might be a long shot, but I would say that

1. the browsers were inconsistent in 1990-2000 so we started using JS to make them behave the same

2. meanwhile the only thing we needed were good CSS styles which were not yet present and consistent behaviour

3. over the years the browsers started behaving the same (mainly because Highlander rules - there can be only one, but Firefox is also coping well)

4. but we already got used to having frameworks that would make the pages look the same on all browsers. Also the paradigm was switched to have json data rendered

5. at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory.

Why do I say that? Recently we started working on a migration from a legacy system. Looks like 2000s standard page per HTTP request. Every action like add remove etc. requires a http refresh. However it works much faster than our react system. Because:

1. Nowadays the internet is much faster

2. Phones have a lot of memory which is wasted by js frameworks

3. in the backend all's almost same old story - CRUD CRUD and CRUD (+ pagination, + transactions)

replies(4): >>44394607 #>>44394696 #>>44395199 #>>44395273 #
1. bob1029 ◴[27 Jun 25 09:15 UTC] No.44395199[source]▶
> at the current technology we could cope with server generated old-school web pages because they would have low footprint, work faster and require less memory

I've got a .NET/Kestrel/SQLite stack that can crank out SSR responses in no more than ~4 milliseconds. Average response time is measured in hundreds of microseconds when running release builds. This is with multiple queries per page, many using complex joins to compose view-specific response shapes. Getting the data in the right shape before interpolating HTML strings can really help with performance in some of those edges like building a table with 100k rows. LINQ is fast, but approaches like materializing a collection per row can get super expensive as the # of items grows.

The closer together you can get the HTML templating engine and the database, the better things will go in my experience. At the end of the day, all of that fancy structured DOM is just a stream of bytes that needs to be fed to the client. Worrying about elaborate AST/parser approaches when you could just use StringBuilder and clever SQL queries has created an entire pointless, self-serving industry. The only arguments I've ever heard against using something approximating this boil down to arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly.

replies(1): >>44396470 #
2. chriswarbo ◴[27 Jun 25 13:01 UTC] No.44396470[source]▶
> arrogant security hall monitors who think developers cant be trusted to use the HTML escape function properly.

Unfortunately, they're not actually wrong though :-(

Still, there are ways to enforce escaping (like preventing "stringly typed" programming) which work perfectly well with streams of bytes, and don't impose any runtime overhead (e.g. equivalent to Haskell's `newtype`)