Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Not SPAs, What?

macwright.com

Post reply on HN
Print view View original

291–300 of 456 posts

Re: If Not SPAs, What?

#291

Post by deepstack »

randomsearch wrote: post #261

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…

>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.

Typical hipster web dev now days! Go back to the basic.

Re: If Not SPAs, What?

#292

Post by yoz-y »

randomsearch wrote: post #261

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…

> You certainly wouldn’t use a language like JS,

I disagree with this. You might not want to use JS but a language “like” JS such as TS or Lua would definitely be on the table. Or just JS without the biggest warts.

> you certainly would want to provide visual design tools as far as possible,

I feel that the promise of visual design tools fell quite short. Issues with version control and general traceability of changes and the ultimate non feature parity with code make me think that code first interfaces are the future.

> APIs would be replaced with standard protocols,

Could you elaborate what do you mean? I assume REST apis but that is basically just HTTP.

> and probably you’d use a relatively small XML for layout.

As long as the language is robust enough to not move stuff around when the UI slightly changes. I feel that XML (and to an extent html) is too lax to express a programmatically created interface.

> So perhaps only the HTML is anything like what you’d use. There’d be no transpilation, no webpack, no polyfills, no CSS, no JS.

In a different world you could replace these steps by compilation, compiler, backwards compatibility libraries, a styling framework and a language of choice.

I think you have shown that JS ecosystem has grown very organically. I think this is because the nature of web developers was to put stuff out rather than really think about how do make it the correct way. I believe this is because of constraints, on a native platform you had the option to go down to assembly or create a new language or paradigm. On web only the browser vendor has this power, all the dev had was JavaScript.

Re: If Not SPAs, What?

#293

Post by tarsinge »

skytreader wrote: post #256
cs02rm0 wrote: post #242

Earlier quoted context omitted.

When SPA's became the norm and even static web pages needed to be build with React I'm in a weird situation where I'm contracting into one organisation and they've contracted me out to another. The first organisation know me as a senior dev/architect with 15 years experience in a niche domain. The second organisation see me as brand new to them and despite paying an embarrassing day rate are giving me noddy UI tweaks…

It's interesting to contrast this kind of organizational behavior with the type where "management won't give us time to deal with technical debt". Though arguably using an over-complicated framework is creating more technical debt, on a certain perspective, this is on the other end of this scale. It seems to me what we want is some kind of "Platonic ideal" where the extremes are bad for development: Management won't…

IMHO the problem is that with reusing your scale I typically see:

  Management that don't really understand tech and is afraid to try things
  |
  |
  THE IDEAL
  |
  |
  Management that don't really understand business (and sometimes tech too) and is focused on tech fashion
Surprise the ideal is hard because it requires both tech and business experience to recognize how best practices and new tech could bring value in a specific context. The job is to make clients happy by solving their problems, with apps that are nice to use, bug free, performant, maintainable, evolvable, with a usually short time to market and obviously for the best cost. Sometimes that equation is solved with a complex stack, architecture and practices with hundreds of engineers, and sometimes with a few web pages, inlined CSS, a bit of vanilla JS, and a solo dev.

Re: If Not SPAs, What?

#294

Post by edwinyzh »

tapvt wrote: post #147
brylie wrote: post #55

HTMX https://htmx.org/ LiteDOM https://litedom.js.org/ Stimulus https://stimulusjs.org/ Turbolinks https://github.com/turbolinks/turbolinks

I am quite a fan of HTMX and am using it for multiple projects now. I hope it continues to gain traction.

Me too! As a developer mostly with desktop software development experiences, htmx is so much straightforward to understand and easy to code, it's a perfect chose for me to implement pages such as 'License Upgrade', 'License Renew', and so on: https://docxmanager.com/miscpages/upgrade-to-standard-from-b...

Re: If Not SPAs, What?

#295

Post by theshrike79 »

throwaway189262 wrote: post #274
randomsearch wrote: post #261

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…

Not even Java applets, but Silverlight.

Hoo boy it was awesome to work with. But. It came out at the wrong time. Linux was coming up as a desktop, MS was still evil. Mono was mostly a hobby project.

The backlash of trying to use "proprietary M$ crap" for web was too big of a hurdle to cross, even if the technology behind Silverlight was lightyears ahead of the drek that was Java Applets.

Re: If Not SPAs, What?

#296

Post by danjac »

TameAntelope wrote: post #188
cutler wrote: post #127

Earlier quoted context omitted.

