Live data from Hacker News

You probably don't need a single-page app

journal.plausible.io

511–520 of 522 posts

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

#511
I kinda dislike this article. Not because it isn't true, but because of the effect it might have on some readers.

Yes, building a SPA is not always the best solution, but sometimes I get the feeling that a lot of developers hide behind 'I know how to build good SSR pages and all SPA I have used suck so I will not learn that sh*t'. If you know how to build a PWA with SEO support, offline+sync capabilities and push-notifications, you will know when to choose what (because of the pain you experienced learning it).

If your boss chooses your tech (from the latest buzzwords) and he doesn't understand the implications, I am truly sorry for you, but don't blame the tech on it (ask your boss for a seminar on 'How to Communicate with Managers' maybe then he will understand that you are trying to tell him something...).

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

#512
post #168

Earlier quoted context omitted.

I think all of your requirements could be met in a myriad of ways. E.g. Django templates/Handlebars can be organized as reusable components, many backend frameworks will render HTML per route, and there are several JavaScript client libraries including Vue and, dare I say, jQuery that will give you a sane way to do client interactivity without page refresh with varying degrees of declarative code style.

I think this means you are sacrificing the component library requirement. There is not a sane way to intermix js,html,css as a single component with dependencies on other components with your approach. What you end up with is 3 very distinct/separate/unique/difficult to maintain solutions across css, js (probably 4 if you include js/html), html.

Vue.js and Aurelia offer examples of how UI components can be organized and composed, while allowing clean separation of structure, function, and presentation (divided along the lines of HTML, JavaScript, and CSS by design.)

The main point is not to limit ourselves to a monotheistic worldview that convinces us, without substantive evidence, that "all other ways are wrong."

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

#513
post #211
post #106

Earlier quoted context omitted.

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.

I've been using parts of it on most Rails apps I've worked on for the last few years. The form object pattern (Reform) really helps when you need to update the same model in different places with different validations. For example maybe an Order only needs a price when it's created, but needs a invoice number (and some other validations) when marked as paid, but an admin should be able to override those validations a…

Thank you for your thoughts on it, I'm intrigued enough to really want to look more into it. Even if I don't get to use it, I think it will give me some ideas that I can apply to other projects.

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

#514
post #495

Earlier quoted context omitted.

I’m sorry but I guess I’m still missing the point. How is it not productive? It takes me a few seconds to get a REST API going.

It's not as productive. Anyone can create a REST API in any language in a few minutes, that's the easy part. Building a complex app is different though and much easier and faster in a proper environment that has strong typing, OOP, interfaces, reflection, dependency injection, a solid standard library, and more. Being able to use that same environment to create frontend views and code will greatly improve productivit…

Yeah sorry, I really don't buy it.

Strong typing is admittedly great and there are solutions to introduce that in JavaScript. However, this is hardly a dealbreaker in complex apps written in JavaScript.

OOP, interfaces: debatable and unnecessary fluff. There are plenty of productive languages without OOP. Example: Elixir. And there are plenty of productive languages without interfaces. Example: Go.

Reflection is unnecessary in JavaScript. You can access any property within an object dynamically and the language is interpreted, so there's no need to perform fancy reflection operations at runtime.

Dependency injection is an engineering pattern. You can apply this to almost any language. And ironically, plenty of JavaScript backend and frontend frameworks have attempted to use it successfully: Angular, Ember. Hell I even wrote my own DI layer once upon a time. https://github.com/divmgl/nwire

I'm sorry, I really disagree with you. I believe C# has the ability to be productive, but there is just no way you're going to convince me that it's superior to JavaScript and its ecosystem. There's a lot of disdain on Hacker News for JavaScript and it's honestly beyond me.

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

#515

Earlier quoted context omitted.

Why does creating a new client side widget require a server call at all? Couldn't you have the widget in a JavaScript template and just clone it on the dom client side?

Cloning from a template would be the what, but I was wondering if there are tools designed for this. It's the kind of thing that could spike complexity and I would want an established pattern of delivering html solely for the purpose of javascript manipulation. It's not a hard problem, but a messy one.

I would use a simple "javascript templating engine" like mustache or handlebars, to easily inject dynamic content into your widget templates.

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

#516

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

> 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 selli…

Maybe I should’ve made it clear that the 10x is an example. In most cases it would be 2x to 4x, the cost for implementing two apps instead of one.

Of course the cheaper option (monolith app + turbolinks and js sprinkles) could be framed as a discount.

And I can imagine how many agencies would not mention the expense of maintenance, because they’d actually want to lock in the client first.

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

#518

Earlier quoted context omitted.

I have always felt as angular was the second major player and vue the one in the 3rd place.

It's possible, especially if you look primarily at the enterprise market. From where I stand (startups, SMEs) it seems like a lot of people moved from Angular 1.x directly to Vue, skipping Angular 2+ versions. I haven't been offered any Angular projects in about 2 years, while React and Vue are really popular. But it's just my perspective, global situation might be different.

This has also been my experience. Enterprise systems really went all-in on Angular 1 for some reason (I personally suspect because it bridges reactive and MVC), and when it was time to move to a fully-reactive front-end framework, in my opinion Vue and Angular 1 are similar to each other in a way that React is not similar in relation to either of them or Angular 2+.

I still can't quite put my finger on why Angular 1 and Vue rhyme, though. It's common wisdom that "If you know Angular, you'll pick up Vue quickly", and it seems to be true, but nobody has ever explained to me why. Is it the state management? Reliance on viewmodels? How they're more complete systems out of the box and can be reasoned about holistically? Help a girl out, HN.

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

#519
post #482

Earlier quoted context omitted.

Yeah we have read experiences like yours again and again on every HN thread about SPA, but why we never learn? We developers kind of helping this fashion to happen.

Nine times out of ten, we developers aren't in a position to make or change business decisions of that magnitude. Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.

True but I was talking about the producer side, those cool kids in big corps. They have money backed and drive small companies to adopt the next cool things.

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

#520
post #502

Earlier quoted context omitted.

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 currently building an app that works nicely as a web app, but it needs to store gigabytes of data and work with only intermittent network access. I'm considering trying to bundle the server-side code into a simple Windows binary that just fires up an HTTP server and binds to 127.0.0.1. Would that work for you?

That's essentially Electron. I'd considered that, but if I'm writing a native application component anyway I may as well make the whole thing native instead of using wonky web tech. I'd like to do that, make it completely native, but right now there are factors beyond my control that I'd have to work around first.
Post reply on HN