Live data from Hacker News

If Not SPAs, What?

macwright.com

421–430 of 456 posts

Re: If Not SPAs, What?

#421
post #149

Earlier quoted context omitted.

For all the speed bumps PHP 7 delivered Laravel typically scores lower than Django and Rails on Techempower benchmarks. This and the reality that PHP roles typically pay 20% less than Ruby, Python or Node has led me to ignore Laravel.

I haven't built anything that requires significant performance tweaking other than some caching and SQL optimisations. Maybe PHP 8 will bring an even better performance when it gets released > HP roles typically pay 20% less Yeah, true. Hence why I am a React dev professionally

I'm not saying any of Django, Rails or Laravel are fast compared with Node, ASP.Net or Spring but what surprised me was how PHP 7, which is a lot faster than Ruby or Python, somehow managed to fall behind when Laravel was added into the mix. It's as if PHP's performance gains only really apply to raw PHP or lightweight frameworks.

Re: If Not SPAs, What?

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

Food for thought: the tech sector is much larger than the trendy dumpster fire of web development. You don't have to work at some startup on some website. There is still lots of real programming to be done.

What are the real growth areas? I'd welcome an exit from web development but as a freelancer it seems to be all there is.

Re: If Not SPAs, What?

#423
post #316

Earlier quoted context omitted.

> 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. When you remove the warts from JS there's not much left. And I'd be pretty skeptical of someone starting a new project in Lua today. I think the mainstream choice for a "blank slate" language today would look something like Swift or Kotlin; Typescript can gets close, but it…

> When you remove the warts from JS there's not much left Modern JavaScript is pretty sweet to write compared to pre 2015. It sure is fun to join in on the "JavaScript bad" circle jerk though.

> Modern JavaScript is pretty sweet to write compared to pre 2015.

That's damning with faint praise if I ever heard it. JavaScript has more or less caught up with the lowest common denominator of other languages. But I've yet to hear anyone make a good case for actively choosing to use it.

Re: If Not SPAs, What?

#424
post #310

Earlier quoted context omitted.

> I still see factories on a daily basis. They are a useful design pattern that is utilized in Java. A separate factory type means you have to write twice as much code for no real benefit. In most languages you'd just use a first-class function (and in post-8 Java you can do the same: rather than a FooFactory you accept a Supplier and people can pass ::Foo . It's still more cumbersome than in most languages though).…

> A separate factory type means you have to write twice as much code for no real benefit. Ah! There's the confusion. What I meant was I see factory methods in code we consume on a daily basis, not that we write the full factory objects. A number of Java projects have static factory methods that provide the interface implementation instance based on your configuration. Would you still object to this kind of design?

If you're actually using that configurability (i.e. your method actually instantiates different implementations in different cases) then no - that's the same thing you'd do in any language. If you're pre-emptively defining factory methods that actually just call the normal constructor then yes (a lot of Java bloat is like that - see also getters and setters on every field for the sake of the 0.01% where you actually want to do something other than just read/write the field).

Re: If Not SPAs, What?

#425

Earlier quoted context omitted.

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…

HTML was never meant for building apps. We took a square peg (document markup language) and jammed it into a round hole (app development.) Most of the problems and frustrations with web development go back to this.

We've been using the wrong tool for the job for over 2 decades. Now it's everywhere and nobody knows any better. It's probably too late now.

Re: If Not SPAs, What?

#426
post #50

I've had great success with the Turbolinks + Stimulus approach. There are a couple of common patterns that you'll reach for, namely, lazy loading content (basically a with a URL attribute that you have Stimulus load via AJAX) and really leaning into Rails remote-link / server javascript responses for modals and little page updates. It's so great to still be super productive and be able to crank out several pages of a…

This is my go-to as well, and it really has worked out quite well for me. Everything feels super responsive and I find it very easy to create reusable stimulus controllers.

I come from the "js sprinkles" approach that rails has always favored, and this feels like a logical next iteration. I sometimes wonder why Basecamp doesn't publicize Stimulus a bit more; I really only learned about it at rails conf. It feels almost like it could be a part of rails itself, and it's the kind of thing that is useful for almost any full stack rails app that does server side rendering.

Re: If Not SPAs, What?

#427
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…

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…

Biggest problem with templating libraries like mustache is they aren’t context aware, so it is up to the programmer to remember the proper way to escape based on where a variable is used.

Re: If Not SPAs, What?

#428
post #344
post #336

Earlier quoted context omitted.

> My experience is that LiveView is fine for all but the last use case. I wouldn't want to impose a 50-500ms+ delay on someone to show a menu drop down or a tooltip or most of the other things listed out. With LV everything involves a server round trip. That's great for when you need to make a round trip no matter what (which is often the case, such as updating your database based on a user interaction), but it creat…

> My experience is that LiveView is fine for all but the last use case. >> I wouldn't want to impose a 50-500ms+ delay on someone to show a menu drop down or a tooltip or most of the other things listed out. It's basically a UX standard that a tooltip only shows up after a few seconds, so that strikes me as a particularly bad example. That said, sure, if instant tooltips are important, a tiny bit of js and a specific…

If you preload, where does LV introduce latency in that tab example?

Re: If Not SPAs, What?

#429
post #397

Earlier quoted context omitted.

I'd say Eloquent Javascript (available for free online, I think) is a good book to read. "You Don't Know JS" is also a good one! Basically, go for anything that teaches you non-js-specific approaches as well as as a solid understanding of the fundamentals.

Thank you! I'll check both of those out

And Crockford’s JavaScript: The Good Parts. Although and older book, JavaScript fundamentals never change and it describes a lot of those forgotten foundations.

Re: If Not SPAs, What?

#430

Earlier quoted context omitted.

> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because t…

Redux is not idiomatic JavaScript though. It’s trying to make JavaScript immutable and have adt which it doesn’t. If you use elm, reasonml, rescript, etc this pattern is a lot easier to implement than with JavaScript.

Yup, it’s beautiful in Elm and makes no sense in JavaScript, which doesn’t need it.
Post reply on HN