Comment by eropple | Hacker News Reader

Comment by eropple | Hacker News Reader

Parent Full thread

> The pro here is that you get just the stack you want!

I don't disagree with the facts-on-the-ground of your post, but I think you're drawing a mighty false equivalency and this line highlights it. The pro here, for a React-based stack is that you are forced to understand the tools involved well enough to make meaningful decisions (if you're a competent developer). By the time I was done evaluating routing libraries, I was confident in my ability to write my own, effectively--and so I didn't have to because I was able to adopt the library of my choice's mental model immediately. If you "just want to build your app", your app is gonna blow up (not might, will, given a long enough timeframe) and you're not going to be equipped to fix it.

Passive consumption is unwise for programmers. We've seen it bite people forever (be it the "all things come from Microsoft" era of .NET that they're just shaking now or the "Spring does it for us" era of Java or most of Rails pre-3.0).

The history of technology is using the progress of others as a foundations on which to build something new. Once it works, it's a given, a building block. No one can understand it all the way down and we need to be careful about saying what 'real developers' do or don't do.

It's not a given at all. All of your abstractions break. These high-level abstractions break much, much more often than lower-level abstractions (because they try to encompass more, it's a surface-area thing). There are abstractions that are so fundamental to doing your job that you must, must must must, understand them at an implementation detail and then use them to improve productivity.

The stump-dumb-simple routing layer of your JavaScript handwavey crap is one that You Really Just Gotta Know; it's literally central to everything you do in a SPA. And yet the overwhelming majority of AngularJS folks I have ever met--and, to their discredit, way too many keypuncher ReactJS folks, but a significantly smaller proportion--have no idea what to do if their web framework spits the bit. And my contention is that having to make choices means the likelihood of a baseline understanding of what chose choices mean is way higher.

There are plenty of capable developers who work on and choose to use AngularJS. I've worked with great ones. But, like the other environments I mentioned before, it sure seems like they brought that capability to AngularJS rather than had that capability fostered by AngularJS in a pedagogical manner. And that's troubling to me, because these folks are going to be writing software that you and I depend on, too. I'm not hanging people for not being able to work meaningfully with the JavaScript runtime or understand how the browser works internally (though these are handy to know, most of my knowledge of JavaScript comes indirectly from embedding first SpiderMonkey and then V8 in a game engine once) or how their OS handles process segmentation to sandbox off their web runtime environment (not a super complicated topic but, sure, out of scope) or how their OS handles memory (this one, ditto) or or or--I'm saying you gotta understand the thing your hands are on all the time and that tools that attempt to swaddle you in a nice comforting "you don't need to worry about that" are gonna put you in a real rough place when that doesn't hold.

So, I've had to maintain (upgrade) a Node/V8 extension, an Angular1 and an Angular2+ but never stopped to understand routing. (We talked about it briefly around that ng1 app.) And I have no idea how Node extensions hook into V8 under the covers.

There were no abstraction breaks. C++ compiled, the thing works, the same goes for ng2 with TS. Ng1 is just plain ugly, but works fine.

I like React/JSX, FRP, I hate the size of the bundles Angular spits out, the byzantine boilerplate required to put something on screen and to make components interact, but it works, and it comes as a full package, and it keeps getting better.

The design principles of Ng are sound. Ng1 was overcomplicated. Ng2 is okay-ish.

I think ng lacks the "documentation" that the React ecosystem must provide due to its separatedness/modularity.

But my main point is, that basically good developers will compare those routing plugins/libs, and those same devs can solve problems when ng2 spits at them. And newbie frontend devs jump on the React is small and simple hype train and take the first tutorial and then get lost in that jungle. (And I'm not saying this can't happen with ng1/2, but neither codebase is about teaching programmers, so that's a very fringe aspect of this topic.)

(Managed to cut a lot of snark I think. Less light-hearted now but also less annoying.)

If you "just want to build your app", your app is gonna blow up (not might, will, given a long enough timeframe)

I feel pretty safe building stuff using technology (Java EE) that I only know the surface. (i.e. API) of.

I think that we should choose solid, well though out libraries that we wouldn't have to fix by yourselves.

and you're not going to be equipped to fix it.

This seems to be more of a problem in JS land where tecnologies seems to get born, hit peak popularity and die within a few months.

In such a case I guess it makes a lot of sense to choose stuff that I could rewrite myself.

Never treating anything as a black box and learning the implementation details of every single bit of the framework I'm using sounds like a good educational exercise, I guess, but not a great way to deliver a useful application in a reasonable amount of time.

Being able to do that (and it doesn't take that long because you should be leveraging your prior experience to quickly build that picture) is literally the core value prop for engaging my services, so it seems to kind of matter to a lot of folks.

Sure, for any one component that's probably true. But there's a lot more than routing going on in a typical SPA, and you'll never really need to dig into most of them most of the time. My preference is to dig into components when I actually need to, rather than digging into every single detail "just in case" it might matter later.

This argument is as old as programming. High level language programmers don't understand everything as good as us assembly programmers, etc.

I don't think it's relevant for evaluating tools.

It is only relevant when hiring as you would like to find developers that is competent enough to grasp low level stuff at least at a rudimentary level.

In this case some side interest in routing frameworks might be indicativ regardless if they prefer to work with angular.

Reply on news.ycombinator.com