Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

81–90 of 522 posts

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

#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 relatively unremarkable CRUD application, if the backend is split across multiple services and teams it may be entirely reasonable to choose to build a SPA frontend with a dedicated team.

On the other hand, if you're building a Rails app with a small team, and most engineers are working full-stack out of necessity, a SPA may not be appropriate.

As companies grow, I've found roles tend to become more specialized. Your decision to build a Rails web app early on could be considered legacy cruft (by some) down the road because it can be difficult to break down and deliver a feature across the full stack if you're not accustomed to building web apps that way.

There are tradeoffs to all of these approaches (including the hybrid approach). Ultimately, you need to do what's what right for your product and team(s), and make your technology choices intentional.

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

#82
So, a question coming from a guy who's been doing Java backend processing for a long time and thinking of making a side project. Was going to go the Angular route, but I'd like to have good SEO. I'd also like to get a POC/MVP up and running to build momentum...don't want to waste time on the front end when it's basic form submissions to kick off data processing.

To show how long it's been since I've done front end...My last 'full stack' development had plenty of tables to style the application grin.

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

#83
post #22

Earlier quoted context omitted.

Technically best doesn't always win the market. I'd love not writing 3 versions of every piece of functionality.

How's that working out when there's more than one browser you have to account for? What's the difference between polyfill or some framework, and something like Qt or SDL? Or I suppose we could just all use chromium, but we could also just all use Windows.

> What's the difference between polyfill or some framework, and something like Qt or SDL?

As a user, I usually can't even tell when they're using a polyfill on the web (except when they stop, like GitHub did with type=date). (As a developer, I often can't tell the difference, either. Some of them are that good!) So long as you generate HTML/CSS/JS, it doesn't matter to me how you do it. That's as 'native' to the web as you can get.

I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right. It's frustrating to use, and I always slow way down and double-check my work because, e.g., popup menus show the 'accept' animation even when you cancel them.

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

#84

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…

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…

While I'm excited about WASM and .NET on the frontend, I don't think Blazor is quite the solution I want. (Getting there though!)

If Evan You, Anders Hejlsberg, and two computers were all locked together in a room for a month or so, whatever emerged from that room is what I'm looking for.

Razor syntax has always felt clunky to me, and I tried very hard to like it when I first started with branching into web development from .NET.

I'm hoping that someone will use WASM very effectively to create some XYZ framework that's revolutionary. Then, Microsoft can do what they did with Java and make a version of it improved by hindsight. I don't think that Razor syntax would be the basis for whatever that is.

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

#85
post #22

Earlier quoted context omitted.

Native will always be the best solution... Because it's native.

Technically best doesn't always win the market. I'd love not writing 3 versions of every piece of functionality.

You're just externalising the time you save as a cost to your users.

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

#86

Earlier quoted context omitted.

It's in Googles interest as everything they deliver is through the browser. Not so much for Apple or Microsoft though. Personally I will be quite sad if I end up loosing so much control over my computing environment.

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.

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

#87

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…

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 tweaked beyond recognition and while the industry is doing so, most of us forgot the beautiful platform that resides underneath.

I love HTTP, HTML, CSS and JavaScript, I really do, but I really believe there is a huge tendency of amateurish approach towards making the web a better and more standardized place.

Back in the day, we had much less choice, and that made working with the web a lot more joyful.

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

#88
post #83

Earlier quoted context omitted.

How's that working out when there's more than one browser you have to account for? What's the difference between polyfill or some framework, and something like Qt or SDL? Or I suppose we could just all use chromium, but we could also just all use Windows.

> What's the difference between polyfill or some framework, and something like Qt or SDL? As a user, I usually can't even tell when they're using a polyfill on the web (except when they stop, like GitHub did with type=date). (As a developer, I often can't tell the difference, either. Some of them are that good!) So long as you generate HTML/CSS/JS, it doesn't matter to me how you do it. That's as 'native' to the web…

> I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right.

You mean it has no respect for your native toolkit... just like the web?

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

#89

Earlier quoted context omitted.

>Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools. Force them to only use simple tools and the good ones will move elsewhere because they know that being stuck on just the simple things is going to limit their…

Good riddance! A project is undertaken to achieve some specified result, not to advance a career or learn some new tool. Don’t get me wrong: those lofty things are welcome when they occur as a byproduct of developing commercial software, but these cannot be the driving factor behind decisions that affect the bottom line.

Part of working with humans and managing humans is understanding they're human and not machines. And keeping those humans happy does very much impact the bottom line. If spending 20% more effort on a project retains engineers that speed up projects by 30% then it's a net gain for the business. Bad companies and managers don't understand that and then wonder why all their engineers are bottom of the barrel (or rather why their projects end up such disasters while those of their competitors don't).

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

#90
post #64

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…

.NET is not that simple either, you are just used to it. Beginners will think it is confusing with .NET, .NET Core, .NET standard for example. There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started. Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on…

I agree.

Microsoft did a terrible job not having one framework for every path, like it did with the original .NET framework.

Post reply on HN