Hacker News Reader

Comment by reaperducer | Hacker News Reader

I think SPAs get a bad reputation partially because they're trendy. Which means that inexperienced programmers flock to them and make them awful.

I recently re-wrote an SPA from a previous dev into a regular set of query/response web pages. The SPA was 2,143K. The new set is 78K. A big part of that savings was because javascript is verboten for this project due to client hardware constraints.

Yes, the previous dev was not the best in the world, but IME SPAs are always heavier than their response/query counterparts.

View on HN

Not trying to defend inexperienced programmers but I've seen plenty of 20+ year senior programmers contribute poorly to SPAs.

They refuse to learn the best practices / new patterns because "they have 20+ years experience".

I have been caught in the middle between some younger programmers and some elder folks for the body of the past 3 years and the bottom line is this:

Learn the suggested best practices, or just don't build apps like this.

The OP's original thoughts on simplicity do ring true, but pushing for better UX is actually a reason to redo something. There are plenty of legacy systems out there with frustrated users, and the "complexity" can be simplified if effort is invested to accomplish those goals.

As a relatively junior developer, my advice would be “learn the best practices, or don’t write code at all”...

But we’ll see if I’m actually following my own advice 15 years from now. Hopefully I’m not on the wrong side of the Dunning-Krueger effect

Sometimes I find myself fighting the framework and someone inevitably shows me the best practice and I see how it would have just worked had I done more reading.

Good luck out there.

> But we’ll see if I’m actually following my own advice 15 years from now.

The one thing I've learned after doing this for 5 years is you probably won't be needing to follow best practices in the next 3 months.

I've been in my current role about three years. Most of my 2015 was building an Angular 1.X transactional app. By the time it was released, I was told to start learning HapiJS and EmberJS because we were transitioning as a group to that. Then 8 months later and several smaller apps, I was told we're going back to AngularJS and Angular 2.0 transitional. So I had to almost completely relearn that. Then after one huge disaster trying to integrate it into our services, we gave it up and spent the rest of 2016 moving that app to ReactJS.

I then spent most of last year jumping around (because now all these apps we built needed supporting) between those three frameworks (Angular, React and Hapi). Now there's talk of moving to VueJS but there is a loud push to just stick with one (Angular or React) and be done with this.

My point here is you may want to learn best practices, but how fast my org was changing, and building things quite literally on the fly, you just don't have time. Sure, in my own private projects, I learn best practices and use them myself. For our customers and "the business"? No time man, no matter if it will us time or not. Getting something shipped that's working is far more important.

Ironically, you've just provided an excellent illustration of some real good practices: find tools that are good enough to do the job, only depend on things that are built to last, and concentrate on actually doing that job. The web development world's obsession with constantly moving to the next thing that does essentially the same job as the last thing but maybe 5% better (or maybe not) is a huge productivity sink and best avoided as much as possible. Getting something shipped that's working is far more important than exactly how you made it, and it always has been. If "best practices" aren't helping with that, are they really best practices at all?

While this is generally true, the situation with SPAs is a bit more complicated. Each popular approach early on had a lot of serious issues and pitfalls. IMO React was the first thing to really break through this and while it’s not perfect it addressed the biggest issues Angular and Ember had quite well.

However, at this point, once you’ve adopted React, NG2, Ember 2.x, or Vue, there’s not much to be gained by switching between them. They’ve all sort of gotten past the initial immaturities of the SPA approach.

This is really something you ought to carefully evaluate once and be done with it.

It sounds like your leadership is morons, but you blamed JavaScript?

Yeah but as a result you could easily write no code at all and not learn from your mistakes.

The trouble is that web development is such a young field and moves so fast (or at least appears to) that the whole idea of "best practices" is fallacious. In many areas, we barely have enough experience to distinguish good practices from bad ones. Even then, most of the good practices that will stand the test of time are about much more fundamental things than which framework or build tool you're using.

It’s definitely not about frameworks or build tools. It’s just about applying whatever you’re using well. It certainly doesn’t have to be perfect, but it should at least be clear that an effort was made.

would work with. don't care if you use them, but at least learn them!

If bad behaving SPAs are commonplace then there is still a lot of work to be done to improve the tools and frameworks. But after many years of churn in tools maybe the problem runs deeper: the language and platform. I wonder if my time is best spent in this field.

Problem: Best practices change every 5-year, new patterns get deprecated by the hot-new opinionated framework at the moment.

