3 ms·

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document.createDocumentFragment. These are perfect 1:1 browser APIs that allow you to do everything you've ever wanted, there's no magic, they call directly into the browser engine to give you what you need. If you want to increase performance, start first by measuring everything. Time to first byte. Time to DOMContentLoaded. The page onload event. window.performance timings; do real user monitoring, not TODO app benchmarks on the latest framework flavor of the week. The entire web community needs a healthy dose of pragmatism. But it's okay, it gives me extra work. I really enjoy doing freelance performance work and telling everyone which code/library/framework is to blame for performance issues and rewriting everything so simply. Show people what works and you'll find they shut up real quick.

randomsofr 10y ago
> Generate the markup on the server and send it down to the client! You are so smart, how come no one thought about that before.
- hrayr 10y ago
  Obviously they did, hence the "It's post-modern web development." No need for snark.
- deleted 10y ago
  [deleted]
paulddraper 10y ago
> Generate the markup on the server and send it down to the client! It's post-modern web development. Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. There are solutions that use the same templating server and client side, but they are far from pedestrian.
- mi100hael 10y ago
  > Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. Strongly disagree that there's any actual improvement on UX. Plenty of sites like GitLab, GitHub, YouTube, etc. insist on using JS to load what could be entirely separate pages, but instead leave the user with some slow, hand-rolled progress bar on the top of the page. For sites doing nearly-full-page refreshes, a server pre-rendering is going to be faster. For sites doing smaller content-level changes, there's no reason something like turbolinks, pjax, or regular old ajax/DOM manipulation can't be used, which is almost always faster.
  - paulddraper 10y ago
    > regular old ajax/DOM manipulation Yes, exactly. There's no way to do this on the server, so anything you do with DOM will be split in to separate server and client side worlds. For example, https://github.com/git/git/compare/master...next https://github.com/git/git/compare/master...next will show you "base: master, compare: next" when you load it. But I can use the dropdown + autocomplete to update that value. That value is set both on page load, and also (justifiably, IMO) dynamically. Multiply that by a hundred bespoke things and you yearn for less server client spaghetti.
  - chiefalchemist 10y ago
    Furthermore, and pardon me if this is stating the obvious, but improving the underlying technology for UX does not necessarily lead to an actual improved UX. Look around. There continues to plenty of misused (?) technology (i.e., crappy user experiences.) In short, technology isn't the problem with most UXs.
fleshweasel 10y ago
Every tool for its job. If you have serious dynamic behavior and you try to handroll it yourself, you risk either low maintainability and bugs in your bespoken optimized DOM manipulation algorithm or doing things in fundamentally inefficient ways. That said, people should be cautious about taking on new dependencies, and definitely need to take an evidence-based approach to performance optimization.
hinkley 10y ago
Vue 2.0 claims server side rendering support, so you should be covered on initial page load. After that it's progressive enhancement. For complex pages, AJAX is going to pay off in the long run. It's a matter of whether you can avoid having to implement and debug your entire app 2-3 times in order to get that behavior. That's the (mostly undelivered) promise of Node. But at this rate web assembly may server code written in more robust languages to find its way into the client and take market share. As someone who grew up on the advantages of static code analysis, I look forward to getting some of that power back.

randomsofr 10y ago

> Generate the markup on the server and send it down to the client! You are so smart, how come no one thought about that before.

hrayr 10y ago
Obviously they did, hence the "It's post-modern web development." No need for snark.
deleted 10y ago
[deleted]

paulddraper 10y ago

> Generate the markup on the server and send it down to the client! It's post-modern web development. Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. There are solutions that use the same templating server and client side, but they are far from pedestrian.

mi100hael 10y ago
> Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. Strongly disagree that there's any actual improvement on UX. Plenty of sites like GitLab, GitHub, YouTube, etc. insist on using JS to load what could be entirely separate pages, but instead leave the user with some slow, hand-rolled progress bar on the top of the page. For sites doing nearly-full-page refreshes, a server pre-rendering is going to be faster. For sites doing smaller content-level changes, there's no reason something like turbolinks, pjax, or regular old ajax/DOM manipulation can't be used, which is almost always faster.
- paulddraper 10y ago
  > regular old ajax/DOM manipulation Yes, exactly. There's no way to do this on the server, so anything you do with DOM will be split in to separate server and client side worlds. For example, https://github.com/git/git/compare/master...next https://github.com/git/git/compare/master...next will show you "base: master, compare: next" when you load it. But I can use the dropdown + autocomplete to update that value. That value is set both on page load, and also (justifiably, IMO) dynamically. Multiply that by a hundred bespoke things and you yearn for less server client spaghetti.
- chiefalchemist 10y ago
  Furthermore, and pardon me if this is stating the obvious, but improving the underlying technology for UX does not necessarily lead to an actual improved UX. Look around. There continues to plenty of misused (?) technology (i.e., crappy user experiences.) In short, technology isn't the problem with most UXs.

fleshweasel 10y ago

Every tool for its job. If you have serious dynamic behavior and you try to handroll it yourself, you risk either low maintainability and bugs in your bespoken optimized DOM manipulation algorithm or doing things in fundamentally inefficient ways. That said, people should be cautious about taking on new dependencies, and definitely need to take an evidence-based approach to performance optimization.

hinkley 10y ago

Vue 2.0 claims server side rendering support, so you should be covered on initial page load. After that it's progressive enhancement. For complex pages, AJAX is going to pay off in the long run. It's a matter of whether you can avoid having to implement and debug your entire app 2-3 times in order to get that behavior. That's the (mostly undelivered) promise of Node. But at this rate web assembly may server code written in more robust languages to find its way into the client and take market share. As someone who grew up on the advantages of static code analysis, I look forward to getting some of that power back.