Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

Post reply on HN
Print view View original

421–430 of 522 posts

Re: You probably don't need a single-page app

#421

Post by callalex »

nicoburns wrote: post #349
dkarl wrote: post #278

Earlier quoted context omitted.

I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. It was nice and would still be nice if browser caching meant a site still worked well over a bad connection. But you can be browsing around a "static" site and hit the back button and be stuck staring at an empty or partly rendered page waiting f…

You could also run server-rendering with a service worker. There's nothing about a service worker that means it only works with SPAs. It basically just gives you control over caching behaviour...

You can also control caching behavior by just setting the headers correctly in the first place. I think the takeaway here is that sometimes SPA frameworks make the behavior “just work” in more cases when the developer doesn’t put any thought into correct cache handling.

Re: You probably don't need a single-page app

#422

Post by kadendogthing »

a_wild_dandan wrote: post #317
kadendogthing wrote: post #293

Yes you actually do. At the very least you should build your web app with technology that makes it fairly trivial to move over to an SPA. MVC is a mistake. Read that again. MVC is a mistake. It's not a good paradigm to write web applications in. SPA's are not complicated. They do not take longer to build. They defacto are often way more responsive than any server side monolith that gets built. Because developers who…

I really wish I could upvote this twice. Tacking on features to a traditional MVC app causes orders of magnitude more technical debt and buggy, tightly-coupled, unmaintainable or extensible spaghetti code. React et al. didn't pass through a membrane from another reality for the sole purpose of annoying devs with more stuff to learn -- they're elegant, powerful solutions to the rapid growing pains and requirements of…

Yep. Developers take their choice and then externalize all the costs to the company; even though the company has put an immense amount of trust and financial power in them.

It's actually absurdly disgusting once you run the numbers. I've directly compared projects before and after over a 1-2 year period and the devs claiming that these "MVC" apps are better for users, the company, or anyone else besides themselves are actually arrogantly delusional. They write these apps, and either leave or then sit there in the company and blame everyone else but themselves.

But hey, at least the problem exists. It allowed me to make a ridiculous amount of money and invest it wisely. shrug

Re: You probably don't need a single-page app

#423

Post by rajangdavis »

I used to love SPA's but, in my experience, the most poorly organized SPA code is severely more complex than poorly organized server side rendered app code.

With SPA's, you're usually dealing with some build system, a variety of dependencies, and a swathe of design patterns. At worst, you have everything located in a single file which has all of the above across tens of thousands of lines.

With server side rendered code, you are (at worst) following someone's code that didn't follow the correct separation of concerns. At worst, the spaghetti code will be within a couple thousands of lines of code.

I had a project recently where I ran into both of the above scenarios and I would prefer to debug poorly written server-side code than poorly written SPA code. It's night and day in terms of complexity.

Re: You probably don't need a single-page app

#424

Post by unclebucknasty »

save_ferris wrote: post #26

This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…

The hybrid approach sounds good, but I've found it frequently non-trivial to pull off in practice. In my experience, you have to be really thoughtful about what and how much you make dynamic.

For instance, if you start to rely heavily on dynamic capabilities to render key components, such as detail views/overlays, then you have to start reasoning about making them accessible via their own URL to enable direct access, browser reloads, sharing, etc. By the time you've done that, you've started duplicating browser functionality via routing, history, etc, and generally working to create an app that coexists peacefully within an app. In other words, you quickly move into SPA territory and all that that entails.

But, if that causes you to be more conservative about sprinkling in dynamic capabilities, then you're really much closer to an old school SSR app and not realizing a lot of the purorted benefits of a SPA, or much else beyond the old school AJAX approaches. Not to say that's useless, but we've long since been down that road, and it doesn't represent any new thinking.

So, it's just hard to find balance there. In most cases, you're really either a SPA or you're not.

Re: You probably don't need a single-page app

#425

Post by Theodores »

paultopia wrote: post #413
Theodores wrote: post #393

Earlier quoted context omitted.

Fun is fine, however, it can distract from the task in hand. Accessibility is queen. No criticisms here, just observations on what gets missed generally by people who go too far along the build tools path and overlook things like document structure along the way. The actual document could benefit from HTML5 niceties such as more accessible elements than 'div' and the table elements. Table has its place but the world…