As a senior programmer is difficult to explain to jr's and sophomores to not look all problems with the "disrupt everything" mentality and have continuous battles about that we don't need TDD, that we don't need CI, that we don't built everything as a webpage and definitely don't need slack integration for everything.

jr's and sophomores tend to go trendy on software development, don't like to work on the boring stuff, the stuff that makes money (audit and management, government compliance and payroll software) prefer to go on FB and built the hot-new AI for choosing the right ad to show you.

As a fellow "senior" programmer, I can barely imagine a non-side project that is small enough for me not to demand it running on CI.

Agreed. My home server has a Concourse instance on it because setting it to run tests on projects takes, like...five minutes of editing a template.

But, then, horror of horrors, it makes it incumbent upon me to write tests, and clearly that's just horrible. ;)

As another "senior", I think these things almost always depend on context. Some of the shiny new tools and techniques really do move the field in a significant way. Most of them don't. The ones that do might advance one area but might not be particularly relevant or helpful in other areas.

For example, personally I find it easy to imagine projects that don't have much need for CI tools, particularly not the formal ones that have "CI" in their name. Maybe a project is small enough that the only developer(s) involved are constantly making builds for test purposes and rebasing is standard practice when pushing to shared branches. Maybe a very large project has a complicated and carefully controlled branch/merge plan for their repository, and merges at key points are systematically checked following a whole review process. Either way, the extra effort to run a dedicated CI tool might not provide much benefit.

Of course, in other cases, you'll be in a sweet spot for this kind of tool. Having something to automatically warn you if a key branch stops building could save a significant amount of time and trouble. The point is that it depends on your situation. Automating something means finding, learning and deploying software and infrastructure to do that job for your particular project. That's time and resources you aren't spending on something else, and these things are always trade-offs.

Calling TDD and CI "trendy" is...well...I'm gonna be real: those are junior attitudes anywhere I've ever been.

But then, I also don't know any senior developers who would write "fuck all JavaScript/NodeJS developers"[0]. Or randomly rant about how somebody who notes that features that break stuff aren't good features[1] (which I noticed because I was fascinated by your post and wanted to learn more about what you think--and boy, did I!).

Dude: maybe it's not your juniors who are a problem here?

[0] - https://news.ycombinator.com/user?id=SadWebDeveloper

[1] - https://news.ycombinator.com/item?id=15859062

First, thanks for taking time in checking my profile and comment history, m quite honored that you have devoted that much time before replying my comment but usually when somebody does this is because they are trying to appeal to authority or a plain ad hominem.

Second, i didn't said TDD/CI is trendy, i said "you don't need them", probably should have add "at all times" to clarify.

Each year it's becoming a increasingly difficult to keep jr's from wasting time implementing TDD+CI+Slack+Hot-New-Thing on all the projects, wasting resources and time from devops for the projects that do need them. Not all the projects that you built on your lifetime need the same amount of bureaucracy as those that clearly are business-critical.

Let's think a little about this post and your prior one. Juniors don't like to work on "boring stuff" like testing and ensuring that your builds correctly complete, hmm? While you're complaining that they "don't need" stuff like TDD or CI. TDD is "wasting time", even though it's how you can actually specify software and then just knock out the issues to turn those tests green, increasing velocity once you're comfortable with the rhythm. CI is "wasting time", even though it's how you avoid rolling broken stuff out to production (and thus have to, yanno, do it again).

What I'm saying is that your post was incoherent (and this reply is worse), which is why I read deeper into your comment history. There's a lot more incoherence there, too. Frankly? It reads like a junior who's found what they think is a local maximum and is insufficiently humble to realize it's not a global maximum either. And I have a little bit of extra oomph on that one, I think, because--lest we forget--your public-facing profile says fuck all JavaScript/NodeJS developers.

Most people would pay a lot of money to juniors who wanted to do that stuff. Maybe those dang kids have a point.

> TDD is "wasting time", even though it's how you can actually specify software and then just knock out the issues to turn those tests green, increasing velocity once you're comfortable with the rhythm.

What kind of software are you writing that this works? full-blown TDD-as-a-specification is both too detached from the domain and too bogged down in details at the same time; you end up creating a Frankensteinian codebase that barely makes a coherent whole, but it's sure easy to test.

> CI is "wasting time", even though it's how you avoid rolling broken stuff out to production (and thus have to, yanno, do it again).

