Speaking of code duplication in a traditional web app every page is an example of code duplication. How about that?
Escaping the SPA rabbit hole with modern Rails
71–80 of 137 posts
Re: Escaping the SPA rabbit hole with modern Rails
#72The main problems addressed in my opinion:
- Code duplication between server and client side
- Added complication threw data transmission between server and client (REST/json)
I think, both problems can be addressed by:
- having (a single) code that works both on server and client-side
- having transparent transport mechanisms for information between client and server.
I am sure, I could implement such a thing for Python/Django, using the already existing tools. But I am not sure, if such a thing would be appreciated by the community.
What do you think?
Re: Escaping the SPA rabbit hole with modern Rails
#73Using a framework like the F#-to-JavaScript transpiler Fable, along with an application framework like Elmish, provides a really good solution to some of the pitfalls cited in the article (prescriptive architecture, front + back-end code sharing) and gives you some moderately strong type safety to boot.
However, the article author's list of SPA pitfalls is really good, and are probably not all surmountable by a framework/platform.
Re: Escaping the SPA rabbit hole with modern Rails
#74I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify your true need, lest the cure be worse than the disease. Most developers of a certain age have come up when it's SPA by default, and can't truly defend why they need it. In this thread, there are several claims that it's impossible to write well-organized jQuer…
Sounds like you haven't been introduced to reagent. https://reagent-project.github.io
sounds like you didn't actually understand the parents point.
Re: Escaping the SPA rabbit hole with modern Rails
#75There was probably a few valid points, but the article was too long with too many flimsy, "try-hard to convince" arguments.
Re: Escaping the SPA rabbit hole with modern Rails
#76Earlier quoted context omitted.
As a user my main beef against SPA is that most of the time they break basic browser functionalities, like the ability to open links in a new tab, or using the back button. When the UI doesn’t simply break with part of the content off-screen.
Having built some SPA's, I'd argue that at least those two things that you mentioned are the fault of whoever built bad SPA's, rather than issues with SPA's as a whole. It's possible to build an SPA that works well with the browser controls because modern browsers expose a lot of their functionality to JavaScript (like it or not). You can use tags for buttons and links in an SPA (and keep the link functionality) -- y…
Would you say Youtube works better now as it is fully SPA?
Re: Escaping the SPA rabbit hole with modern Rails
#77Earlier quoted context omitted.
As a user my main beef against SPA is that most of the time they break basic browser functionalities, like the ability to open links in a new tab, or using the back button. When the UI doesn’t simply break with part of the content off-screen.
Having built some SPA's, I'd argue that at least those two things that you mentioned are the fault of whoever built bad SPA's, rather than issues with SPA's as a whole. It's possible to build an SPA that works well with the browser controls because modern browsers expose a lot of their functionality to JavaScript (like it or not). You can use tags for buttons and links in an SPA (and keep the link functionality) -- y…
It is an issue with SPAs as a concept because part of that concept is that you’re taking on responsibility for things the browser traditionally did for you.
That’s not a bad thing but it’s extra work which someone has to be responsible for, similar to how e.g. using a complex custom widget means you’re on the hook for accessibility rather than the browser vendors.
Re: Escaping the SPA rabbit hole with modern Rails
#78Earlier quoted context omitted.
Uh, you can definitely implement a standard CRUD app with one of the serverless platforms. You can even throw an entire expressjs application into a lambda function with minimal modification if you want.
> You can even throw an entire expressjs application into a lambda function This is the first general misconception with serverless. Serverless is not lambda . If you think serverless == lambda, it's like saying cloud == ec2 . You're missing the point of it.
than please define serverless for us.
using lambda and its equivalent is - in my understanding - the definition of serverless. You might not be able to utilize the biggest advantages of serverless infrastructure if you combine it with a standard ACID database backend, but it should still be a serverless deployment.
Re: Escaping the SPA rabbit hole with modern Rails
#79I have to admit, I do not know Turbolinks well, but I feel like the author misses something fundamental about the benefits of modern frameworks. It's not just about building a giant SPA - component-based design is a huge value proposition. The problem I see at the moment is that client side "apps" - however they are rendered - hit a wall in complexity that is really hard to overcome without a a sane and sensible way…
> Just like every sane regular programming language has concepts of classes or modules or some kind of system for divide-and-conquering problems into pieces, your front end needs that too once it gets complex. And that's what these React/VueJS frameworks are doing for me.
One question which should be included in that is whether you need a huge framework and supporting toolchain or just ES6 classes. There’s a good argument that using standard features will last you longer than frameworks which rapidly go in and out of vogue, and it avoids the constant frictional support costs of regular forced upgrades and debugging complications.
Re: Escaping the SPA rabbit hole with modern Rails
#80Without any input from me and several other js devs in our org, it was decided that we'll do a complete rewrite of our Ember.js app in React. The primary reason stated was hiring and the secondary was build times. The first should have been performance but they've been pretending like performance doesn't matter and that it's good enough. It's not. Since it's easier to develop, our backend admin system is built in .NE…
> wouldn't need QA at all if we wrote tests.
If this is true, you’ve been doing QA wrong. A good QA team will catch gaps in the developers’ thinking, not just click buttons like robots.