Live data from Hacker News

If Not SPAs, What?

macwright.com

271–280 of 456 posts

Re: If Not SPAs, What?

#271

Earlier quoted context omitted.

Every time that sort of thing has happened to me it's been because there's some grand plan to build out more features that the people on the frontline don't know about. The plan rarely materializes but the idea that the foundation should be built in a way that supports it isn't completely stupid.

It’s not stupid, no, but a “supporting foundation” is a largely just a seductive metaphor. It says, “Clearly software is like a building. Every building needs a solid foundation.” It doesn’t inspire engagement with other metaphors, like considering software to be a tree that must be grown incrementally and as a product of dynamic forces. It doesn’t map knowledge from the building domain to knowledge in the software d…

Or that, with software, you can always rip out the foundation and replace it. And you're working on it as you work on the rest of the "building" anyway.

The difficulty of working on lower abstraction layers doesn't scale with the amount of higher layers. Unlike with buildings or bridges, there's no gravity in software, no loads and stresses that need to be collected and routed through foundations and into the ground, or balanced out at the core. In software, you can just redo the foundation, and usually it only affects things immediately connected to it.

A set of analogies for software that are better than civil engineering:

- Assembling puzzles.

- Painting.

- Working on a car that's been cut in half through the middle along its symmetry plane.

- Working on buildings and bridges as a Matrix Lord who lives in the 4th dimension.

All these examples share a crucial characteristic also shared by software: your view into it and construction work is being done in a dimension orthogonal to the dimension along which the artifact does its work. You can see and access (and modify, and replace) any part of it at any time.

Re: If Not SPAs, What?

#272

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced prog…

> not to defend the Java ecosystem, but it does get some things right, or more right than others

Out of curiosity, as a Java enthusiast, I was wondering if you could give examples of what you feel is wrong?

In my HN browsing I find Java is rarely actually discussed here, though often dismissed. I don't know why.

Re: If Not SPAs, What?

#273
First thing is to identify whether you're creating a web app or a web site. The latter being characterized by content-driven approaches and workflows around HTML fragments received from editors, aggregators, syndicates, product catalogs, or other third-party sites. These sites tend to be PHP-heavy, but don't have to be; a competent markup processor or "isomorphic" web composition processor (running both server-side and in the browser such as mine based on SGML no less) is specifically designed for this purpose, with straightforward and sophisticated, HTML-aware type checking, composition, templating, and escaping. For the former category of highly interactive web apps, my recommendation would by React or Vue, based on the mindshare of these frameworks. Don't let your devs use these frameworks for the sake of padding their resumes, and try to pin down your requirements and the necessary skill profiles for your team. It might not make sense for an internal app to be created using React when this will split your team into frontenders and backenders with completely disjoint stacks, increased coordinations, and loss of agile job rotation.

Re: If Not SPAs, What?

#274

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced prog…

> In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet!

Yeah, it's increasingly clear to me that Java was just 20 years ahead of its time. Java really would make a great front end language.

People lament the complexity and size of the JVM... But these days V8 is just as bad. The complexity is a trade-off for runtime performance.

It's compiled into a compact easy to parse bitcode format similar to WASM. It's faster than JS and shares many basic design decisions. The packaging system is and always was basically a better version of NPM. It has pretty good cross-platform UI, probably the best there is outside of QT.

WASM apps are eventually going to be built identically to Java cross-platform desktop apps. Probably using Java, Go, C#

Re: If Not SPAs, What?

#275
post #37

I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simpl…

React isn't so bad. It's fairly straightforward and the components are contained within the page. And it's more of a library than a framework. The core is small and easy to learn

Angular is a giant confusing pile of magic. It's so complex you've gotta be a core developer to even understand how an app comes together. Stay the hell away if you can

Re: If Not SPAs, What?

#276

Earlier quoted context omitted.

It’s not stupid, no, but a “supporting foundation” is a largely just a seductive metaphor. It says, “Clearly software is like a building. Every building needs a solid foundation.” It doesn’t inspire engagement with other metaphors, like considering software to be a tree that must be grown incrementally and as a product of dynamic forces. It doesn’t map knowledge from the building domain to knowledge in the software d…

Or that, with software, you can always rip out the foundation and replace it. And you're working on it as you work on the rest of the "building" anyway. The difficulty of working on lower abstraction layers doesn't scale with the amount of higher layers. Unlike with buildings or bridges, there's no gravity in software, no loads and stresses that need to be collected and routed through foundations and into the ground,…

The real "foundations" of a software system are probably its data structures rather than the infrastructure/backend. It's still an iffy metaphor though for the reasons you've given.

Re: If Not SPAs, What?

#277
post #266

Earlier quoted context omitted.

No, it doesn’t take that much skill. I think this is the source of the problem. The stupidity and hostile fear of originality I detect in this these comments is a very real reflection of my professional experience. This, dependence on frameworks and inability to imagine anything beyond the common SPA, really scares the shit out of me knowing I will be coming home from a military deployment soon and returning to the c…

> No, it doesn’t take that much skill. That is a pretty bold statement to make.

Not at all. It would only be a bold statement if it weren't so immediately validated in practice. A developer can write code or they can't.

Re: If Not SPAs, What?

#278

Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced prog…

> not to defend the Java ecosystem, but it does get some things right, or more right than others Out of curiosity, as a Java enthusiast, I was wondering if you could give examples of what you feel is wrong? In my HN browsing I find Java is rarely actually discussed here, though often dismissed. I don't know why.

For me, Java’s ties with Oracle and the nightmare stories about complicated `MetaAbstractBaseClassFactoryClassFactory` are why I seek alternatives, or would be dismissive.

Re: If Not SPAs, What?

#279

Earlier quoted context omitted.

I hear this so often, so as an exclusively js/ts dev I have to ask... what about this is “done poorly”? ``` try { return await fetch(url); } catch (e) { handleError(e) } ``` Because that (metaphorically speaking) is 90% of what I write. Throw in the occasional closure, `map()` or `reduce()` My day to day headaches are never from TS, and always from unpredictable DOM api/layout/style behavior. I guess I just don’t hav…

Fyi return await is redundant and is just creating one additional callback you didn't need (b/c you will have to call this function with an await anyways)

Try / catch is the exception, if you don't await then your catch handler won't work. https://jakearchibald.com/2017/await-vs-return-vs-return-awa...

Re: If Not SPAs, What?

#280
post #278

Earlier quoted context omitted.

> not to defend the Java ecosystem, but it does get some things right, or more right than others Out of curiosity, as a Java enthusiast, I was wondering if you could give examples of what you feel is wrong? In my HN browsing I find Java is rarely actually discussed here, though often dismissed. I don't know why.

For me, Java’s ties with Oracle and the nightmare stories about complicated `MetaAbstractBaseClassFactoryClassFactory` are why I seek alternatives, or would be dismissive.

Just noting that the abstraction stuff is mostly a consequence of the CORBA-derived, over-engineered "Enterprise Java" space, and provided you stay out of that tar-pit, and choose your libraries/dependencies wisely, Java is really nice to work with.

Even if you need to implement some kind of "Enterprise Java" app, you can do so with much better libraries and tools than back then, that do not suffer from the excessive abstraction problem.

Post reply on HN