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

101–110 of 522 posts

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

#101

Post by brogrammernot »

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…

Node modules doesn’t get deployed out from your local machine, it’s pulled in during the build.

Also, .NET and “easy to use” hasn’t happened in forever. Unless you’re counting the “Hello world” tutorials that are useless.

The .sln file within a .NET project ends up being pretty damn large, so the whole 60mb node module thing seems a bit ridiculous.

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

#102

Post by onion2k »

bzalasky wrote: post #81

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources. Libraries like React are awesome for breaking down complex (or even not so complex) UIs into story sized chunks that can be tackled by different engineers or even different teams. This is one of the biggest reasons to consider using them, IMO. Even in the case of r…

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources.

And the users.

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

#103

Post by beatgammit »

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…

We had a very static product, and one of our devs decided to make more use of client-side rendering despite essentially being a set of unchanging forms. This quickly got out of hand, so we adopted a hybrid approach.

I built out another product, which was much more dynamic and made sense as a SPA. However, having been bitten by the forced SPA, I decided to do as much static rendering as feasible, and I think that has made things a lot easier to develop and less buggy.

Honestly, I agree that a SPA is usually a bad idea and prefer to have as much of the app be able static as possible since that simplifies things considerably. For example, slack could open a separate tab for settings (and perhaps chat history) and only have the chat parts as a SPA. It would make it slightly less fancy, but also probably much lighter on resources, faster to load, and easier to develop.

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

#104

Post by s_y_n_t_a_x »

petilon wrote: post #95
s_y_n_t_a_x wrote: post #80

Earlier quoted context omitted.

If you don't need state, don't include it. That's the beauty of React. But as far as a state management lib goes, Redux is one of the simplest, go look at the source. I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a small…

React requires too much incantations, rituals and ceremony. You have props and state, context, error boundaries, refs, keys, you have to figure out where state should live, etc. You make a component that contains state. Then you want to use it in a component hierarchy -- now the component is supposed to have props not state. You make a component that has props, now you want to use it at the top level -- now the compo…

You don't have to deal with any of that crap when you deal with react. Just write pure functions as components. The arguments are the props.

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

#105

Post by sheeshkebab »

Coming from similar background as author (various legacy web apps with all the challenges of learning now useless js frameworks) - I’m now have a different opinion:

SPA approach should be the default unless you have specific requirements to add html SSR (and even then google is pretty good at indexing public spa content too).

So, respectfully disagree.

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

#106

Post by 64738 »

wrestlerman wrote: post #30

I have the same opinion. Building SPA is f* hard and time-consuming. But it depends. If you know how to build SPA fast, then, by all means, go that route. (As a solo dev or small team) I use Rails, but Rails views are a disaster. You can use a lot of different patterns/gems, but still, logic is highly coupled with the view layer. Personally, I like Phoenix approach with templates + views. But still writing script tag…

Take this with a grain of salt, as I only recently came across it and haven't used it, but the Trailblazer framework looks like it has a good way of getting logic out of the views.

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

#107

Post by bzalasky »

onion2k wrote: post #102
bzalasky wrote: post #81

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources. Libraries like React are awesome for breaking down complex (or even not so complex) UIs into story sized chunks that can be tackled by different engineers or even different teams. This is one of the biggest reasons to consider using them, IMO. Even in the case of r…

The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources. And the users.

Hopefully, users have been considered in the product requirements, but yes, I wholeheartedly agree.

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

#108

Post by AnIdiotOnTheNet »

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 original simple use case and now it needs to be usable in scenarios where network access won't be available for most of the work day, which means I need to rebuild it --in whatever time I can manage to devote to it, dev not being my primary or even secondary responsibility-- to deal with that and better handle the functionality we tacked on later.

After a review of my options, which unfortunately doesn't seem to include writing a native application (for reasons I still may be able to work around), 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. Basically, just a client application written in JS. No special frameworks, no complicated toolchains. Even that is a pain in the ass because the web world hasn't quite worked out how to store local data in a non-stupid way.

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

#109

Post by tpetry »

greenhatman wrote: post #75
subpixel wrote: post #65

On the one hand, site like https://dev.to/ that are built in Rails and rival the speed and performance of any _static site_ support the argument that you can just use the tools you know. On the other hand, to get your Rails site to function that well takes a lot of work - it is by no means the starting point. Systems like Next.js and Gatsby.js and others are attractive in that A) they offer the ability to use both se…

I think dev.to is an SPA. But not built with a framework.

It‘s a traditional server side rendered application. But they use a custom implementation like turbolinks and instantclick to change the sites content without a full reload.
Post reply on HN