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

381–390 of 456 posts

Re: If Not SPAs, What?

#381

Post by CptFribble »

pwdisswordfish4 wrote: post #360
rlt wrote: post #269

Earlier quoted context omitted.

This is very vague. Can you give some examples?

The question asking for clarification is itself vague. Examples of which part? Look at JS that's written for serious applications today, identify the stuff that you'd label as "idiomatic", and then look at code that was written 10 years ago for serious applications, and see if it matches what your conception of "idiomatic JS" is. Good references for the way JS was written for high-quality applications without the neg…

Hi, I'm also a new JS coder, but I'd like to avoid becoming one of "those people" you're talking about. I've been struggling with exactly what you mention - how to find out the "correct" way to apply patterns/do relatively complex things, but all I get on search results are Medium articles written by bootcamp grads.

Can you recommend any sources of truth/books that can guide down the right path? Of course I'll be going through all the things you mention but I'm just curious if there's somewhere I can get the right information besides just reading through Firefox code, for example.

Thanks!!!

Re: If Not SPAs, What?

#382

Post by recursivedoubts »

dinkleberg wrote: post #355
tapvt wrote: post #147

Earlier quoted context omitted.

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

How do you handle things like menu pop-ups and toggling/hiding content? I keep wanting to use htmx and it's like, but there always seem to be very common tasks like having an expandable menu on mobile that don't have a great solution in these libraries and I have to write vanilla JS. I've settled on Alpine instead for the time being because it has some data management built in. I'm thinking I'm going to have to switc…

htmx is focused on increasing the network-oriented expressiveness of HTML, rather than on pure front end enhancements.

For something like menu popups or toggling content on the front end, I would expect an application to use a front end framework like bootstrap, or perhaps WebComponents, or a scripting solution like Alpine, in conjunction with htmx.

Alpine and htmx complement one another nicely, particularly since htmx 0.2.0, when we started firing kebab-style event names.

Re: If Not SPAs, What?

#383

Post by exabrial »

There are very few SPAs that are tolerable. Even Google can't make a good one, their admin console for GSuite is terrible and has latency out of this world.

Re: If Not SPAs, What?

#384

Post by dugmartin »

mercer wrote: post #334
dugmartin wrote: post #92

Earlier quoted context omitted.

I've been playing with LiveView myself for personal projects and it is very nice. One interesting thing is that it makes you consider memory issues again since all your rendered data structures are held in memory in the LiveView process unless they are explicitly cleared after the render with "temporary_assigns". For apps that would have to hold and transfer a lot of data up and down the channel I've ended up using a…

I'd say that's the main (potential) 'problem' with LiveView, alongside latency issues. In practice, I've usually found that the advantages outweigh the disadvantages when it comes to the former. Beefing up my servers seems like a worthwhile trade-off. When it comes to latency, or related issues, I find that I'm still so much better off using LV as a basis and 'dropping down' into plain JS or (p)react when I need it.…

I'm still using LiveView in a lot of the other parts of the app - places like signup/signin where the having the form validation seamlessly done server side using changsets is very, very nice. I'm also using in places where I would normally have to expose an api endpoint for CRUD and instead I'm using events and handling it in the LiveView. Again, very nice.

Re: If Not SPAs, What?

#385

Post by marcus_holmes »

cateye wrote: 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…

I don't think it's developers tbh. Or rather, it's another set of perverse incentives in the industry.

To get a job, devs need experience in relevant tech. No company is willing to train their devs - they all have to hit the ground running. So devs have to have demonstrable experience in the tech that lots of companies use. Companies need to hire devs, and don't really care what tech is used. But using what everyone else uses makes their hiring easier because it's easier to find devs who want to work on that tech. So they advertise for devs with experience in a hot tech. The devs see this and try and move their internal projects to use the hot tech so that if/when they look for their next job they'll have experirence in it.

The devs are just trying to stay relevant in a rapidly changing tech scene so they can get their next job.

The companies who employ them don't care what tech is used, but find recruiting devs to be easier if they're working in the latest hot tech.

The key point that could change all this is if companies were willing to train their devs in the tech stack they're using.

