91–100 of 137 posts
Earlier quoted context omitted.
Server side rendering has one big advantage - it's fast. Client side rendering frameworks may be easier and sexier, but serving html is always going to be faster.
If you need custom data in the page on a per request basis then SSR is usually the fastest method to generate the final HTML but it isn't the fastest method of getting something on the user's screen. Its "time to render" that counts, and that means doing as little work as possible to send something to the user. Serving the same static, "prerendered" HTML file with no customization to every user is always going to be…
Just seeing the skeleton of the web page doesn't make it fast. The page will be unresponsive for longer and will visually stutter while rendering. It's a much worse user experience imo.
> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. JSX is fine, the real power is building your HTML in pure JavaScript. I'll nev…
I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far.
There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string.
1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...
Earlier quoted context omitted.
I believe in a mix of these two. It's going to be server rendered JS app that will download itself on the background and install itself as a PWA. The best of both worlds.
That is what we have today.
Earlier quoted context omitted.
I was initially a pretty big fan of JSX, but after using Vue it just feels like extra overhead. In my experience, parsing complex JSX in my head results in constant context switches depending on whether the specific parts I'm looking at are closer to HTML or closer to JS. And for the tasks I've generally been doing at work, there rarely seems to be a good reason to combine the two. If I'm trying to fix a bug for exam…
I keep hearing all of these "Vue just makes more sense than React" converts, and I'm baffled. I recently did some Vue after doing React for a few years, and it felt like a major step backward. It felt very JSP - here was a different syntax that was HTML except when it chose not to be - managing data was done in a custom expression language, and I was left to figure out what scope a given value had. Need to loop somet…
If you look at the job market around here, it’s 70% react and 30% angular with almost no Vue jobs right now. The ones listing Vue as a requirement almost all use React, who are willing to retrain Vue developers. It used to be more evenly distributed between angular and react, but it would seem that react won the front end war.
This is HN though, it’s not very representative of what goes on outside of Silicon Valley. Right now there isn’t a single Rust job in my country as an example, at least not in any of our major jobbanks. There are thousands of PHP jobs though. But if you took HN to be representative for languages, you’d think it was the opposite.
Designers already suck so badly at HTML & CSS that getting them to do any wastes more time than it saves. They don't need to be let near any other implementation tech either, not Android layouts, not iOS storyboards, and not React.
Designers don't really want to do implementation either, why make them learn a bunch of things they don't care about?
Earlier quoted context omitted.
I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.
>I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers , I can't see how the industry will migrate back to server-side rendering in 3 years. The unavoidable technical issue is the round-trip latency of the network. The same delays…
Things I get from designers: 1. Wireframes 2. Layouts (bitmaps) 3. Assets (fonts, images) (4. Occasionally, interactive prototypes made with designer-friendly tools.) Designers already suck so badly at HTML & CSS that getting them to do any wastes more time than it saves. They don't need to be let near any other implementation tech either, not Android layouts, not iOS storyboards, and not React. Designers don't reall…
That's first off an assumption, although I do see where you're coming from. The main thing is speeding up and removing the middle man - why separate design and implementation if you can do them at the same time? The tools are there.
So, if you read between the lines, React was basically built for a better "Like" button according to Dan's blog post here: https://overreacted.io/the-elements-of-ui-engineering/ Hmm...
React was written for Instagram. Nothing to do with Facebook's Like button.
Instagram was the first time it was used to drive the whole page (rather than a small widget).
Earlier quoted context omitted.
I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.
>I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers , I can't see how the industry will migrate back to server-side rendering in 3 years. The unavoidable technical issue is the round-trip latency of the network. The same delays…
So is downloading an entire app when you only want to read one page.