You need CI if you're working on a big project that will get deployed to multiple places (counting dev, staging and production machines). You don't need CI if the project is small and limited in deployment - about all it does then is protect you from the lazy-ass developer who thinks committing code that doesn't build is a good idea.

The thing that I believe 'SadWebDeveloper is aiming at is that hippie-devs mistake finger for the moon; they think of TDD and CI and other popular practices as dogmas to follow, instead of potentially useful techniques that may or may not be beneficial to any particular project. Noticing the limits and the trade-offs comes with experience, I guess.

> Most people would pay a lot of money to juniors who wanted to do that stuff. Maybe those dang kids have a point.

Would they now? Paying structures in software companies have usually little to do with actual value provided to the project/company.

> And I have a little bit of extra oomph on that one, I think, because--lest we forget--your public-facing profile says fuck all JavaScript/NodeJS developers.

Maybe too strongly worded for my taste, but I can kind-of understand the sentiment. The software ecosystem around the web is just bonkers.

> What kind of software are you writing that this works? full-blown TDD-as-a-specification is both too detached from the domain and too bogged down in details at the same time; you end up creating a Frankensteinian codebase that barely makes a coherent whole, but it's sure easy to test.

For clients, where I most often practice TDD? Libraries. Web applications (mostly services, occasionally web). DevOps tools. Personally, where I do it for core logic when I understand the problem fully going in? I have a React Native app in the Play Store which I basically proved working via tests before I ever built a UI. I've built a service-oriented authn/authz stack I'm looking to open-source soon, and it has 100% test coverage and the test cases have been looked over by much wiser heads than me to bulletproof it. All sorts of stuff. I naturally write code that's decoupled sufficiently to avoid mocking (except when forced to by writing sufficiently downstack stuff, but that's rare enough these days).

Specifications are in English from the client (either from them directly or written by me to their approval), I turn them into tests as I rough out an overall architecture, and I then make those tests turn green. And, because I actually know how to write tests in the large and in the small, I have a reasonable--not perfect but reasonable--expectation that my code will work.

(I don't do this as much as I should for personal projects, but that's because most of them are much more exploratory or are effectively plumbing over somebody else's API.)

> The thing that I believe 'SadWebDeveloper is aiming at is that hippie-devs mistake finger for the moon; they think of TDD and CI and other popular practices as dogmas to follow, instead of potentially useful techniques that may or may not be beneficial to any particular project.

This is the sort of in-your-own-head view that makes one old prematurely and unnecessarily both unwise and unlikeable.

I know that, because I used to say what you do, and I was wrong. It used to be Ruby, though, not just JavaScript. Things change too fast. It's all too reckless. Then I started using them in earnest--first Ruby a few years ago, then Node and JavaScript over the last year. And I realized that the things that draw external criticism are things that exist for a reason. These things are not discussed merely because they're "popular", it's because they make the end result better and they are transferable from project to project in a way that amortizes the cost even for small ones.

But, more importantly, the notion that these are somehow "hippie-devs" because they care about practices you don't is one, disrespectful, and two, kinda really often wrong. (I know this because I thought this, and I was full of shit.) These are not stupid, uncritical, or foolish people. There are problems and there are gaps--the Node ecosystem's general lack of understanding of underlying Unix is continually troubling--but when it comes to the platform and the practices of it, the notion of "change for change's sake" is mostly unfounded.

Anyway, the software ecosystem around the web is bonkers because the web is bonkers. Because people want the web to do stuff it wasn't built to do and is really hard to do effectively. That's why there's so much churn. Because people are learning new things and applying them. (Heaven forfend.) But it's working. If you step into this stuff, today, here and now, with React and ES6, you get an experience that is flat-out better than any I have had with any system, ever--with WPF being the closest, but not that close, I can think of, and miles better than any server-side HTML chewing that I can think of. Stuff is changing because stuff is improving. And it's also slowing down as practices gravitate towards what appear to be reasonable local maxima. It did for Ruby, it is now for JavaScript; you can write a frontend using React and be reasonably assured that it'll be supported for most of a decade and that you'll be able to find developers, and the JavaScript backend stack hasn't really changed much in a couple of years). It's part of the lifecycle. Whining about it is whining about the weather; nobody else cares, and nobody wants to hear it.

