Hacker News Reader

Comment by iamleppert | Hacker News Reader

I love when people try to point the finger at a technology when in reality it is 100% the people who are using and implementing the technology. It's their fault. 99% of developers I know who create terrible SPA's have a long list of terrible things they've created. It's a mixture of incompetence, laziness, and poor management.

View on HN

>It's a mixture of incompetence, laziness, and poor management.

Don't forget the constant, unrelenting pressure to keep up with trends or you'll get summarily banned from ever having a developer job again. SPAs got trendy, so naturally everyone had to jump in on it when normal MVC applications work perfectly fine. There's a bit of hyperbole in my previous sentences, but please don't write off the endless articles and forum posts telling people to keep up with X technology because it does influence people.

Like seriously, we're constantly prodding devs into technologies they don't want to get comfortable with, then we're suddenly surprised at the lack of competence.

Any dev worth his salt can be productive in any language (sooner or later).

It’s when they’re hiring for technology instead of skill that I get antsy.

The rate of which you get there matters though. Because the most expensive resource is your workforce. I think modern JS is reasonably productive, and I think getting there is too.

But we recently build a Blazor.net app, and even though it’s new tech, the production time was a lot lower than it would have been, had we used our standard graphql Apollo + Vue approach.

I think something like django might be even more productive, but good luck hiring for that.

It's possible to create systems that are effectively impossible to use safely. I suspect that javascript on the web is a pretty well designed footgun, such that it's the exception to find someone who can't hurt themselves in their confusion.

If web browsers could interpret another language, would you make the same argument against it?

yes and no, the two big issues are that a) the SPA has to work within the very poorly documented render loop, for lack of a better term, of the browser and b) Javascript has some very idiosyncratic idiosyncracies and lacks some basic language functionality that is present in most languages

Please explain what’s poorly documented in current browsers render loop.

ok, if a div is added to the page body, and then another div is removed, what does the render loop do? any pointers to documentation are appreciated :)

Quick Googling:

https://developers.google.com/web/fundamentals/performance/c...

https://developers.google.com/web/fundamentals/performance/r...

I think a big part of the problem is precisely the interpreted and web browser part of your post, so you're right, but I think at this point it's difficult to disabiguate the browser, the DOM, and JavaScript. I think JavaScript as a language also has problems that make it difficult to do large scale engineering with, thus transpilers.

Maybe WebAssembly will provide fruitful ground for new, simpler, and more rigorous languages.

I also think that much of modern web apps could be accomplished better with HATEOS apps doing pure server side. But I will allow that my beliefs there are at least partly nostalgic

Using Elm, even a little bit, has given me a perspective on what a different language can do in the browser.

If you subscribe to Gary Benhardt’s Capability/Suitability theory of programming history [1], JavaScript is the highly capable technology that can be used for any sort of architecture you can imagine, and Elm is a turn towards suitability that says, “some of those architectures are unsound or have a very low floor for quality.”

You might want to abstract over DOM APIs for different reasons, but at their semantic core they are fine.

[1] https://m.youtube.com/watch?v=NftT6HWFgq0

I think that JavaScript is a really interesting and unique language. I would rather have had Perl in the browser. JS seems more appropriate as a relatively obscure academic language. Note that I tend to view trying to enforce types or use classes in JS as being misguided and futile, which does not seem to be a mainstream view.

It's not that people are writing SPAs badly so much as it's often unnecessary complexity. Like the "microservice all the things straight away" trope.

Sometimes a CRUD form should just be a CRUD form.

And sometimes something that should be a simple web page should be just that - I've not got anything against SPAs as such but I do hate looking at a spinner for 30 seconds to eventually look at something that is simply a static page with no interaction.

This is the problem 90% of the time. I hate the resume driven development nature that is almost encouraged in our industry.

The last few maintenance programming jobs I have worked on seem to have been written by people who have used a framework at peak hype cycle, without actually having a good knowledge of the framework.

Job ads never say "writes elegant code with a simple yet effective design". No they want "experience with React, Vue, Rails, Docker, etc".....

And at larger companies that's the fault of a totally separate team from the UI developers.

Several times I've run into the issue of an API developer misinterpreting "microservice" as "a separate endpoint for direct access to every DB row". Then you find yourself having to make half a dozen API calls for every form, just to keep the UX of the app from becoming a granular nightmare.

Or maybe the approach of reinventing the browser in the browser, shoehorning a document viewer into an application platform, retrofitting a language not designed for large-scale app development, coupled with hybris and lack of experience is an environment that attracts bad development.

It is somewhat prone to that since you're on your own to cobble various frameworks and tools together. Not to say you can't build a good one, but it's harder when good advice is fragmented by tech choices.

(see: "Flash is buggy and crashes all the time." - Steve Jobs, 2010)

If you ran the developer edition of Flash back then, you'd have seen that 99.9% of Flash "crashing" was a totally avoidable, unhandled exception from a third-rate developer.

Reply on news.ycombinator.com