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

321–330 of 522 posts

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

#321

Post by pault »

danielovichdk wrote: post #87
s_y_n_t_a_x wrote: post #54

Earlier quoted context omitted.

You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge. It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain. There are hundreds of directions you could go in, and I consi…

I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tw…

I don't doubt your experience, but when people say "toolchain" in the context of front end development, it's usually a reference to the dev environment and build toolchain, not the HTML/CSS/JS technologies themselves. I've been focusing primarily on front end development since 1999, and while I also hate the current complexity in setting up a complex JS client, it allows us to scale far beyond what was possible back in the jQuery days, and it has made my life much easier. It becomes a problem when people suggest that you set up babel, webpack and hot module reloading for a site with a couple of forms.

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

#322

Post by Toutou »

matchagaucho wrote: post #187

Counterpoint... how many times have you clicked on a Show More link and thought to yourself "No, no... please don't redirect me to another page". Progressive reveal patterns are expected by end users. It's just lazy for a programmer to assume old-world CRUD patterns with server-side render.

I can't see why the Show More content couldn't be rendered server-side, fetched with AJAX and plugged into the DOM with two lines of JS. SSR, no redirect nor refresh, progressive reveal af.

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

#323

Post by crooked-v »

caseymarquis wrote: post #34

For new development, I reach for SPA tools (like VueJS with Webpack) fairly quickly. The reasons for this are: 1. Reusable web components. 2. Clear separation of backend and frontend logic. 3. Using the latest version of javascript. I really like HTML/CSS/JS as tools for building GUIs, but I feel HTML/CSS specifically suffer from the inability to make components. I think there are definitely instances where there is…

You may want to look at Next.js, which is an SSR/SPA framework using React components that also has a "render entirely to static files" build mode option.

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

#324

Post by mnm1 »

phkahler wrote: post #86
simple_phrases wrote: post #42

Earlier quoted context omitted.

Native apps allow Google to collect much more information than they can via the browser. They also allow for a wider range of advertising opportunities.

Except for people who won't put up with advertising in native apps.

Based on the number of Windows 10 users, that's a very small percentage of users indeed.

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

#325

Post by scrollaway »

andrei_says_ wrote: post #310
Spivak wrote: post #254

Earlier quoted context omitted.

It's difficult to tell the person who's writing your paycheck "this is totally possible I just don't like it and so won't do it." Like if you're doing SSR you could at least use something like turbooinks to implement state transitions.

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 :)

> It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix.

I say this as someone who's done a lot of freelance work: No, you can't bullshit your clients like this. You may be able to tell them that if it's not an actual lie, but in your case, if you actually would endure such costs and fragility, it speaks volumes about your agency's skill levels.

If you're in the business of selling websites, maybe it's time to actually learn how to write a good SPA rather than bury your head in the sand, because yeah, clients do actually want those.

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

#326

Post by crooked-v »

BlackFly wrote: post #250

I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to tone down the "probably don't need" into a "don't necessarily need". As a predominant back end developer, I do feel that the complaints from the article are due to inexperience or misunderstanding: 1. stateless requests: You don't have to cache any state by de…

> I am not sure what the Angular or React solutions are but with vue just use the vue router.

For React there's a couple, but most of them boil down to the same basic idea that you've got switch statements that decide which components to render based on router state (rather than there being anything "special" about routing entry points), and then something like a component that just acts like an tag but triggers the client routing change instead.

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

#327

Post by pault »

AnIdiotOnTheNet wrote: post #108
danielovichdk wrote: post #28

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…

I'm with you. I'm not employed as a developer, and am certainly not a web dev, but a few years ago I (perhaps foolishly) used some spare time at work to create a tool to help the people who do the non-sitting-in-an-office work in our company get more accurate and relevant documentation for their day-to-day workflow that they could access via a cheap tablet connected to our WiFi. It grew, as projects do, out of its or…

> I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available.

I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is supported by all browsers and all you need to do is de/serialize your data to JSON when your data changes.

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

#328

Post by jrowley »

hello_moto wrote: post #313
insulanian wrote: post #303

Earlier quoted context omitted.

Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. I would also wholeheart…

> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better. In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to delive…

This where technology like graphql can really shine.

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

#329

Post by crooked-v »

pault wrote: post #321
danielovichdk wrote: post #87

Earlier quoted context omitted.

I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tw…

I don't doubt your experience, but when people say "toolchain" in the context of front end development, it's usually a reference to the dev environment and build toolchain, not the HTML/CSS/JS technologies themselves. I've been focusing primarily on front end development since 1999, and while I also hate the current complexity in setting up a complex JS client, it allows us to scale far beyond what was possible back…

> It becomes a problem when people suggest that you set up babel, webpack and hot module reloading for a site with a couple of forms.

I've found that parcel-bundler "just works" for stuff like that without needing extra configuration, including the Babel part.

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

#330

Post by mehrdadn »

Fredej wrote: post #238
kyledrake wrote: post #67

Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…

It's funny how Google has been banging on about "just a few milliseconds of extra loadtime and your bounce-rate increases!" while in Gmail it's like they think the product is so good, people should be willing to wait 10 seconds to view their _mail_. The reason I'm even reading this comment section is because I wanted something to do while waiting for Gmail to load.

If Gmail is taking 10 seconds to load it might be worth your time to consider a faster computer for your own sake. It can be like 3-4 seconds on a faster computer.
Post reply on HN