I run a devops consultancy. Sometimes this is marriage counseling for engineering teams; sometimes this is "come provide technical leadership." I am paid to have opinions and to lead people towards best practices. I have learned over time that holding those opinions so tightly that you say "fuck all JavaScript/NodeJS developers" doesn't make you good or wise or experienced or decent, it makes you a jerk, and it makes you unfit to interact with people, let alone mentor young adults. And it is unworthy of your defense.

Ouch.

I guess I deserved it.

Funny how you mention Ruby, because as I was writing the previous comment, I actually thought of it; I was a bit dismissive of the Ruby culture (that around Rails in particular) as well, but - unlike JS - it was entirely tangential to my work, so I didn't dwell on it.

Maybe I'm projecting a bit when I talk about "hippie-devs", but that's because I used to be one too (more than once), and I remember being eventually disillusioned about the things I was in so much awe of.

(Also, I don't call something "hippie-dev attitude" for just caring; the attitude I don't like is following and promoting popular trends without understanding the actual (not imagined) benefits and trade-offs they involve. Which is something I was both doing at times, and frequently witness on the web.)

> If you step into this stuff, today, here and now, with React and ES6, you get an experience that is flat-out better than any I have had with any system, ever--with WPF being the closest, but not that close, I can think of, and miles better than any server-side HTML chewing that I can think of.

I started playing with React recently and I admit, it seems to be great and living up to the hype (barring the broken setup process that suffers from ever-shifting JS dependencies, but that's orthogonal).

> you can write a frontend using React and be reasonably assured that it'll be supported for most of a decade and that you'll be able to find developers, and the JavaScript backend stack hasn't really changed much in a couple of years).

I don't feel confident about it. I mean, the last stable JS thing I remember was... jQuery. Everything else I've seen so far is shifting sands. Works today, broken tomorrow, works again next week, abandoned half a year later. But you have more experience there, so I'll take this as evidence toward "stability" hypothesis. I really do hope it's true - then maybe we can iterate on overall React performance, fix the damn unstable mess of underlying dependencies, and we'll have something solid for everyone to use.

> I have learned over time that holding those opinions so tightly that you say "fuck all JavaScript/NodeJS developers" doesn't make you good or wise or experienced or decent, it makes you a jerk, and it makes you unfit to interact with people, let alone mentor young adults. And it is unworthy of your defense.

Thinking about it more, I believe you're right.

Thanks for calling me on my bullshit. Really. That's one of the reasons I come to HN - so that people can tell me where I'm wrong, especially in the opinions I hold strongly.

Haha, hey, I appreciate your response - I recognized your posts, I figured you were an alright guy, so I gave you my honest take. =) Like I said, I've totally been there. I still rip on Golang more than I probably should, but that too is out of knowing how the whole thing works. (Before editing, I wrote "the whole tire fire" here. Old habits die hard.)

I think being disillusioned with tech is also part of the cycle. You can't be frustrated by something until you really know it and really like it. Usually anyway--my exception is Golang, I got deep into it but never liked it. I haven't hit the frustration point with Ruby personally, but I also don't use it as a substrate on which Rails runs. I think I would be much more frustrated by it if I did, because Rails seems to have gone down some weird holes (ones that make a lot of sense--if you're writing a Basecamp framework), but Ruby-the-ecosystem, not so much.

I do think React is going to be a Thing for at least five years. There's too much momentum behind it and, unlike Angular, it seems to have a straight-up smart basis for existence. Making the UI fundamentally stateless (or easily made stateless--I think component state is going to be left out of "React: The Good Parts") will age pretty well, and it's already really fast at DOM rewrites in ways I tend to think browsers can key in on with batch APIs down the line (to avoid context switches into/out of JS-land).

Couple that with already having stuff like React Native out there, and it seems pretty open-and-shut that it'll be a worthy choice for a while even if Facebook abandoned it--which I don't expect them to do unless something clearly superior, and worth the cost of migrating a lot of stuff, comes up.

wow, that's a really long reply for a couple of short rants on HN, you either have tons of free time (kinda implied now that you have explained that you work as a full time freelancer) or really take this site seriously; personally i don't take this site seriously for that kind of discussion because the vast majority of the audience here is not a developer, i even have a comment on my history asking this in a thread.