Re: If Not SPAs, What?

#386

Post by thu2111 »

doctor_eval wrote: post #285
avereveard wrote: post #265

Earlier quoted context omitted.

> Frontend tooling has never been better than it is today. eh. Swing in its golden age run circle around what we have now. Granted it's old tech now that we settled for in-browser delivery, but still: - look and feels could do theming you can only dream of with css variables/scss - serialize and restore gui states partially or whole, including listeners - value binding systems vue can only dream of - native scrollers…

Not to be mean, but I worked with Swing for ten years and it was absolute crap. Constantly dealing with resizing “collapsars”, GBLs, poor visual compatibility with the host OS, a fragile threading model and piles and piles of unfixed bugs and glitches was a nightmare. It might have worked if you had a specific end user environment but it was a PITA for anything else, and deployment was even harder. There are a few th…

Give me HTML+CSS+JS any time.

Sure! And Chrome is superbly tested.

But HTML/CSS/JS aren't anywhere near good enough to build GUIs of any complexity by themselves, so everyone layers tons of stuff on top. And then those ... those, people have plenty of complaints about too. But if they didn't use them those complaints would migrate to the underlying framework.

I mean, Swing may have had a fragile threading model (not sure what you mean by that really), but HTML doesn't have one at all. Not great!

Re: If Not SPAs, What?

#387

Post by Nextgrid »

aitchnyu wrote: post #357
Nextgrid wrote: post #183

Earlier quoted context omitted.

Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.

What about interpreted languages? I was taught a Python web server can do $NUMCPUS+1 concurrent requests and therefore 32 1 CPU VM will perform as well as a 32 CPU VM.

You still have the overhead of the OS. In the first case you’re running 32 instances each with their own OS, the latter you have a single OS to run.

Unless high availability is the concern, I’d always recommend a big machine with lots of CPUs than lots of small ones.

Re: If Not SPAs, What?

#388

Post by ryansolid »

It's worth pointing out MarkoJS it was basically made for this case for eBay's eCommerce solution. It predates the Next.js of the world but offers similar experience except it's MPA first mentality with seamless isomorphic experience and full working partial hydration for years.

https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-...

Re: If Not SPAs, What?

#389

Post by ng12 »

blakehaswell wrote: post #217
ng12 wrote: post #2

If you can do server side great: do it. The difficulty is accurately predicting how much JavaScript you'll end up writing. If your client-side JavaScript is comparable in complexity to your SSR you'll eventually end up with the worst of both worlds.

I'm not sure that's such a huge problem. HTTP routing provides a wonderful architectural seam so that we can use different solutions for different domains like `/profile` and `/document-editor`. We can create rich client-side experiences without creating a monolithic SPA. And as long as we make sure we have those architectural seams we have the flexibility to decide.

Organizing my HTML into pages is the easy part. The hard part is the rich client-side experience: things like building a sortable/filterable table with a rich datetime picker where the data is displayed dynamically in a chart with zoom/pan capabilities. That's why I build SPAs: I've already bit the bullet to get highly dynamic client-side code, it's just as easy to construct my pages client-side as well.

Re: If Not SPAs, What?

#390

Post by dinkleberg »

recursivedoubts wrote: post #382
dinkleberg wrote: post #355

Earlier quoted context omitted.

How do you handle things like menu pop-ups and toggling/hiding content? I keep wanting to use htmx and it's like, but there always seem to be very common tasks like having an expandable menu on mobile that don't have a great solution in these libraries and I have to write vanilla JS. I've settled on Alpine instead for the time being because it has some data management built in. I'm thinking I'm going to have to switc…

htmx is focused on increasing the network-oriented expressiveness of HTML, rather than on pure front end enhancements. For something like menu popups or toggling content on the front end, I would expect an application to use a front end framework like bootstrap, or perhaps WebComponents, or a scripting solution like Alpine, in conjunction with htmx. Alpine and htmx complement one another nicely, particularly since ht…

Ah for whatever reason I always saw this as an either-or scenario, not in tandem.

That gives me hope as I’ve wanted to use htmx on a project. Gonna start playing around with it tonight. Thanks!

Post reply on HN