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

221–230 of 522 posts

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

#221

Post by a_wild_dandan »

scarface74 wrote: post #57
dsego wrote: post #53

One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react. The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynam…

I would rather change a page if and when it is needed by a new feature than over engineer up front.

And I would rather over-engineer a bit now to make feature additions trivial & rewrites unnecessary. Different stroke for different folks, I guess.

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

#222

Post by oblib »

This article feels to me like complaining about making the simple difficult.

Since I work alone I suppose I'm not up to speed on what defines a single page app but the apps I've been building with PouchDB, jQuery, and Bootstrap run in a single page.

"Stateless requests Traditional web servers are built to be stateless. "

True, but "apps" should be designed to be self-contained (i.e. all the user navigation is done within the app UI, not the browser UI).

"The browser knows how to deal with a traditional architecture If you go with the SPA route, you’ll always need extra code to emulate trivial browser features."

That's a pretty trivial problem and browsers don't really solve that, nor should they.

"Fewer, more mature tools Avoid the Javascript fatigue by not relying so much on Javascript!"

The apps I'm building are almost entirely Javascript. I see that as a good thing. What little I do on the server side I do with Perl, which is something I've been doing since the `90s, so I can feel "traditional" doing that if it helps me sleep at night.

"SEO for free Single-page apps have to add extra infrastructure and code to make sure they can be indexed by crawlers."

This is not so difficult to address and in some cases it's not even a consideration. In the case of a "blog" app you can simply assign a url to a post and deliver a page built on the fly specifically for it. Google can parse that.

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

#223

Post by hesarenu »

petilon wrote: post #124
s_y_n_t_a_x wrote: post #104

Earlier quoted context omitted.

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.

Then you aren't benefiting from React at all. The point of React is DOM diffing, which you trigger using setState method.

The point of React is components. Simple components to build complex apps. Dom diffing are just lower level concerns.

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

#224

Post by Novashi »

save_ferris wrote: post #210
Novashi wrote: post #179

Earlier quoted context omitted.

TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want. We seem to only want developers…

> TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner. Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some ne…

Unknown: when random CEO idea occurs

Known: we’re definitely rewriting it in two years regardless of this CEO feature

The feature probably isn’t that complicated anyway

Maybe if you want code quality, stop rewriting so much shit because there’s some new hotness. Probably helps to not have so much new hotness too.

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

#226

Post by amoitnga »

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…

> 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.

This doesn't seem like a problem of "MVC vs SPA".

The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for example. You'd experience the same pain.

The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.

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

#227

Post by hombre_fatal »

scarface74 wrote: post #57
dsego wrote: post #53

One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react. The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynam…

I would rather change a page if and when it is needed by a new feature than over engineer up front.

Well, the thing is that you don't know if you're "over engineering" up front. That's the whole challenge.

And rewriting down the road because of the wrong gamble can be very costly. Make the wrong bet enough times and you'll see that it's not over-engineering but just engineering for changing requirements.

A classic example is thinking it will be simpler to avoid React and use a few .show()/.hide() toggles. Simple at first. Then as you take on complexity, you start to feel like the lumberjack who thought he could save time by skipping the axe sharpening.

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

#228

Post by FootballMuse »

aaaaaaaaaaab wrote: post #192
hyperpape wrote: post #139

Earlier quoted context omitted.

Great example, because the basic HTML version doesn't support keyboard shortcuts, which makes it a huge step back for me. It's certainly possible to have a server rendered app that uses JS sparingly for interactive behavior, but it blows away a lot of the benefits once you're doing significant DOM-manipulation.

If only there was a way to support keyboard shortcuts via plain old HTML... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

Aren't those inconsistent across platforms? Also you must use the "super" key/combo, and there's only one. Not to mention the internationalization concerns.

Good luck implementing 10% of the keyboard shortcuts gmail uses: https://support.google.com/mail/answer/6594?co=GENIE.Platfor...

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

#229

Post by guu »

dsego wrote: post #53

One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react. The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynam…

Here’s an approach you might find interesting.

Use JS rendering for all your pages but continue to use Laravel for routing/passing data to view: https://reinink.ca/articles/server-side-apps-with-client-sid...

Post reply on HN