I think a big reason that old-school server-side rendering (i.e., templates) isn't popular anymore is that templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, and you get real function signatures for all your UI components. This makes it way easier to write reusable components, because you can specify the arguments, and write regular unit tests against them, etc.
With most templating languages, there is no defined function signature (with arguments and types specified), so you get to read through the template to figure out what data to pass in. This makes it very hard to make things reusable. And similarly, templating languages are often some bizarre, janky custom language with pipes and stuff.
At a previous employer, we actually solved this problem. We implemented a pattern that gave us real typed interfaces for UI components rendered with templates on the server. We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did, although not in the browser.
I recently started a side-project in javascript for the first time in years, and was surprised to discover that there is apparently no modern open-source library for rendering server side components, other than rendering react on the server of course. Your options are basically react or using some shitty templating language. I went with react.
1: When I say react, please understand it to mean any of the nice modern frontend libraries, like react, vue (is this still a thing?), svelte, etc.
I find the popularity of JSX-style templating really surprising.
<div>
<h1>Conditional Display and Looping in JSX</h1>
<ul>
{this.state.items.map(item => (
item.show ? <li key={item.id}>{item.name}</li> : null
))}
</ul>
</div>
That seems like such an unintuitive way of implementing loops and if statements!
I helped design the Django template language, where the above would look like this instead:
<div>
<h1>Conditional Display and Looping in Django Template</h1>
<ul>
{% for item in items %}
{% if item.show %}
<li>{{ item.name }}</li>
{% endif %}
{% endfor %}
</ul>
</div>
I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.
Maybe because you’re thinking of it like a template language. It is not. It is JavaScript through and through. And mapping over an array is quite idiomatic. So are ternary operators. If you really prefer you can pop that out into a for loop with a full-blown if statement, but that’s not very common—at least not in React.
I think the long history of being served over the wire drove the community to prefer shorter, more terse code.
Here's my perspective, as someone who's done a lot of JavaScript app development and recently onboarded into a Django app:
- JSX composes normal JavaScript expressions. That means that every operator/function/etc I have access to in JavaScript is also available within JSX. With Django templates, I need to create a custom tag or filter.
- JSX desugars to a normal JavaScript expressions. That means I can store it in a variable, return it from a function, etc.
- JSX returns structured data rather than a string. That means it can be used to support output formats other than text. This isn't so much of an advantage for web dev, where you want a string, but it's a "least worst" situation if you use React Three Fiber, React Native, etc.
- The aforementioned type safety is nice!
On the other hand, I imagine Django templates are significantly more welcoming if you're more familiar with HTML than JavaScript.
By the way, the ternary in your JSX example can be removed by filtering the array:
<div>
<h1>Conditional Display and Looping in JSX</h1>
<ul>
{this.state.items
.filter(item => item.show)
.map(item => <li key={item.id}>{item.name}</li>)}
</ul>
</div>
I love Django. I will be the first to throw spears at modern JS dev. Django's template language works well for simple cases. By design, it is restrictive compared to a proper programming language. I find this to be problematic.
For things beyond if/for statements, the solution is usually to write custom tags in a DSL that I have a hard time grokking. With JS, you can write arbitrary logic in an imperative language.
If you do proper server side rendering you wouldnt even have if statements in the template. your backend code should have divided everything into correct buckets for you to iterate through them. application logic shouldnt be in your view.
I wonder why JSX didn't just go all the way with the language (arrays and objects) to represent html tags and attributes, it would have cut the noise by 50%.
> templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript,
I've run into this same issue when developing a DSL for generating language bindings and doing data serialization. Not having compile-time type safety is such a pain.
So I'm extending the language to feature statically typed string templates as well. It currently targets (generates) C++, but I'll add other language targets in the future.
It's still a work in progress but I just flipped the repository public in case you want to follow along as I work: https://github.com/dpemmons/typedef
I've still found nothing that can match up to what Wicket was doing 10+ years ago. Your are self-contained, and know how to render their own markup. Any "templates" live with the components and are tightly coupled to them. Control flow lives in code and code alone; your markup specifies ids where your code can attach components, but there's no way for your markup to call back into your code, so you avoid spaghetti. It's wonderful.
"Moderately interactive interfaces" describes most web applications - stuff like gmail, airbnb, facebook, youtube, reddit, etc. Even for things like Mapbox or Observable that require a high performance core, React is the best choice for building the surrounding chrome.
Whether HTML/CSS/DOM was a good technology to use for building these types of applications is another question but we're stuck with it now either way.
Sometimes I wonder how many criticisms of JavaScript frameworks are driven by a nostalgia for an internet that no longer exists. Not this post per se, but many seem to forget why the industry landed on React in the first place.
I'm pushing GridWhale, which is a completely server-side platform, but the trick is that we remote the UI to the browser (think X-terminal but at the granularity of UI controls).
The nice thing about this is that your program doesn't have to worry about the front-end/back-end split. You just write as if you had full control over the machine, and the platform takes care of remoting to the browser.
EDIT: 15 minutes after this post, I've already had 20 clicks, and each click spawns a new server-side program. And it's just running on a little 4-core Xeon PC under my desk.
I'll post again when it all falls over!
EDIT2: Not as bad as I feared/secretly hoped. After an hour there are about 100 program instances, but obviously most are idle, so they don't take up too many resources. The compute process is only using 32 MB of working memory, so we have plenty of room for more. My guess is we could easily hit 1,000 program instances. Of course, this kind of traffic is trivial for a standard web server--we're talking something like 50 requests per minute. But you gotta start somewhere!
EDIT3: Spoke too soon! Finally crashed. Although not from traffic but from a bug, so now I have something to debug.
Why is every clickable element implemented as a div? You lose out on a lot of native things, like changing mouse cursor on hover, keyboard navigation for users with special accessibility needs, etc.
Folks, this is exactly what htmx (and Phoenix LiveView and Laravel Livewire and Rails Hotwire) solves. OP was almost there but couldn't quite articulate this niche. Which is OK, we have the benefit of hindsight now.
Try htmx. It will blow you away with its simplicity compared to (today's) React. My personal recommendation: try it with dream-html, a library I wrote for expressing HTML directly in the language: https://github.com/yawaramin/dream-html (or some similar library).
IMO, React's popularity has little to do with productivity in the context of what other tools are available (many of which we never even heard about). It's mostly about network effects. Popularity is the primary reason why companies use React as it suppresses developer salaries by making devs more interchangeable. It creates liquidity in the market for dev talent due to shared familiarity. Had the similar kinds of network effects existed around a different, better framework, all companies would be much more productive. And even then, I would say the benefits of network effects are greatly exaggerated.
Also, it's important to note that many developers who are good at putting together functionality in React quickly aren't necessarily good developers in the more general sense (in the long run). This can cause problems later in terms of security, maintainability, performance, hiring (due to complexity of the software itself scaring off prospective hires; familiarity with the stack isn't everything) also there are concerns about operating costs, vendor lock-in and scalability.
HTML and DOM lack too many common and expected GUI idioms (see link). If our standards had those, then we wouldn't need to use clunky stuff like React to emulate them. We need a state-ful GUI markup language standard.
HTML and DOM lack those because that’s not what they’re for. Stop trying to build desktop and mobile applications using a document markup language. If you’re building a client-side application, use the platforms’ native languages and technologies.
It should be possible to port a modern browser engine to an average new PC from 1995 and use almost the entire web, over 33.6K dialup, with good performance—modulo high-res/quality images, audio, and video. That we’ve allowed the web to get away from this says way more about web development than technology.
> HTML and DOM lack those because that’s not what they’re for. Stop trying to build desktop and mobile applications using a document markup language. If you’re building a client-side application, use the platforms’ native languages and technologies.
People love to say this here but I've never seen a good reason for it. Web technologies are far and away the best I've used for creating user interfaces. And there are significant advantages to building on the web. How else can someone jump into collaborating on a document or a picture with me — without installing anything — after receiving only a short text?
There is a very clear market desire for desktop style apps delivered through browsers.
Users love it. Users hate installers. Users hate updates. Webpages have neither.
Companies love it. Makes subscription access apps easy to sell. Makes it easy to target all platforms and keep costs low.
Seems very flippant to completely dismiss the dominant trend in this industry over the past 20 years as simply wrong.
I agree the technologies are not well suited to this purpose which is why I avoid frontend at all costs. But powerful web apps generate a lot of value for a lot of people, myself included.
The hoops that need to be jumped to get a web version of a simple tableview/datagrid with sortable rearrangeable resizable columns and recycled rows like desktop UI toolkits have had since the dawn of time are a bit nuts.
We have started our platform before React, but ran into similar issues. Luckily they are surmountable. Many of them can be solved by inlining the CSS and basic JS into the page when the session cookie is missing. Then install a service worker to cache each inlined file and show them next time they are requested.
There are nuances like rewriting URLs in the CSS to be relative to the page, and then replacing them back in the service worker before caching the result.
But you don’t need static sites. You can use CDNs to cache your pages and make them effectively static. Use AJAX or ESI / SSI to include stuff that depends on the session cookie.
I very much agree about the point about Server Side Rendering. I don't like it. There are some fundamental differences between front end and back end which should never be neglected. Critically, considerations related to authentication and access control but also relevant in terms of performance (e.g. caching and bundling as described in the article SSR is just a bad idea in practice; I've never seen a project make good use of it)...
Readit News
With most templating languages, there is no defined function signature (with arguments and types specified), so you get to read through the template to figure out what data to pass in. This makes it very hard to make things reusable. And similarly, templating languages are often some bizarre, janky custom language with pipes and stuff.
At a previous employer, we actually solved this problem. We implemented a pattern that gave us real typed interfaces for UI components rendered with templates on the server. We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did, although not in the browser.
I recently started a side-project in javascript for the first time in years, and was surprised to discover that there is apparently no modern open-source library for rendering server side components, other than rendering react on the server of course. Your options are basically react or using some shitty templating language. I went with react.
1: When I say react, please understand it to mean any of the nice modern frontend libraries, like react, vue (is this still a thing?), svelte, etc.
I helped design the Django template language, where the above would look like this instead:
I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.I think the long history of being served over the wire drove the community to prefer shorter, more terse code.
- JSX composes normal JavaScript expressions. That means that every operator/function/etc I have access to in JavaScript is also available within JSX. With Django templates, I need to create a custom tag or filter.
- JSX desugars to a normal JavaScript expressions. That means I can store it in a variable, return it from a function, etc.
- JSX returns structured data rather than a string. That means it can be used to support output formats other than text. This isn't so much of an advantage for web dev, where you want a string, but it's a "least worst" situation if you use React Three Fiber, React Native, etc.
- The aforementioned type safety is nice!
On the other hand, I imagine Django templates are significantly more welcoming if you're more familiar with HTML than JavaScript.
By the way, the ternary in your JSX example can be removed by filtering the array:
For things beyond if/for statements, the solution is usually to write custom tags in a DSL that I have a hard time grokking. With JS, you can write arbitrary logic in an imperative language.
Yeah exactly, which is why I always recommend DSLs that embed HTML directly in the language. E.g. https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html
They make writing HTML a breeze with the full power of the programming language available.
> We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did
Dan Abramov is not the original creator of React. That was Jordan Walke: https://www.youtube.com/watch?v=GW0rj4sNH2w
So I'm extending the language to feature statically typed string templates as well. It currently targets (generates) C++, but I'll add other language targets in the future.
It's still a work in progress but I just flipped the repository public in case you want to follow along as I work: https://github.com/dpemmons/typedef
Whether HTML/CSS/DOM was a good technology to use for building these types of applications is another question but we're stuck with it now either way.
The nice thing about this is that your program doesn't have to worry about the front-end/back-end split. You just write as if you had full control over the machine, and the platform takes care of remoting to the browser.
Here's the reference manual for it: https://gridwhale.com/program.hexm?id=GCJ5TL7Z&file=GCJ5TL7Z...
[Be gentle--this is implemented as a GridWhale program and everything is still a prototype.]
And here's a post I wrote on the motivation: https://medium.com/@gridwhale/rise-of-the-hyperplatforms-d4a...
EDIT: 15 minutes after this post, I've already had 20 clicks, and each click spawns a new server-side program. And it's just running on a little 4-core Xeon PC under my desk.
I'll post again when it all falls over!
EDIT2: Not as bad as I feared/secretly hoped. After an hour there are about 100 program instances, but obviously most are idle, so they don't take up too many resources. The compute process is only using 32 MB of working memory, so we have plenty of room for more. My guess is we could easily hit 1,000 program instances. Of course, this kind of traffic is trivial for a standard web server--we're talking something like 50 requests per minute. But you gotta start somewhere!
EDIT3: Spoke too soon! Finally crashed. Although not from traffic but from a bug, so now I have something to debug.
Again, though, I want that to be handled by the platform, as much as possible, so that devs don’t have to.
Hm. Custom SemVer, custom language, custom GUI framework? It's a lot.
Folks, this is exactly what htmx (and Phoenix LiveView and Laravel Livewire and Rails Hotwire) solves. OP was almost there but couldn't quite articulate this niche. Which is OK, we have the benefit of hindsight now.
Try htmx. It will blow you away with its simplicity compared to (today's) React. My personal recommendation: try it with dream-html, a library I wrote for expressing HTML directly in the language: https://github.com/yawaramin/dream-html (or some similar library).
Also, it's important to note that many developers who are good at putting together functionality in React quickly aren't necessarily good developers in the more general sense (in the long run). This can cause problems later in terms of security, maintainability, performance, hiring (due to complexity of the software itself scaring off prospective hires; familiarity with the stack isn't everything) also there are concerns about operating costs, vendor lock-in and scalability.
https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
It should be possible to port a modern browser engine to an average new PC from 1995 and use almost the entire web, over 33.6K dialup, with good performance—modulo high-res/quality images, audio, and video. That we’ve allowed the web to get away from this says way more about web development than technology.
People love to say this here but I've never seen a good reason for it. Web technologies are far and away the best I've used for creating user interfaces. And there are significant advantages to building on the web. How else can someone jump into collaborating on a document or a picture with me — without installing anything — after receiving only a short text?
Users love it. Users hate installers. Users hate updates. Webpages have neither.
Companies love it. Makes subscription access apps easy to sell. Makes it easy to target all platforms and keep costs low.
Seems very flippant to completely dismiss the dominant trend in this industry over the past 20 years as simply wrong.
I agree the technologies are not well suited to this purpose which is why I avoid frontend at all costs. But powerful web apps generate a lot of value for a lot of people, myself included.
There are nuances like rewriting URLs in the CSS to be relative to the page, and then replacing them back in the service worker before caching the result.
https://community.qbix.com/t/qbix-websites-loading-quickly/2...
But you don’t need static sites. You can use CDNs to cache your pages and make them effectively static. Use AJAX or ESI / SSI to include stuff that depends on the session cookie.