I certainly think most of this stuff is right. I've been meaning to go through and make the whole thing more semantic, just haven't gotten around to it yet. So I really appreciate your thoughts, most of that stuff is going on the todo list. (Maybe not the SVG stuff; the way I do the SVGs is a lot more convenient for design flexibility.) (But, to the original point, all of those great suggestions are totally compatibl…

You have some neat SVG icons already, I urge you to refactor them so they are not 'design assets' but fully fledged and fully yours. The exercise of doing them will give you a new string to your bow for solving visual problems. SVGs are like LEGO but a lot more fun, so long as you play with them properly rather than just use ready mades. So same as LEGO then...

Once you have done a small set, e.g. your dozen ones, you will be able to have more of this design flexibility, plus you will discover that creative drawing is not actually what usually goes on with Adobe style applications but goes up to a whole new level when you do SVG - because it is code.

If embedding SVGs has cool factor, you can make them fully presentational by putting them in CSS custom variables and then using those custom variables in pseudo elements. This is how I do external links, download links etc.

The only downside is that you can't radically change the colours on mouseover etc.

https://css-tricks.com/solved-with-css-colorizing-svg-backgr...

Also Google Lea Verou if you want to take pride in your SVGs.

To add to your refactoring list, have one stylesheet with everything that changes depending on screen size set as a CSS variable. So at the top have a big list of 'things that change' and the defaults for any screen size. So if you have margin size for instance, set it there for mobile, then, have a media query below the base list of css variables and then update the variable in the media query block. Try to have zero CSS rules in the media queries, have it exclusively setting CSS variables.

If you do it this way then you can tell from the CSS where something changes because it has a CSS variable. Done the old way with chunks of CSS in media queries you can't see at a glance if there is more than one place a given rule is defined, done the new way it can be maintained a lot easier.

A final thing - you have a lot of table information and CSS grid is absolutely excellent for showing tables. You don't have to explicitly write out all cells, unlike with tables, you can make things with a given class or other attribute go in the correct column keeping your source data semantically neat even if some records do not contain all the fields. Rather than classes you could mark up your 'papers' and references with things like 'cite' tags, 'address' tags or whatever is bestest HTML5 and have these flow into the correct columns without using classes or tables, just a succinct css grid declaration and that is it. The grid layout is much better for speed so you will like it.

Re: You probably don't need a single-page app

#426

Post by wolco »

paultopia wrote: post #262

Unpopular opinion: I love SPAs for simple stuff. Yes, they're a ton of work. But the feel of them is unparalleled. I have my personal home page written as a Vue SPA. It was a silly amount of work to get together, and not everything works perfectly. BUT: it moves like a rocket. I pre-render the simple front page, so initial load is nearly instantaneous (especially with cloudflare &c), and, by the time a visitor finish…

The site is very simple (6 icons links on the homepage and just plain text on the subpages) this could have been done as a static site quicker with even faster rendering. As a bonus you may get external traffic to your cv page if it was separate.

I do like the big icons on the homepage and I'll just say great job.

You used an spa because it was easier for you and that makes sense. One npm call and oje starter kit can get you a finished emtpy app. Doing it in plain html should be even easier but we lack the all-in-one modern tool it seems.

Re: You probably don't need a single-page app

#427

Post by mehrdadn »

chalupa-man wrote: post #404
krferriter wrote: post #378

Earlier quoted context omitted.

Nah, just tested and mail.google.com took 23.3 seconds to load in Chrome and 30.2 seconds in Firefox. I have a 4-core 8-thread i7 and am on a 20Mbps internet line. It's the website, it isn't my computer.

Is that from scratch? I'm using an i3 on a 1 Mbps satellite connection, and opening up Gmail now (having opened it earlier today), it was 0.27s until DOMContentLoaded and I could interact with it. It continued asynchronously loading stuff in the background but from my POV it loaded in 1/3 of a second, which in Chrome is faster than the app opens on my iPhone 7. I have disabled the Hangouts/Chat feature in settings wh…

Okay I can't believe that either! You're really talking about full Gmail loading in 1/3 of a second? That sounds impossible if we're loading the same Gmail...

Re: You probably don't need a single-page app

#428

Post by jes5199 »

ivanhoe wrote: post #402
tspike wrote: post #366

Earlier quoted context omitted.

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

There was indeed a moment few years ago when front-end frameworks/libs were changing at warp speed, but last year or so I think the situation crystalized a lot. You now have React and Vue as major players and Angular competing for the 3rd place against some fresh libs... and I don't see that changing anytime soon.

yeah, you have React, but which of the 30 fashionable state-management libraries are you using? Typescript or Flow? What version of JS syntax? What compiler what minifier? oh hey, half of these just stopped being maintained without warning

Re: You probably don't need a single-page app

#429

Post by Spivak »

eeZah7Ux wrote: post #367
andrei_says_ wrote: post #310

Earlier quoted context omitted.

How about “that’s totally possible. It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix. I personally would love to work on it, just keep in mind that any changes will require 10x the time and budget” And ... “Here are a couple of technologies which would allow us to speed up the experience at a very low cost. I recommend we try these first.” Turbolinks for the win :)

...and it breaks linking to URLs and backspace.

Turbolinks? Huh? You have to write your code keeping turbolinks in mind because certain onload events will only fire once but you use turbolinks specifically because you want those things to work but want the speed advantage of not doing a full page refresh.

Re: You probably don't need a single-page app

#430

Post by BigJono »

sovietmudkipz wrote: post #409
tspike wrote: post #366

Earlier quoted context omitted.

Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.

Not only that but you have to reinvent SSR with front end frameworks. Why do something simple when you can make it 10x as hard but ultimately end up with the same result.

I mean, I think these SSR front-end frameworks are a pile of crap, not worth the added complexity, and I hate using them; but it's pretty clearly not the same result. The problem they're solving is not "render on the server side", it's "render on the server side for the initial load then inject a fully functioning SPA for subsequent loads".
Post reply on HN