Anyways, i believe that all your comments/rants can be resumed on you getting offended by my profile motto on javascript/nodejs developers, my disdain for testing-all-the-things mentality and some out of context sarcasm that may or may not have hit hard on you (m guessing it hit, otherwise you won't even try to pull an ad hominem move like the one before), the only answer i can think to this is... sorry that my jokes/rants got you, it wasn't intended, was a rant i write when i first originally join HN almost 2 years ago.

Now that we have made that clear let's rewind to my original rant, the one talking about jr's pushing TDD+CI+Slack+Hot-New-Thing on everything and add that we were talking before about jr's trend to make everything on SPA's and OP rant on seniors not grasping the need for that tech.

In today "web development best practices", it is common to build things out of duck-tape, jr's like to bootstrap their environment with all the batteries included and by today "standards" this includes TDD+CI+Slack+Hot-New-Thing, which is fine if you are going to build the next-uber but not-so-fine if you get hired to built a simple webpage for a client (the boring stuff, nobody wants to work that jrs usually had to grind before touching business-critical infrastructure), webpage that barely has dynamic stuff but now requires a hole built process because jr's thought that in the future they might need it.

This trend leaves me or any other senior always talking to them on the good and bad things of being a "lego/duck-tape developer", because not all of the jrs are full engineers or have a PhD on computer science the vast majority join either fresh from college or just took a couple of online courses and were able to navigate the HR interview process.

That was is my original rant that you took it wrongfully as an attack on your belief (well kinda your main job as a devops consultant), maybe you have been working so many years in big projects that you forgot that not everyone is building the next uber.

Kindest Regards

PS: Why m not in your hall of shame? i don't deserve that honor yet? ;)

Testing is a fine idea, but I don't really believe in TDD for most projects.

For you? Or for everyone? The former is a reasonable position, which I assume of you because I think your posts tend to be solid and well-thought-out--and also because the latter is demonstrably cracked.

And even if you don't, personally, like TDD, ranting about junior developers "wasting time" using it is some weird stuff. Whose juniors actually want to be writing tests? Most times, you have to hammer it into them.

I have no idea what distinction you're drawing or what you think is demonstrable about it. Sorry.

The distinction being that you may feel less productive when doing TDD--but that TDD very obviously yields significant benefits for developers who aren't you. I'm not saying that you should do TDD because it works for me, but I am saying that it very demonstrably does work for me.

If you don't like TDD and don't practice it for this reason or that, that's totally fine. Going out of your way to disabuse junior programmers from using it strikes me as crazy-town, which is kind of the point I'm making here?

> but that TDD very obviously yields significant benefits for developers who aren't you

Isn't this a case of begging the question? It's "very obvious"? It's not so obvious to me. You claim it is "demonstrable," but demonstrate nothing.

I think the idea that writing tests is a substitute for design or documentation is a bad idea that can easily lead someone astray.

You think you don't need to test your code or ensure that it compiles consistently? And you try to teach this to jr devs?

You must be a joy to work with...

That makes no sense. What other "practice" besides "best" would they be using, given that SPA didn't exist 20 years ago? Would they look at the SPA sample and say "I see that you're using history to have the back button work, but I'm removing that code"? Obviously not.

> SPAs are always heavier than their response/query counterparts

Heavier by what metric? Initial load size? Sure. But the static assets will be cached after the first page load, after which an SPA should definitely be faster than a traditional server-side web app given that a) less data is sent over the wire for each page load (you don't need to re-send headers/footers, JSON is usually smaller than HTML, you can implement intelligent caching strategies, etc), and b) only a part of the page is re-rendered, rather than the entire thing every time. So "heavier" really depends on what you're optimizing for.

> Heavier by what metric?

I measure by the amount of data sent to the client to accomplish a task. I keep a very close eye on this because it's part of my POP (proof of performance) reports each month.

Don't forget that plain query/response caches many static assets, too.

Sure, but what about responsiveness and other metrics? Reducing the absolute amount of data sent over the wire may be what you are optimizing for, but it's not by any means the absolute metric of performance. Personally, as a user, for many web apps I would rather see a longer initial page load but have all subsequent actions appear instantaneous (a la Gmail), than spread the load times out across every action.

My point isn't that SPAs are better than traditional web apps or anything like that, just that these decisions depend entirely on what you are optimizing for and what your priorities are. If initial page load time is your priority, then an SPA may not be the way to go; however, if your goal is to maximize responsiveness or interactivity, then the extra 2MB of JS will likely pay off.

Reply on news.ycombinator.com