This is the main reason I refuse to entertain going perm in the tech sector. The amount of superfluous infrastructure and unquestioned use of SPA's is just an overwhelming time sink. I would honestly rather work with some 2-bit company's legacy PHP than this mountain of crap.

For what it's worth, once you are proficient in the full end-to-end, navigating it is pretty easy, IMHO. It just takes years and lots of room to do basically nothing, and if something meaningfully shifts, you need a while to get back up to speed. I'm not saying it's efficient, or that you should dive in, but I did want to throw out there that there is a light at the end of the tunnel. People using React.js aren't fla…

> It just takes years and lots of room to do basically nothing, and if something meaningfully shifts, you need a while to get back up to speed.

If true, that's a damning indictment of the industry and the whole SPA pattern.

Re: If Not SPAs, What?

#297

Post by TeMPOraL »

buzzerbetrayed wrote: post #219
cblconfederate wrote: post #35

Earlier quoted context omitted.

That's not possible for SPAs outside localhost. Every single SPA i know is clunky, including gmail which is probably one of the most barebones. The lack of visual indication that something is happening or downloading alone is infuriating with SPAs. Most of them reinvent the browser in a very poor substitute that invariably fails to both be practical , and to mimic a native mobile app (i think the latter is the reason…

SPAs are like CGI.. you only notice it when it is bad. I can assure you, you use many SPAs that are not slow and clunky, you just don't realize they are SPAs

Name three.

Because like other commenters that chimed in, I can notice most SPAs, and all SPAs I've used had annoying performance problems. By problems I don't mean a sudden request that takes half a second, but that every UI interaction feels subtly slow.

I don't know where people get these performance targets of "below 100ms and users won't notice". I notice. I notice if UI responses take longer than two-three animation frames, the same way I notice when a game is running at 20 FPS and not 60 FPS.

Re: If Not SPAs, What?

#298

Post by TeMPOraL »

nullsense wrote: post #36
zmmmmm wrote: post #12

My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…

I thought 100ms was basically the threshold for feeling "instant"? But totally agree with your position on this in general!

It's a crap threshold. 100ms is 10 FPS. You can most definitely tell when something is updating at 10 FPS, vs. 20 FPS (50ms). Movement stops being jarring at ~30 FPS (33.3ms), but you can most definitely tell apart that and 60FPS (16.6ms).

Re: If Not SPAs, What?

#299

Post by ratww »

rawoke083600 wrote: post #240
switz wrote: post #134

Earlier quoted context omitted.

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly l…

I definitely agree you, F.E Tools has gotten a lot more mature and we have a lot further to go as well. I'm primarily a backend developer and I think in general backend developers makes for "poor fronted devs". I'm talking about those "occasional" times the backend-dev needs to do some f.e dev work. Just because they don't know the tech as well, best practises and spend as much time with it as a dedicated F.E Dev. jQ…

> If you are a shop with mostly backend-devs and don't want to invest in a F.E dev, you definitely should look into a js-framework.

That matches in my experience.

I worked in a shop with only backend developers and the frontend was an absolute buggy mess of jQuery on top of bootstrap. After migrating most of it to Vue I taught it to the team and all the experienced-but-frontend-shy developers started producing great frontend code by themselves.

Re: If Not SPAs, What?

#300

Post by TeMPOraL »

hnick wrote: post #205
solipsism wrote: post #176

Earlier quoted context omitted.

How often do you deal with blitting textures into vram when working on your web applications? If not very often, that means you're building on top of a stack of software that includes a rendering engine, equivalent in many ways to Unity or Godot.

> you're building on top of a stack of software that includes a rendering engine Yes that's pretty much a web browser, isn't it? There are many types of engines, such as a business logic engine. The distinction between engine and framework is a little vague but what I'm getting at is the low-code interacting-components design approach, rather than code first. I'm wondering why that hasn't taken off. People use Godot…

Games aren't low-code. Even with UE4, people end up learning C++ because there's only so much you can do with the Blueprint flowcharts before it becomes an unmaintainable mess that grinds your development speed to the ground. It's also pretty much a law of nature that every nontrivial game eventually develops a scripting language (unless it's already written in one, e.g. Python).

But it's absolutely true that you can teach artists to code - within the limited domain - much easier than you can teach programmers to draw or write stories.

A personal opinion: I'm not entirely sure that being entirely art-driven is necessarily a good direction for games either. You can build a pretty game out of default UE4/Unity/Godot building blocks, but it'll be rather quickly recognized as a cookie-cutter game with custom art. If you want to innovate on, or even carefully tune, the gameplay itself, you need to code your way out of engine defaults.

Post reply on HN