Normally you'll always need to add something interactive, therefore js. To do that with server side rendering you'll couple the client side to the server side.
For example the server has to send a tag with a class name that the client also is aware of that.
Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.
I think old.reddit.com's interface is more user-friendly than HN's. Why should I leave the page to write a comment? Avoiding JS just for the sake of avoiding is just blind fanaticism under the pretense of being faster and more lightweight.
(The new reddit redesign is a resource hogging abomination riddled with needless SPA bullshit, but the old reddit design was pretty clean and minimal and yet an SPA.)
I think the definition is a bit murky there. I can do a _lot_ of things on a Reddit page without a refresh: add comments, delete comments, edit, sticky, report as spam, save, hide the post, view the contents of the post (if it's an image), crosspost to other subs, etc. I understand that a true SPA would never require a refresh for anything, but this comes pretty close.
You can get surprisingly far without Javascript, imo. Interactivity means a lot of different things, do you won't always need to have coordinating front and back ends
...? "Most of the world is fine with whale oil lamps, who needs electricity"
Try a really good interactive article from the New York Times. You'll have a much more impactful experience than if you read a blurb about the same thing on your RSS reader.
That's why I think these conversations are so meaningless. My job would be a nightmare if I didn't use SPAs. It's all about the right tool for the job.
While I've long been more comfortable with server rendered pages, I feel like we're oversaturated with this sentiment. I don't think it matters all that much.
The message is build with what accomplishes your goals and works with your team's skills.
The notion that SPAs are only good for certain types of applications or organizations doesn't make much sense to me.
Building server-generated web sites works faster for me because I'm still more comfortable with it. SPAs make concessions but so do server generated apps.
> The message is build with what accomplishes your goals and works with your team's skills.
Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools.
>Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools.
Force them to only use simple tools and the good ones will move elsewhere because they know that being stuck on just the simple things is going to limit their careers.
edit: And losing them will probably cost you more project velocity than you'd ever gain with different tools.
Good riddance! A project is undertaken to achieve some specified result, not to advance a career or learn some new tool. Don’t get me wrong: those lofty things are welcome when they occur as a byproduct of developing commercial software, but these cannot be the driving factor behind decisions that affect the bottom line.
Part of working with humans and managing humans is understanding they're human and not machines. And keeping those humans happy does very much impact the bottom line. If spending 20% more effort on a project retains engineers that speed up projects by 30% then it's a net gain for the business. Bad companies and managers don't understand that and then wonder why all their engineers are bottom of the barrel (or rather why their projects end up such disasters while those of their competitors don't).
Google does, but not reliably, especially for newer (ES6) JavaScript features. Bing and DuckDuckGo do not render complex JavaScript apps. Neither does Yandex, I believe.
In theory google can crawl SPAs, but in practice it doesn't work all that well. Server side rendering is one solution, a pre-rendering proxy is another.
Not by default. The big frameworks are first and foremost client side frameworks, which means in an extreme case the server is just sending down <html><script src=.../></html> (basically), and the client framework handles all of the rendering/data fetching.
BUT — with a bit of work, you can set things up to do server side rendering. It requires you use Node at some point in your server stack, and you essentially call the library (on the server) and run their RenderToString function (each has a slightly different implementation).
There are frameworks for this (next.js, nuxt.js) or you can roll your own - it’s not terribly complicated.
You simply do not make SPA on crawlable URLs, so that's not a problem. You use SPA when the page is behind authentication and is customized for the user.
I'm more interested in the future of "you probably don't need a native app".
It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there.
I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
How's that working out when there's more than one browser you have to account for? What's the difference between polyfill or some framework, and something like Qt or SDL?
Or I suppose we could just all use chromium, but we could also just all use Windows.
Consider that maybe there are uses for software where the web isn't necessary and isn't even the first choice.
You're a hammer, so everything is a nail. The reality is that the web is a horrible choice for a whole lot of things. It's a document platform with parts of an application platform shoe-horned in and bolted on, and the result looks like a garbage fire to people who come from the land of native software.
I'm not sure I understand why browsers getting closer to native apps ruins anything for anyone else. You're still able to hammer your nails however you want.
> What's the difference between polyfill or some framework, and something like Qt or SDL?
As a user, I usually can't even tell when they're using a polyfill on the web (except when they stop, like GitHub did with type=date). (As a developer, I often can't tell the difference, either. Some of them are that good!) So long as you generate HTML/CSS/JS, it doesn't matter to me how you do it. That's as 'native' to the web as you can get.
I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right. It's frustrating to use, and I always slow way down and double-check my work because, e.g., popup menus show the 'accept' animation even when you cancel them.
It's equally possible you're doing the same thing by forcing users to download a native app. It's kind of hard to talk about in the abstract. Some things work better in an app, for other things it adds nothing notable.
Not sure exactly what you mean by React NativeJS but perhaps React Native for Web (https://github.com/necolas/react-native-web) is along the lines of what you are thinking?
Works remarkably well. It’s already used for Twitter’s mobile site
I'm sure it's nice for you, but users like me aren't happy that every mouse move and page load is cataloged and studied and shared with partners. At least with a native app I can add a firewall rule to restrict it's ability to use the internet.
Native has downsides too, like having almost zero control over the client and being unable to link other people like you can on the web. Just a bunch of silos by design.
Native is only a trade-off that has great performance at other expenses.
Not always. There are times when you don’t want to download an app for every little thing, though the opportunity to be able to do so is nice. There’s a reason we have browsers and not just everything coming through in its own individual app.
It's in Googles interest as everything they deliver is through the browser. Not so much for Apple or Microsoft though. Personally I will be quite sad if I end up loosing so much control over my computing environment.
That’s much higher than I’d have expected. I wonder how much of it comes from games and their in app purchases, a segment that is unlikely to take much of a hit from moving other apps to the web.
Native apps allow Google to collect much more information than they can via the browser. They also allow for a wider range of advertising opportunities.
They don't need to show you ads in their apps. They just use them to collect your data, like where you are every moment of every day and use that data to better target ads.
Android and Google Search are completely different Google departments. They will fight for the audience as long as they won't directly compete with each other. Board can see this as a widening audience, cementing presence and reaching new markets. It's in the best interest of Google Search and Chrome to push browser apps ahead.
Google's services are incredibly convenient and well made, and you may be assuming people will give up those conveniences. That's a big assumption and I think it wont pan out that way.
This is the only reason we have an SPA to begin with-- small team writes a single frontend and deploy to web, iOS and Android via Cordova, Windows via Electron, and (previous) Chrome OS via the now deprecated Chrome App APIs. If we didn't need to support the full experience on all these devices, SPA would be way overkill.
I didn't view WASM on its own as the big differentiator. But, it is one of many things that's closing the gap between native apps and web apps. As you mention, it's useful in some situations.
As browsers close the gap they simply become the OS but slower, more abstracted, and with less security. And they stop being good browsers. It's the old emacs situation come round again.
The only positives are to corporations and institutions with profit motives to decrease dev time and increase ability to spy on users and extract rent from them.
> As browsers close the gap they simply become the OS but slower, more abstracted, and with less security
Browsers are forced to implement standards like CORS, single-origin policy, and multiple levels of SSL certificate validation and thus are more secure than most of native apps. How do you know whether that mobile app is not signing in over HTTP? In a web browser it's obvious instantly.
> motives to decrease dev time and increase ability to spy on users and extract rent from them.
Literally the worse what can happen over web browser is tracking based on various forms of fingerprinting. Native apps? MAC addresses, SSIDs, serial numbers - EVERYTHING is available for the native app to send ANYWEHERE, even over HTTP.
> they simply become the OS but slower, more abstracted, and with less security.
I agree with slower, at least for computational tasks, but not security. Do you feel safer installing an organisation's native app than using their web app?
> The only positives are to corporations and institutions with profit motives...
What advantage does the web give to corporations that native apps don't? You mention spying, but the native mobile app ecosystem is filled with tracking and analytics code (and it's easier to hide it). The only corporation-level difference I can see is that native apps are heavily tied to a specific company's platform, while web apps aren't. This is a huge positive to the web - I've felt free to change platforms many times.
A second huge and underestimated positive of the web is backwards compatibility (ie. lower maintenance headaches). A complicated internal web app I wrote eight years ago is still running despite not being modified. The websites and lousy javascript I wrote as a kid in 1999 still run exactly the same as in 1999. Spacejam.com is unmodified from 1996. Yet I have many native apps from two years ago that no longer run correctly due to OS updates (especially on mobile).
This feels like clickbait, but just as an aside there's nothing that says you can't do server side rendering and react. Next.js is what I'm using on my current project and it's server side out of the box. So you have text rendered in source like you would with a traditional server side app with the benefits of SPA. So at least one of his nitpicks sounds like he didn't do his homework.
I mean, not really? When you want a new page you create a react component in the "/pages" directory. "/pages/hello/index.js" routes to "mysite.com/hello", and "/pages/hello/there/world/index.js" routes to "mysite.com/hello/there/world". The pages are served from a node.js site. The newest version (8) comes with lambda rendering but you don't have to use it if you don't want.
The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into sh.
Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is a button that will open a popup with another form, dynamically generated based on what you choose. Or maybe there is data you must dynamically fetch from the server, based on some combination of actions that the user did.
You can play the ".show()" and ".hide()" game with plain JS, but if you have more than 5 inputs, I promise you, you'll be really sorry for choosing that method.
You can also "inject" somehow any SPA just into that particular view in your project, but then you'll be already dealing with the cons of both SPA and SSR. It doesn't pay off.
I have been doing all types of FE and BE development, and what has given me the best results is making the BE a REST API and doing the rendering on the frontend.
This is where the hybrid approach they mention in the article really shines. Embed front end frameworks where you need it, and stick to SSR where you don't. It doesn't have to be a binary choice.
Yes, that's what I said in my comment. But if you choose that path, you automatically have to deal with the problems from both worlds. "How do I configure webpack?", "Why is babel not working?", "How do I do _this_ or _that_ in React or Vue or whatever?". Going the hybrid approach is choosing to deal with the problems from both worlds.
But configuring webpack is usually just an initial set-up cost. I've never had to go back and rejigger webpack once it's set up. You might have to touch it again if you make major changes to how you serve assets or something, but these one-time costs are part of development.
> Going the hybrid approach is choosing to deal with the problems from both worlds.
This is true of any technology. Every framework, language, library, etc. comes with a cost in setup, design, maintenance, etc. For us, the cost of dealing with problems from both worlds is much, much lower than trying to shoehorn a SSR app with SPA-like functionality. By limiting the size and scope of the SPA, you avoid a lot of the really hairy state management problems that can arise when an SPA is trying to keep track of too much state.
My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful.
Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well.
Since the announcement, our productivity has diminished dramatically since so much of our time is now focused on re-working functionality that already exists into an SPA, and it's completely unnecessary. Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks, and we're definitely going to make mistakes along the way that we weren't making before.
It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients, when 99.9% of our clients have no idea what an SPA is. And the amount of money being spent on turning already-working apps into SPAs is astronomical.
I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all.
Compared to client side rendering discrete web requests with minimal templates; you usually get much better separation of logic, view, and code than the typical serverside solution.
There is a happy medium where server side services are encapsulated to separate concerns in a similar manner, but it rarely happens, even with competent, experienced, well intentioned teams.
Indeed, that's true. While I'm not saying they're good for everything, one thing I like about SPAs is that the server can just serve up an API that is usable by both web and mobile clients. No duplication of templating/view logic between server and client as often happens when the server is serving up HTML.
I could make the reverse argument: bad frontend programmers who dont use the facilities available to separate concerns create unmaintainable spaghetti when good backend programmers who separate concerns properly produce beautiful maintainable code.
The key being bad programmers dont isolate concerns and good ones do.
It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.
But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together.
With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.
>Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.
IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro.
SPA doesn’t guarantee good separation of concerns though. I have seen many a horrible SPA in my day that had all the business logic in the client side JS and zero validation server side. Server basically a very thin wrapper around the database.
I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.
Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.
This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.
I'm not sure I buy this. I recently worked on a project where we had one .net core developer, a dev ops guy, and me doing the client SPA. We were all able to focus on our core competencies and turn around the project incredibly quickly. I would argue that you can get away with the same team size split between front and back end and possibly end up with a more efficient allocation of resources.
Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win.
That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.
That's a hell of a generalisation, and it falls down pretty fast when you move beyond CRUD apps. You can easily end up with entire teams whose role is just to babysit Elasticsearch.
Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API).
Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort.
It depends... but it is always less effort not maintaining an external user facing UI.
Well, what does your API actually do? If you're e.g. Heroku, your front end does almost nothing in comparison to the rest of your product. Why would running the backend of a globally distributed infrastructure-as-a-service company be easier than maintaining the front end?
I think the counterpoint to this would be Google Search. The core product is incredibly simple from a frontend perspective, but the backend is world-class engineering.
I think making information usable is hard. This means that the burden of the development falls on whatever is making the information useful. If you simply can query an API and get stuff back that's valuable because the data is already processed, UI is pretty easy (aka Google). If your backend is returning raw data that needs to be organized and displayed, and users need to be guided through complex processes that are just simple CRUD operations server side, you have a much harder UX/UI challenge. Most things fall somewhere in the middle.
Two teams sharing an interface means one team will block the other most of the time if a new feature always requires changes in the interface and implementation on both sides. Doesn't matter if individual development speed increases, overall project speed will suffer greatly.
One reason the SSR mess is so easy to walk into is that everyone knows it's a reasonable amount of refactoring to get out of later. The cleanup of an SSR app lacks the deployment headaches of SPAs (doubly so with the service worker layer).
> I would note that generally server side templating is often a mish mash of business logic
If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...
TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less.
It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want.
We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.
> TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less.
I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner.
Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.)
Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.
>Plus you've got the extra layer of an API to maintain too
On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.
Possibly, though your perfect API design may differ significantly from your perfect site structure. It feels reasonable to consider both and see it as a positive if the use cases work.
This is also the main argument that keeps me on the side of SPA for our own project, at the moment. Our product is a specialized database with a fancy GUI on top, but we have customers that only use the database through its API; by using it ourselves for our frontends we make sure everything is doable that way.
The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...
Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.
I definitely view being forced to build a sane API as one of the perks of a SPA. Having worked on some PHP pages with SQL queries, HTML, CSS, & JS all in a single file you would be surprised how people fail to separate concerns when they aren't forced to.
How would you make it "even more complicated, and more likely to spaghettifi" to maintain an API than having to maintain a rich UI. Now that's a load of nonsense, or at least very misguided hyperbole.
I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose.
Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions).
The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong.
I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.
Hi, I'm a Redux maintainer. Any specific concerns that I can help with?
You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:
After having some pretty extensive (heated) debates about the merits of redux here on HN, I've come to the opinion that the love/hate for redux is a consequence of the departure from MVC architectures that more experienced developers are accustomed to. There are decades of best practices built up around scaling object oriented MVC architectures, but react and redux come from a completely different school of programming where trying to apply traditional inheritance patterns is impossible and can mortally wound a project.
There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary:
> Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity.
It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile.
So I could see an issue with someone writing business logic in a view and then someone else rewriting that business logic somewhere else slightly differently.
But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside.
I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.
Not contradicting you, but how did you evaluated that the SPA is not bringing any value to the customers? It may make work harder for you, it may cost more, but maybe that cost is rightfully justified from a business perspective.
As a consumer of SPAs all across the internet, all I seem to get is a bunch of janky, slow, bloated, buggy experiences. Server-rendered views just seem more performant and reliable when done well.
Same issue at the previous company. Engineering team decided to turn the web app into SPA, and spent months doing this. All that time which could have been spent on building customer value were wasted.
Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation.
We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it.
While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc.
The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it.
> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it
If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever).
I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders.
I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make sure we could cover their functional needs. It was a rule-based system for validating and analyzing user-provided data, where they'd be responsible for maintaining the rules via an admin backend. It was your typical PHP based request/response lifecycle.
They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?"
So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves.
Recently, I saw Turbolinks [0] which looks like the same concept with way more panache.
I’ve occasionally thought of doing SSR but making it possible to server render only a small part of the page in response to an API request and then just use JavaScript to swap in the html from the backend.
This is exactly what the article points out. Github/Gitlab and many other projects do the same thing.
Either small parts of the application are standalone SPAs (since they can be mounted to any single root element) or there are libraries like Turbolinks/Intercooler that just make the full-page request but in JS and then replace the DOM with the results so the browser doesn't actually experience a full page reload.
> My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful.
This doesn't seem like a problem of "MVC vs SPA".
The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for example. You'd experience the same pain.
The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.
> Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
That's pretty debatable. I've worked on some gnarly SSR architectures and making changes to the front end almost always involves refactoring some of the backend as well.
You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)
Also, on the majority of SPA frameworks you have the notion of components which makes making the UI a lot simpler than with traditional SSR abstractions (templating and partials are not sufficient).
Or your backend template engine is weak. In Elixir, EEx used in Phoenix, every template is a function. It's not supper good, but it's component (I hate term "component" and prefer "function")
But a component is a function that satisfies certain properties, why would you prefer to not to be precise in your communication? Do you call squares rectangles because you hate the term "squares"?
Not at all, people moves between libraries of the same framework, they will likely refactor jQuery mess into a framework, but it's unlikely for a team to move from React to Vue or Angular (and vice versa).
There was indeed a moment few years ago when front-end frameworks/libs were changing at warp speed, but last year or so I think the situation crystalized a lot. You now have React and Vue as major players and Angular competing for the 3rd place against some fresh libs... and I don't see that changing anytime soon.
yeah, you have React, but which of the 30 fashionable state-management libraries are you using? Typescript or Flow? What version of JS syntax? What compiler what minifier? oh hey, half of these just stopped being maintained without warning
It's possible, especially if you look primarily at the enterprise market. From where I stand (startups, SMEs) it seems like a lot of people moved from Angular 1.x directly to Vue, skipping Angular 2+ versions. I haven't been offered any Angular projects in about 2 years, while React and Vue are really popular. But it's just my perspective, global situation might be different.
This has also been my experience. Enterprise systems really went all-in on Angular 1 for some reason (I personally suspect because it bridges reactive and MVC), and when it was time to move to a fully-reactive front-end framework, in my opinion Vue and Angular 1 are similar to each other in a way that React is not similar in relation to either of them or Angular 2+.
I still can't quite put my finger on why Angular 1 and Vue rhyme, though. It's common wisdom that "If you know Angular, you'll pick up Vue quickly", and it seems to be true, but nobody has ever explained to me why. Is it the state management? Reliance on viewmodels? How they're more complete systems out of the box and can be reasoned about holistically? Help a girl out, HN.
Not only that but you have to reinvent SSR with front end frameworks. Why do something simple when you can make it 10x as hard but ultimately end up with the same result.
I mean, I think these SSR front-end frameworks are a pile of crap, not worth the added complexity, and I hate using them; but it's pretty clearly not the same result. The problem they're solving is not "render on the server side", it's "render on the server side for the initial load then inject a fully functioning SPA for subsequent loads".
I'd rephrase: Front-end frameworks have been progressing through an iterative process, browsers are adopting standards that make them more consistent, and the tooling have been advancing at a rapid rate.
FE is a vibrant ecosystem and the tooling, in my opinion, is some of the best I have worked with as a SE.
Remote workers are good for this scenario. My current employer is maintaining an outdated backbone.js app, thankfully I'm not on that team.
We have one guy in the office responsible for all of it, as warm bodies with backbone experience are impossible to find. However, should we decide to employ remote workers, we can easily find developers with backbone.js experience from Romania, Lithuania, India, and Pakistan who would work for a pittance and be grateful for the opportunity.
you don't have to follow every trend. stick to one framework until it is no longer suitable. since 2012 i have learned to work with exactly two frameworks. i started with angular 1, and switched to aurelia when angular 1 was no longer viable. i'll stick with aurelia until it has run its course.
"You simply trade back-end frameworks complexities for the front-end framework complexities"
Not necessarily, you can have simple and modular front-ends while also having less complex back-end frameworks. The question is between SPA and non-SPA web applications, not between SPA and JSP/PHP.
The complexities of back-end frameworks are far less than the complexities of front-end frameworks in my experience and observation (in particular because the latter tend to needlessly reinvent half of a web browser). Additionally, the back-end complexities still exist when using front-end frameworks (unless you don't actually have a back-end, of course).
Is there any possibility that the added complexity is a symptom of the framework in use and not a general problem with ALL frameworks? I know I've experienced many projects and found server side rendering more complex then client side when using frameworks like Ember.js.
It's a symptom of the SPA architecture. Since you give up a lot of basic functionality by not using multiple pages, that same functionality has to be reinvented.
I'm a front-end engineer, but I'd agree that SPAs are always more complicated than a pure SSR solution: You're inherently doing more. You're probably already tracking state somewhere on the backend (e.g. in a database). An SPA means you now have to track state on the front-end too.
There are benefits and things you can do with an SPA that you can't do with pure SSR, but they _do_ come at a cost. TANSTAAFL.
I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this...
Doesn't matter, so don't let it matter to you.
When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way.
I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new.
When that happened I was often able to influence the direction of the work.
All you can do as a professional, with experience, is offer up an argument and attempt to make it convincing enough to compel people to do things your way. If they reject your option, defend only once, and no more. After that, simply step back and work with whatever technologies are decided upon.
You can also attempt to work the social networking game and play (internal) politics. If you do these successfully you're more likely to get your ideas heard and implemented. I find this tiresome.
Ultimately if I'm being polite, professional and basing my arguments on facts and evidence, and they're being rejected, I'm not expelling any more energy on this front. Move on. Work on and with what's decided and have fun doing it.
> work with whatever technologies are decided upon.
It may sound great when you learn something new, but when you worked with a technology and you know its deprecated crap - as a professional - you should also consider your own career..
Work on crap nobody uses for 5 years and you are so handicapped by that you "will" find a new job, but rather not a good one.
Not everyone can spend hours at home to keep up with the industry.
I was looking for work once and went to place that made wheelchair lifts for vans and buses. There was a miscommunication about what they were hiring for and when I got there they took me out to a drill press with a stack of thousands of parts on carts that needed a hole drilled in them.
The bank I used has gone from traditional to SPA style, and I wish they hadn't. There is a massive load time before I can even log in with some stupid animation, and they've reduced the exporting features. As a customer I have gained nothing. But I guess it keeps food on the table for some devs.
Our team has found the balance by making a bunch of smaller, individual SPAs that make up our whole application. We follow some SPA designs, but have them more modular, and glued together by a bunch of delivery pages. We kind of get the best of both worlds, plus there's some pages and content that just render better on the server, and delivered faster through caching...
Anytime you rewrite 12 existing, working web apps in something new it is going to be a huge pain. The only sane way to approach this is the strangler pattern, picking one page/view in one app to rewrite, then another, hooking them up with some kind of client-side router, and slowly letting the SPA consume the old SSR pages.
That way you can measure the cost/benefit of each page before deciding it should be added into the SPA.
I'd love to hear some trench stories where these kinds of initiatives to increase the complexity of (what appear to be core) business tools were met with what I'll call a "simplicity advocate," who carried the day and the complexity was tempered, if not rejected.
Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications.
MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic.
Clean separation of frontend SPA and backend API made both sides simpler and more robust.
I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.
I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.
> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.
In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.
Hah. I just finished a huge refactor of an application where the back end developers "dramatically simplified" the business logic and architecture. What they meant is they removed all of the business logic from the back end so the client could do it instead. You might be able to tell I'm still a little bitter about that.
> In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience.
The key is to design the DTOs (which API endpoints are based on) starting from the API consumer perspective. Business logic on backend is responsible to deal with mapping of DTOs to the domain models and in turn to data access layer models.
This results in most DTOs being "flat" and easy to consume by client.
I turned around an SPA fast because I'm only a backend developer. I wrote API endpoints only and contracted a friend to write the frontend, delivering a swaggerspec and vague ideas of what I wanted. Completed the thing in like four design meetings and one touch-up meeting. Couldn't be happier.
your anecdotal story doesn't highlight deficiencies with SPA. You only talked about the pains associated with rebuilding apps with different technology to achieve feature parity.
> "It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients"
In other companies, I wonder if this is just as often due to: (a) developers getting tired of what works reasonably well and wanting to move to a different technology and/or (b) the voices in the tech evangelist community whose own jobs seems to hinge on pitching new and shiny, latest and greatest library/framework/whatever, instilling FOMO and insecurity in the developers who listen to them about not getting on board with the latest and greatest?
Eh. The problems you talk about have little to do with SPAs in general, and have more to do with "rewriting things from A to B". If you had started out with SPAs first and wanted to un-SPA everything, you'd be making the same comments. The issues you mentioned aren't intrinsic to SPAs, they're intrinsic in redoing things.
You're right, but it's also intrinsic to the senselessly shifting paradigm/bandwagon-jumping around SPAs. It's not just that redoing things is a problem, but that the motivation behind the rehaul is poorly conceived.
I think that's how the cookie crumbles, unfortunately. Most companies want to be on the biggest bandwagon to ensure they have a steady supply of fresh, young employees. Few companies want to rely on niche software that only a few people know how to work with. As long as younger people keep jumping onto new trends, companies will continue to follow.
The hybrid approach sounds good, but I've found it frequently non-trivial to pull off in practice. In my experience, you have to be really thoughtful about what and how much you make dynamic.
For instance, if you start to rely heavily on dynamic capabilities to render key components, such as detail views/overlays, then you have to start reasoning about making them accessible via their own URL to enable direct access, browser reloads, sharing, etc. By the time you've done that, you've started duplicating browser functionality via routing, history, etc, and generally working to create an app that coexists peacefully within an app. In other words, you quickly move into SPA territory and all that that entails.
But, if that causes you to be more conservative about sprinkling in dynamic capabilities, then you're really much closer to an old school SSR app and not realizing a lot of the purorted benefits of a SPA, or much else beyond the old school AJAX approaches. Not to say that's useless, but we've long since been down that road, and it doesn't represent any new thinking.
So, it's just hard to find balance there. In most cases, you're really either a SPA or you're not.
On the flip side, I recently worked on a "hybrid" project that has been around for a couple years. It was a nightmare knowing when SSR stopped and SPA began. There was no consistency, multiple ways to do the same thing, and poorly maintained. It was schizophrenic.
I think the real issue you are dealing with is what others mentioned: rebuilding something from scratch burns a ton of people-hours and money. Asking a bunch of rails developers to lean into FE development is a recipe for animosity and to me it shows in this post.
Yeah we have read experiences like yours again and again on every HN thread about SPA, but why we never learn? We developers kind of helping this fashion to happen.
Nine times out of ten, we developers aren't in a position to make or change business decisions of that magnitude.
Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.
True but I was talking about the producer side, those cool kids in big corps. They have money backed and drive small companies to adopt the next cool things.
That's not SPAs problem, that's your company specific problem. It is always painful to migrate. You need to re-wire the logic, change the shoes in the air.
You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge.
It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain.
There are hundreds of directions you could go in, and I consider that a good thing. There are choices, but there are recommended paths for beginners as well.
It sounds to me like you're hating on a toolchain that you don't have any experience in.
While I'm excited about WASM and .NET on the frontend, I don't think Blazor is quite the solution I want. (Getting there though!)
If Evan You, Anders Hejlsberg, and two computers were all locked together in a room for a month or so, whatever emerged from that room is what I'm looking for.
Razor syntax has always felt clunky to me, and I tried very hard to like it when I first started with branching into web development from .NET.
I'm hoping that someone will use WASM very effectively to create some XYZ framework that's revolutionary. Then, Microsoft can do what they did with Java and make a version of it improved by hindsight. I don't think that Razor syntax would be the basis for whatever that is.
I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades.
The technology landscape is absolutely ridiculous if you want to do things for the web.
Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not.
The web today had been tweaked beyond recognition and while the industry is doing so, most of us forgot the beautiful platform that resides underneath.
I love HTTP, HTML, CSS and JavaScript, I really do, but I really believe there is a huge tendency of amateurish approach towards making the web a better and more standardized place.
Back in the day, we had much less choice, and that made working with the web a lot more joyful.
I've heard this repeated a few times, and it's utter nonsense. Unless you're deliberately going off into the weeds, a full featured SPA works the same on Chrome, Safari, Firefox, and Edge. I don't even bother testing on multiple platforms anymore; they just work.
I did web development in the IE6 era (and before). This is nothing like that.
I do believe the live standards from whatwg is a good example of some vendors making it possible to implement features before other vendors do.
It creates a gap, it creates a constant drive forward which again seems, IMO, to sometimes be about vendor competition instead of the greater good of the web.
I don't doubt your experience, but when people say "toolchain" in the context of front end development, it's usually a reference to the dev environment and build toolchain, not the HTML/CSS/JS technologies themselves. I've been focusing primarily on front end development since 1999, and while I also hate the current complexity in setting up a complex JS client, it allows us to scale far beyond what was possible back in the jQuery days, and it has made my life much easier. It becomes a problem when people suggest that you set up babel, webpack and hot module reloading for a site with a couple of forms.
FYI: Blazor is using the Mono runtime and is still in experimental stage. It's 2MB raw, can be compressed over HTTP as any other file, and can get much smaller after linking and optimizing the build.
Early tests have made the whole package as small as 200kb which rivals many JS builds but with far more capabilities.
I pretty exclusively use .NET backends with VueJS frontends. You get all the power of the MS devtools for the backend, near total separation of backend and frontend logic, and then you get all the SPA benefits in the frontend. I absolutely love using SPA tools for frontend development (you just have to spend a year or so with them and really get comfortable, so maybe it's stockholm syndrome), but I can't imagine switching to a dynamic language for backend development.
I may switch things up once WASM is further along. I would love to be using C# on both sides. I would still want very clear backend/frontend separation though.
.NET is not that simple either, you are just used to it. Beginners will think it is confusing with .NET, .NET Core, .NET standard for example.
There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started.
Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on their homepages.
> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked.
> I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer.
This is cute.
I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet.
60MB is a significantly lower amount compared to 40GB, but I don't think it is fair to compare the disk space of an operating system, IDE, and database server to a directory of javascript libraries.
If a developer cannot meaningfully work within .NET without an IDE, it absolutely counts. Just like someone on the frontend cannot work without babel or typescript.
Those libraries add specialized tooling for the project in question. Instead of downloading a runtime that has a huge std, in JS everything is downloaded on a per-project basis.
I cannot speak to .NET, but want to work with python? Bring in one library and it'll top 40MB (e.g. numpy).
I don't get why so many people complain about `node_modules` filesize, it's not even an issue to think about.
They complain because they're under the impression that everything in node_modules will end up shipped to the browser.
It's also more visible. Python libraries are hidden in the environment far from your shell or file manager. So you don't know that your virtualenv weighs 300mb. But node_modules is right there, you can't help but look.
In other words it's a complete lack of experience, regardless of how adamant the OP is about their skills.
For a while .NET Core also had a folder within the project for third-party NuGet modules, and for a simple web app they would go into the 200mb, and that's without the compiler itself. Now those files live in a hidden folder (or were absorbed by the stdlib), and nobody complains about it anymore.
Initiatives like Yarn's plug-and-play [1] would have the side effect of being great marketing for Node.js development.
It sounds like OP was trying to make a beginner-level sample app in Node.js - is your .NET app of the same nature? Judging by the mention of SQL Server, it's not.
I'm with you. I'm not employed as a developer, and am certainly not a web dev, but a few years ago I (perhaps foolishly) used some spare time at work to create a tool to help the people who do the non-sitting-in-an-office work in our company get more accurate and relevant documentation for their day-to-day workflow that they could access via a cheap tablet connected to our WiFi.
It grew, as projects do, out of its original simple use case and now it needs to be usable in scenarios where network access won't be available for most of the work day, which means I need to rebuild it --in whatever time I can manage to devote to it, dev not being my primary or even secondary responsibility-- to deal with that and better handle the functionality we tacked on later.
After a review of my options, which unfortunately doesn't seem to include writing a native application (for reasons I still may be able to work around), I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. Basically, just a client application written in JS. No special frameworks, no complicated toolchains. Even that is a pain in the ass because the web world hasn't quite worked out how to store local data in a non-stupid way.
> I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available.
I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is supported by all browsers and all you need to do is de/serialize your data to JSON when your data changes.
- Redux with a middleware that saves the whole state to localstorage automatically
- Some simple background timer stuff that uses ononline and onoffline events to know when to poll for updates, then dumps the JSON contents from the polling into the Redux store
- Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary
Then stick some Progresssive Web App stuff in there so the whole bundle can work offline entirely from browser cache.
> Redux with a middleware that saves the whole state to localstorage automatically
I don't want to save the whole state automatically. The state isn't complicated. Even the data isn't complicated.
> Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary
Or I just write some javascript that creates a view of based on the data it has cached locally and updates that view when the user interacts with it.
This is what we're talking about. I have a relatively simple problem, I don't need to pull in additional dependencies in the form of a framework that's just going to make things more complicated and require me to learn its paradigms.
> I don't want to save the whole state automatically. The state isn't complicated. Even the data isn't complicated.
If you don't want to save the state, why mention localstorage in the first place? The point of using the Redux thing would be to automate that process, so that you don't have to manually save/retrieve anything to localstorage yourself.
I'm currently building an app that works nicely as a web app, but it needs to store gigabytes of data and work with only intermittent network access. I'm considering trying to bundle the server-side code into a simple Windows binary that just fires up an HTTP server and binds to 127.0.0.1. Would that work for you?
That's essentially Electron. I'd considered that, but if I'm writing a native application component anyway I may as well make the whole thing native instead of using wonky web tech. I'd like to do that, make it completely native, but right now there are factors beyond my control that I'd have to work around first.
Riot is a good solution for simple SPAs if you don't like huge toolchains. It gives you web components and DOM binding and all that, all in a 15 KB package that does all the compilation in a few milliseconds on the client.
No configuration of babel or webpack or whatever to worry about, just host your app as static files that point at your API.
I come from the .Net toolchain as well, no longer develop full-time, but write tools for my business as needed. I use Angular (6 or whatever). They talk to a .Net (core) server as little as possible. What I find is the iterative dev turnaround time, that cycle between find a bug - fix it - test it, is so much faster with angular than if server-side rendered. It's a joy. That same cycle on server side in .Net - change some .cs file and check that fix quickly - , slowly rather - a real pain. That alone drives the choice for me.
Last time I followed the official .NET tutorial I was also shocked when I had to download +1.5gb of dependencies. It was more than 4 years ago though and the landscape might be a lot better now but I don't think they managed to keep the whole thing under the 60mb mark. The tooling is just simple and clean when you've been working with it for a long time.
`node_modules` directory topping 60+ mb means nothing when the final product is an optimized bundle or a `node` process loaded in memory. A large majority of developers don't care about this because they're just looking to get actual work done... not sure why you're trying to "fix this".
I'm also not sure what you're talking about when it comes to unclean code and complicated tooling. The tooling is dead simple... much simpler than the NuGet/IIS/OWIN nightmare that is C# development.
I think you're very close minded and you'll likely be stuck in .NET land forever. And that's okay if that's what you like or if it's what gets you a paycheck. But to completely dismiss this ecosystem as if it's not productive... it's just a sign of naiveté. Good luck.
It's really down to language and ecosystem. JS as a language and NPM as a ecosystem are not as productive as C# and the .NET standard library, framework and Nuget.
With WebAssembly, C# Razor Components will soon be able to run either server or client side and still maintain the same highly productive development that's missing from JS.
It's not as productive. Anyone can create a REST API in any language in a few minutes, that's the easy part.
Building a complex app is different though and much easier and faster in a proper environment that has strong typing, OOP, interfaces, reflection, dependency injection, a solid standard library, and more. Being able to use that same environment to create frontend views and code will greatly improve productivity compared to the current Javascript frameworks and limitations.
Strong typing is admittedly great and there are solutions to introduce that in JavaScript. However, this is hardly a dealbreaker in complex apps written in JavaScript.
OOP, interfaces: debatable and unnecessary fluff. There are plenty of productive languages without OOP. Example: Elixir. And there are plenty of productive languages without interfaces. Example: Go.
Reflection is unnecessary in JavaScript. You can access any property within an object dynamically and the language is interpreted, so there's no need to perform fancy reflection operations at runtime.
Dependency injection is an engineering pattern. You can apply this to almost any language. And ironically, plenty of JavaScript backend and frontend frameworks have attempted to use it successfully: Angular, Ember. Hell I even wrote my own DI layer once upon a time. https://github.com/divmgl/nwire
I'm sorry, I really disagree with you. I believe C# has the ability to be productive, but there is just no way you're going to convince me that it's superior to JavaScript and its ecosystem. There's a lot of disdain on Hacker News for JavaScript and it's honestly beyond me.
I have the same opinion. Building SPA is f* hard and time-consuming. But it depends. If you know how to build SPA fast, then, by all means, go that route. (As a solo dev or small team)
I use Rails, but Rails views are a disaster. You can use a lot of different patterns/gems, but still, logic is highly coupled with the view layer. Personally, I like Phoenix approach with templates + views. But still writing script tags makes me cringe a little bit.
But I wouldn't discourage people from using SPAs, though. If you are gonna have a lot of buttons, modals, different tables, charts, forms and stuff like that, I would go SPA. Or first serverside -> SPA. Especially, when you are working in the team, it's so much easier to tell one person to craft this json api and another to craft this design with a consumer for the json api.
That become long... in short: if you have a small team or solo go server side 99%. If you have a big team or app that's gonna be very heavy UI -> go full spa or go server(mvp) -> spa
Take this with a grain of salt, as I only recently came across it and haven't used it, but the Trailblazer framework looks like it has a good way of getting logic out of the views.
I've been using parts of it on most Rails apps I've worked on for the last few years.
The form object pattern (Reform) really helps when you need to update the same model in different places with different validations.
For example maybe an Order only needs a price when it's created, but needs a invoice number (and some other validations) when marked as paid, but an admin should be able to override those validations at any stage. If you are doing something like that with standard Rails the model is going to end up as an untestable mess, where as the form objects can be tested on their own.
My only complaint is that the creators of Trailblazer really don't seem to like Rails, so trying to get them to both work together can sometimes be a bit tricky. And the documentation is lacking if you want to do some more complicated things.
Thank you for your thoughts on it, I'm intrigued enough to really want to look more into it. Even if I don't get to use it, I think it will give me some ideas that I can apply to other projects.
Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA, or SPA -> SSR is easy (via Gatsby/Next.js). The other direction though, seeing projects grow from SSR -> interactivity/SPA is usually a horrifying display of highly-coupled code spaghettification.
> Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA
Aha, by mistake you corrected your grammar! HNers cargo cult everything, including grammatical mistakes like "an SPA" ( see literally everywhere in this thread). Just say it out loud, "I start with an SPA", does that roll off the tongue? No, neither does, "I'm going to buy an sailboat". However, "It either needs to be a SPA, ..." is totally natural.
While this comment may not seem on topic/useful, it's a useful meta comment -- please don't take offense.
For new development, I reach for SPA tools (like VueJS with Webpack) fairly quickly. The reasons for this are:
1. Reusable web components.
2. Clear separation of backend and frontend logic.
3. Using the latest version of javascript.
I really like HTML/CSS/JS as tools for building GUIs, but I feel HTML/CSS specifically suffer from the inability to make components.
I think there are definitely instances where there is no need for these tools. I would genuinely like to know how to manage the items listed above when this is the case. ie Recommended tools for when I go "SPA seems like overkill for this... what are my other options for this functionality?"
If you want to stick to JS, then Node + Express is a fine stack. You can always use React to add functionality to specific parts of the site if you find you need to later.
Once you know how to use the tools (Webpack with Hot Module Reloading, React/Vue/Whatever, Storybook, TypeScript), it is hard to work without them.
They offer a ton of advantages, especially speed of development if you have a clear separation of frontend & backend logic. If you can mock your backend & develop the front end all by itself without any other code needed, you can go at crazy fast speed. You are also able to focus on UX/UI without needing to think at all about the backend. I feel there is a ton of value in this, whether or not your app is a SPA or not.
I think tools like Gatsby will make building actual SPAs easier down the road. They offer huge speed advantages the longer someone is on the site. Though one could gain a lot of these with just preloading content & HTTP/2 as well. As the article said "It all comes down to tradeoffs". I would also argue what resources you have available & the value of speed on your site.
You may want to look at Next.js, which is an SSR/SPA framework using React components that also has a "render entirely to static files" build mode option.
Totally agree with the article, the spa hype has produced a lot of crappy slow web sites and crippled productivity of many teams for years. I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. Spa are like applet or Silverlight, just different tech, same goes for ws* vs rest api and so on...
True, if you do not stay long enough to feel the consequences of your decision you do not learn from those years. We do not usually hire ppl that change job that often, but we are not in a silicon valley kind of enterprise
Because studies have shown that's the only reliable way to get appropriate salary raises. If companies properly managed salaries for existing employees that wouldn't happen so much.
I have modest skills as a developer. I was trying to convert an old static web site into something more interactive. Without really thinking it through, I started building a SPA. I got stuck on the SEO part. I found it innately complex, but the real trouble came from trying to bring together the disparate sections of the old static site while preserving and abetting SEO.
One day I just ditched the SPA and rebuilt the whole architecture with NodeJs and Express. I was done in a few days. It could have gone even faster, but the original static site was really a mess with years of accumulated bad decisions embedded in it.
I know this is just one data point and not really proof of anything. Nevertheless, the linked article made a lot of sense to me. Most of the bulleted points resonated with me, but none more than the SEO issue. There are solutions to the SEO issue, but I personally did not find them easy to implement. If I were part of a big professional team, and we really needed a SPA, I would have called this one differently, but I was working on my own, and I didn't really have the sense at first to see that I didn't need a SPA to achieve my goals. I was perhaps a bit too susceptible to the hype without enough experience to really understand the issues involved.
Thanks. This does look interesting. It's hard to keep up with all the frameworks, but this does look like something worth investing some time in. I'll check it out.
As a FE engineer, SEO is the one area of SPAs that does feel like the wheel is being reinvented to accommodate its existence. It's unfortunate, there are solutions, but it's a little annoying to deal with.
I happened to watch a conference talk on YouTube by the director of infrastructure at Netflix. He closed it out by saying, yes we open source everything, and yes this solution works for us. But just because we do it doesn't mean you should. Do what works for you.
But in reality...I only need it because people on the other side of the interview table expects every engineer to have 3-5 years experience of x,y, z.
I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of server-render applications any way, right? Turns out 99% of the time it is performant for the SPA to rerender the whole page. Instead of Angular and React, if you use simple libraries such as UIBuilder ( https://github.com/wisercoder/uibuilder ) and MVC router ( https://github.com/Rajeev-K/mvc-router/ ) you can build simpler applications that work well and are super easy to develop and maintain. Each of those libs is less than 500 lines, so super easy to learn and use.
This article says traditional web servers are stateless, but in the case of SPAs servers are stateful. The opposite is true. Traditional web servers have session state, but in the case of SPAs the servers can be stateless because all servers are responsible for is persistence and query/search.
This article says maintaining browser history is a mess in SPAs. Not true. The same MVC architecture that works so well on the server can be done just as easily on the client, see this lib: https://github.com/Rajeev-K/mvc-router/
This article says server-rendering has fewer more mature tools. That may be true. There are so many new tools for SPAs. But you can ignore them and build SPAs trivially using the libs mentioned above.
This article says server-rendering is better for SEO. Not true anymore. Google and Bing crawlers now execute javascript to crawl your content. This is more work for Google and Bing but not more work for you.
If you know how to do it SPAs are the easiest and best approach because all the server needs to do is implement persistence and query/search using a REST API. If you later need a native mobile client this approach is already more compatible with mobile than if the server renders HTML in addition to persistence and query/search.
You don't need React, Redux, and other such libs, true.
But you're missing the point of them. It's to prevent the problems that cropped up after years of jQuery development.
Too many side-effects and poor state management lead to very hard to find bugs.
When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.
React, Redux and other such libs solve the problem while overcomplicating the programming model. My point is that 99% of applications don't need the complexity introduced by surgically making the smallest possible change in the DOM to refresh the page. There are simpler libs out there that eliminate 99% of the complexity of React, Redux etc while providing 99% of the benefits.
Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server.
React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way simpler.
>you don't even have to use JSX
But JSX is the good part of React. You get compile-time checking of your expressions if you use TypeScript and you get syntax coloring, intellisense etc for both HTML and JavaScript.
If you don't need state, don't include it. That's the beauty of React. But as far as a state management lib goes, Redux is one of the simplest, go look at the source.
I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a smaller implementation, use preact or some other template lib.
When dealing with React and Redux you are just dealing with functions. You could do everything in pure functions.
React requires too much incantations, rituals and ceremony. You have props and state, context, error boundaries, refs, keys, you have to figure out where state should live, etc. You make a component that contains state. Then you want to use it in a component hierarchy -- now the component is supposed to have props not state. You make a component that has props, now you want to use it at the top level -- now the component is supposed to have state, or have an otherwise unnecessary wrapper.
You don't have to deal with any of that crap.
The best part of React is DOM diffing and incremental screen update. Obviously this is only useful if your application needs to update screens it previously rendered. In fact I'd argue that React is only useful if you need to incrementally update complex screens, because simple screens can be re-rendered completely and no one will know the difference. Very few applications need to incrementally update complex screens. If your application doesn't have this need you can use simpler technologies that don't have the same "Care and feed" requirements of React, such as UIBuilder: https://github.com/wisercoder/uibuilder
But the very fact that we're having this debate is proving my point. React's programming model is unnecessarily complicated. JavaScript + DOM is all you need. The simple libs (each less than 500 lines) I pointed to get you close to this without sacrificing productivity or code maintainability while keeping the programming model simple.
To reply to your last comment, each project is different, and if you just want a few things on a page, sure use a small lib like what you suggested. But at a certain point you start reinventing the wheel and no other developer will be able to jump into it. You need a framework for large projects with a team and potential future members.
First off, this is not “the point of React”. Second, direct use of setState is not somehow the only path to focused DOM updates with React. In order to understand this better, I suggest you read up on the topic of Reconciliation in React - https://reactjs.org/docs/reconciliation.html
There are better ways to build components. The problem with React components is that they are only compatible with React. What if there was a way to build components in a better way, and what if those components were compatible with all current and future frameworks? There is a way to do that. Look up W3 Web Components specification. There's sample code here: https://github.com/wisercoder/uibuilder
So another library. From the examples i am not impressed. Web-component are not panacea. For me reactjs is still the best frontend framework out there.
You're dramatically overexaggerating the complications of global state handling in Redux. For a simple app, you could just use the useState hook, and pass the state-setting callback down into children components:
> Developing SPAs is easier than server-render applications.
Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build.
Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several changes, across directories and languages in both the front and back-end, and usually two different build chains.
You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whatever syntax you are using to embed expressions in the template. If you use SPA there is one additional language (unless you use Nodejs for server logic) that's true. And you also have two different build chains. But the advantage is that the server logic becomes much simpler because you don't need session state or rendering logic. Your server can focus on being a stateless REST service which is more scalable (since you don't have session state clients can connect to a different server on each request). Your server is also more future-proof because it won't need to be rewritten to support native mobile clients.
> Your server can focus on being a stateless REST service which is more scalable
You can do exactly the same with server side rendering. In all the applications I've built over the past decade, the only state I've had is an encrypted session cookie to say which user you are logged in as - but that's send by the browser on each request, so it doesn't matter which server handles it.
The urls I've built are basically the same as you would for a REST API, to view a widget you do a GET /widgets/1, to view the form to edit you do GET /widgets/1/edit, to save the update you to PATCH /widgets/1, which redirects you to the list of widgets at GET /widgets. I admit that trying to fit multi-step workflows into this scheme doesn't always fit so nicely, but with good API design (that's what you are building, an API for the browser to call directly without JavaScript) you can make it perfectly stateless.
I think that "I'm a backend person" says it all -- most of the people in this thread are probably not JS natives or front-end natives. All of the complaints about JS fatigue, or not knowing how to use client-side routing are because you've done things differently on the backend. Is it such a surprise that front-end frameworks and tools make more sense to people who actually enjoy and have experience working on the frontend?
If you provide an API schema, with a SPA the whole frontend can be developed separately of ever touching backend code. Okay, so you changed the name of model.thing to model.anotherThing - quick change in the reducer that is consuming that end point and call it a day.
> Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript!
That was his point. The rails stuff he learned five years ago is all still considered good practice, but the JavaScript stuff he learned (listed above) is now considered antique.
I think the general point holds up, but why is sass in that list? I know some newer alternatives are used with React nowadays, but sass is still very much a best practice in general as far as I'm aware.
(If he means SASS vs SCSS syntax, I recall using SCSS ~8 years ago, so it's an odd choice to include either way.)
Once you've used grunt, using gulp is not a big logical jump. Then to webpack. Whatever, they're just build scripts! Roll your own shell scripts if you want! A day to learn them, or a lifetime of being a hater.
One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react.
The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynamic UI elements.
Definitely, which is why I leave room for those unknowns with a some preemptive over-engineering. Worst case, those (well-known, general, popular) abstractions don't get used and the project works. Best case, they really save my butt and the project works. Worth it either way, imo!
Well, the thing is that you don't know if you're "over engineering" up front. That's the whole challenge.
And rewriting down the road because of the wrong gamble can be very costly. Make the wrong bet enough times and you'll see that it's not over-engineering but just engineering for changing requirements.
A classic example is thinking it will be simpler to avoid React and use a few .show()/.hide() toggles. Simple at first. Then as you take on complexity, you start to feel like the lumberjack who thought he could save time by skipping the axe sharpening.
The concept of a SPA is a total hack of web patterns. I predict in a few years we'll refer back to SPA's the way we do now to AJAX or DHTML.
We're getting closer to the best of both worlds, where we SSR pages and then "hydrate" them with JS components. The tooling around this isn't great yet, but it's definitely all there.
On the one hand, site like https://dev.to/ that are built in Rails and rival the speed and performance of any _static site_ support the argument that you can just use the tools you know.
On the other hand, to get your Rails site to function that well takes a lot of work - it is by no means the starting point.
Systems like Next.js and Gatsby.js and others are attractive in that A) they offer the ability to use both server-rendered and client-rendered React, and B) exceptional performance is the starting point. It's up to you to slow it down, not speed it up.
It‘s a traditional server side rendered application. But they use a custom implementation like turbolinks and instantclick to change the sites content without a full reload.
521 comments
[ 3.1 ms ] story [ 370 ms ] threadFor example the server has to send a tag with a class name that the client also is aware of that.
Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.
(The new reddit redesign is a resource hogging abomination riddled with needless SPA bullshit, but the old reddit design was pretty clean and minimal and yet an SPA.)
Especially in news, articles, longreads, right? /s
Most of the internet content would be perfectly fine without interaction, or with ordinary, oldschool POST forms
As author said, it is tradeoff.
Try a really good interactive article from the New York Times. You'll have a much more impactful experience than if you read a blurb about the same thing on your RSS reader.
The message is build with what accomplishes your goals and works with your team's skills.
The notion that SPAs are only good for certain types of applications or organizations doesn't make much sense to me.
Building server-generated web sites works faster for me because I'm still more comfortable with it. SPAs make concessions but so do server generated apps.
Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools.
Force them to only use simple tools and the good ones will move elsewhere because they know that being stuck on just the simple things is going to limit their careers.
edit: And losing them will probably cost you more project velocity than you'd ever gain with different tools.
BUT — with a bit of work, you can set things up to do server side rendering. It requires you use Node at some point in your server stack, and you essentially call the library (on the server) and run their RenderToString function (each has a slightly different implementation).
There are frameworks for this (next.js, nuxt.js) or you can roll your own - it’s not terribly complicated.
It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there.
I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
Or I suppose we could just all use chromium, but we could also just all use Windows.
There's no scenario where I only have to write two native apps. Perhaps there is for other people.
You're a hammer, so everything is a nail. The reality is that the web is a horrible choice for a whole lot of things. It's a document platform with parts of an application platform shoe-horned in and bolted on, and the result looks like a garbage fire to people who come from the land of native software.
As a user, I usually can't even tell when they're using a polyfill on the web (except when they stop, like GitHub did with type=date). (As a developer, I often can't tell the difference, either. Some of them are that good!) So long as you generate HTML/CSS/JS, it doesn't matter to me how you do it. That's as 'native' to the web as you can get.
I can spot Qt a mile away. A lot of the visuals look wrong and a lot of the controls don't behave right. It's frustrating to use, and I always slow way down and double-check my work because, e.g., popup menus show the 'accept' animation even when you cancel them.
You mean it has no respect for your native toolkit... just like the web?
How true is that? I was under the impression that for Android and iOS, Chrome used the native widgets for most things.
React Native and ReactJS are a move in the right direction.
I wonder if we'll get React NativeJS
Works remarkably well. It’s already used for Twitter’s mobile site
Native is only a trade-off that has great performance at other expenses.
[1]https://www.statista.com/statistics/444476/google-play-annua...
I mean, it's neat and all, but most websites aren't CPU-bound.
The only positives are to corporations and institutions with profit motives to decrease dev time and increase ability to spy on users and extract rent from them.
Browsers are forced to implement standards like CORS, single-origin policy, and multiple levels of SSL certificate validation and thus are more secure than most of native apps. How do you know whether that mobile app is not signing in over HTTP? In a web browser it's obvious instantly.
> motives to decrease dev time and increase ability to spy on users and extract rent from them.
Literally the worse what can happen over web browser is tracking based on various forms of fingerprinting. Native apps? MAC addresses, SSIDs, serial numbers - EVERYTHING is available for the native app to send ANYWEHERE, even over HTTP.
I agree with slower, at least for computational tasks, but not security. Do you feel safer installing an organisation's native app than using their web app?
> The only positives are to corporations and institutions with profit motives...
What advantage does the web give to corporations that native apps don't? You mention spying, but the native mobile app ecosystem is filled with tracking and analytics code (and it's easier to hide it). The only corporation-level difference I can see is that native apps are heavily tied to a specific company's platform, while web apps aren't. This is a huge positive to the web - I've felt free to change platforms many times.
A second huge and underestimated positive of the web is backwards compatibility (ie. lower maintenance headaches). A complicated internal web app I wrote eight years ago is still running despite not being modified. The websites and lousy javascript I wrote as a kid in 1999 still run exactly the same as in 1999. Spacejam.com is unmodified from 1996. Yet I have many native apps from two years ago that no longer run correctly due to OS updates (especially on mobile).
v8 is probably one of the most strenuously vetted pieces of software on the planet.
With a server rendered website, you don't have to do anything
This is pretty simple to reason about honestly.
Laravel is stable in production but they break backwards compatability all the time and not always in major versions.
Symfony is much better about it.
Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is a button that will open a popup with another form, dynamically generated based on what you choose. Or maybe there is data you must dynamically fetch from the server, based on some combination of actions that the user did.
You can play the ".show()" and ".hide()" game with plain JS, but if you have more than 5 inputs, I promise you, you'll be really sorry for choosing that method.
You can also "inject" somehow any SPA just into that particular view in your project, but then you'll be already dealing with the cons of both SPA and SSR. It doesn't pay off.
I have been doing all types of FE and BE development, and what has given me the best results is making the BE a REST API and doing the rendering on the frontend.
Just my 2 cents.
> Going the hybrid approach is choosing to deal with the problems from both worlds.
This is true of any technology. Every framework, language, library, etc. comes with a cost in setup, design, maintenance, etc. For us, the cost of dealing with problems from both worlds is much, much lower than trying to shoehorn a SSR app with SPA-like functionality. By limiting the size and scope of the SPA, you avoid a lot of the really hairy state management problems that can arise when an SPA is trying to keep track of too much state.
My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful.
Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well.
Since the announcement, our productivity has diminished dramatically since so much of our time is now focused on re-working functionality that already exists into an SPA, and it's completely unnecessary. Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks, and we're definitely going to make mistakes along the way that we weren't making before.
It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients, when 99.9% of our clients have no idea what an SPA is. And the amount of money being spent on turning already-working apps into SPAs is astronomical.
Compared to client side rendering discrete web requests with minimal templates; you usually get much better separation of logic, view, and code than the typical serverside solution.
There is a happy medium where server side services are encapsulated to separate concerns in a similar manner, but it rarely happens, even with competent, experienced, well intentioned teams.
The key being bad programmers dont isolate concerns and good ones do.
Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.
But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together.
With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.
YAGNI
1. One language - JavaScript
2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing)
3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations
One language, one repo, easy & consistent API production/consumption, no?
I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.
That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.
Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API).
Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort.
It depends... but it is always less effort not maintaining an external user facing UI.
I think making information usable is hard. This means that the burden of the development falls on whatever is making the information useful. If you simply can query an API and get stuff back that's valuable because the data is already processed, UI is pretty easy (aka Google). If your backend is returning raw data that needs to be organized and displayed, and users need to be guided through complex processes that are just simple CRUD operations server side, you have a much harder UX/UI challenge. Most things fall somewhere in the middle.
If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...
It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want.
We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.
I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner.
Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.)
Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.
Known: we’re definitely rewriting it in two years regardless of this CEO feature
The feature probably isn’t that complicated anyway
Maybe if you want code quality, stop rewriting so much shit because there’s some new hotness. Probably helps to not have so much new hotness too.
If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA.
Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.
On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.
The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...
Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions).
The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong.
I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.
You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:
https://redux-starter-kit.js.org
There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary:
> Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity.
It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile.
[0]: http://entity-systems.wikidot.com/
But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside.
I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.
We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it.
While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc.
The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it.
This approach is also described in MS's silk project - https://www.microsoft.com/en-us/download/details.aspx?id=272...
If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever).
I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders.
You can find an example of this technique here[0]
[0] https://github.com/jbogard/ContosoUniversityDotNetCore
They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?"
So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves.
Recently, I saw Turbolinks [0] which looks like the same concept with way more panache.
[0] https://github.com/turbolinks/turbolinks
[0] https://stimulusjs.org/
[1] https://intercoolerjs.org/
Either small parts of the application are standalone SPAs (since they can be mounted to any single root element) or there are libraries like Turbolinks/Intercooler that just make the full-page request but in JS and then replace the DOM with the results so the browser doesn't actually experience a full page reload.
This doesn't seem like a problem of "MVC vs SPA".
The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for example. You'd experience the same pain.
The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.
> Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
For your example I'd call it "squares" not because I don't hate it, but I don't think squares has something to do with "component"
I predict a bigger react ecosystem. The slide of vue but the raise of the Quasar framework for apps. The rise of Angular once again.
I still can't quite put my finger on why Angular 1 and Vue rhyme, though. It's common wisdom that "If you know Angular, you'll pick up Vue quickly", and it seems to be true, but nobody has ever explained to me why. Is it the state management? Reliance on viewmodels? How they're more complete systems out of the box and can be reasoned about holistically? Help a girl out, HN.
FE is a vibrant ecosystem and the tooling, in my opinion, is some of the best I have worked with as a SE.
We have one guy in the office responsible for all of it, as warm bodies with backbone experience are impossible to find. However, should we decide to employ remote workers, we can easily find developers with backbone.js experience from Romania, Lithuania, India, and Pakistan who would work for a pittance and be grateful for the opportunity.
Not necessarily, you can have simple and modular front-ends while also having less complex back-end frameworks. The question is between SPA and non-SPA web applications, not between SPA and JSP/PHP.
There are benefits and things you can do with an SPA that you can't do with pure SSR, but they _do_ come at a cost. TANSTAAFL.
But I agree, that seems to be my impression. Single Page Apps allow higher quality User Interfaces (if done right), though they do require more work.
But if the comparison is with more traditional SSR sites, React and Vue are also not doing everything the back-end was doing before.
I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this...
Doesn't matter, so don't let it matter to you.
When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way.
I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new.
When that happened I was often able to influence the direction of the work.
All you can do as a professional, with experience, is offer up an argument and attempt to make it convincing enough to compel people to do things your way. If they reject your option, defend only once, and no more. After that, simply step back and work with whatever technologies are decided upon.
You can also attempt to work the social networking game and play (internal) politics. If you do these successfully you're more likely to get your ideas heard and implemented. I find this tiresome.
Ultimately if I'm being polite, professional and basing my arguments on facts and evidence, and they're being rejected, I'm not expelling any more energy on this front. Move on. Work on and with what's decided and have fun doing it.
It may sound great when you learn something new, but when you worked with a technology and you know its deprecated crap - as a professional - you should also consider your own career..
Work on crap nobody uses for 5 years and you are so handicapped by that you "will" find a new job, but rather not a good one.
Not everyone can spend hours at home to keep up with the industry.
I was looking for work once and went to place that made wheelchair lifts for vans and buses. There was a miscommunication about what they were hiring for and when I got there they took me out to a drill press with a stack of thousands of parts on carts that needed a hole drilled in them.
I politely declined the position.
MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic.
Clean separation of frontend SPA and backend API made both sides simpler and more robust.
I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.
In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.
The key is to design the DTOs (which API endpoints are based on) starting from the API consumer perspective. Business logic on backend is responsible to deal with mapping of DTOs to the domain models and in turn to data access layer models.
This results in most DTOs being "flat" and easy to consume by client.
It sound as though the application was a suitable candidate for an SPA and should have been developed as one to begin with?
For instance, if you start to rely heavily on dynamic capabilities to render key components, such as detail views/overlays, then you have to start reasoning about making them accessible via their own URL to enable direct access, browser reloads, sharing, etc. By the time you've done that, you've started duplicating browser functionality via routing, history, etc, and generally working to create an app that coexists peacefully within an app. In other words, you quickly move into SPA territory and all that that entails.
But, if that causes you to be more conservative about sprinkling in dynamic capabilities, then you're really much closer to an old school SSR app and not realizing a lot of the purorted benefits of a SPA, or much else beyond the old school AJAX approaches. Not to say that's useless, but we've long since been down that road, and it doesn't represent any new thinking.
So, it's just hard to find balance there. In most cases, you're really either a SPA or you're not.
I think the real issue you are dealing with is what others mentioned: rebuilding something from scratch burns a ton of people-hours and money. Asking a bunch of rails developers to lean into FE development is a recipe for animosity and to me it shows in this post.
Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.
Your comment being on top is ridiculous
Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked.
The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris.
I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer.
Good luck fixing that. I'd rather keep my code and tooling simple and clean.
It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain.
There are hundreds of directions you could go in, and I consider that a good thing. There are choices, but there are recommended paths for beginners as well.
It sounds to me like you're hating on a toolchain that you don't have any experience in.
If Evan You, Anders Hejlsberg, and two computers were all locked together in a room for a month or so, whatever emerged from that room is what I'm looking for.
Razor syntax has always felt clunky to me, and I tried very hard to like it when I first started with branching into web development from .NET.
I'm hoping that someone will use WASM very effectively to create some XYZ framework that's revolutionary. Then, Microsoft can do what they did with Java and make a version of it improved by hindsight. I don't think that Razor syntax would be the basis for whatever that is.
The technology landscape is absolutely ridiculous if you want to do things for the web.
Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not.
The web today had been tweaked beyond recognition and while the industry is doing so, most of us forgot the beautiful platform that resides underneath.
I love HTTP, HTML, CSS and JavaScript, I really do, but I really believe there is a huge tendency of amateurish approach towards making the web a better and more standardized place.
Back in the day, we had much less choice, and that made working with the web a lot more joyful.
We're in a lot better place than we were a decade, let alone 2, decades ago.
I've heard this repeated a few times, and it's utter nonsense. Unless you're deliberately going off into the weeds, a full featured SPA works the same on Chrome, Safari, Firefox, and Edge. I don't even bother testing on multiple platforms anymore; they just work.
I did web development in the IE6 era (and before). This is nothing like that.
It creates a gap, it creates a constant drive forward which again seems, IMO, to sometimes be about vendor competition instead of the greater good of the web.
I've found that parcel-bundler "just works" for stuff like that without needing extra configuration, including the Babel part.
Early tests have made the whole package as small as 200kb which rivals many JS builds but with far more capabilities.
I may switch things up once WASM is further along. I would love to be using C# on both sides. I would still want very clear backend/frontend separation though.
There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started.
Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on their homepages.
Microsoft did a terrible job not having one framework for every path, like it did with the original .NET framework.
> I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer.
This is cute.
I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet.
What is 60mb compared to that?
Those libraries add specialized tooling for the project in question. Instead of downloading a runtime that has a huge std, in JS everything is downloaded on a per-project basis.
I cannot speak to .NET, but want to work with python? Bring in one library and it'll top 40MB (e.g. numpy).
I don't get why so many people complain about `node_modules` filesize, it's not even an issue to think about.
It's also more visible. Python libraries are hidden in the environment far from your shell or file manager. So you don't know that your virtualenv weighs 300mb. But node_modules is right there, you can't help but look.
In other words it's a complete lack of experience, regardless of how adamant the OP is about their skills.
For a while .NET Core also had a folder within the project for third-party NuGet modules, and for a simple web app they would go into the 200mb, and that's without the compiler itself. Now those files live in a hidden folder (or were absorbed by the stdlib), and nobody complains about it anymore.
Initiatives like Yarn's plug-and-play [1] would have the side effect of being great marketing for Node.js development.
[1] https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-pl...
Nothing special about it. It just happens to use this specific stack.
Also, .NET and “easy to use” hasn’t happened in forever. Unless you’re counting the “Hello world” tutorials that are useless.
The .sln file within a .NET project ends up being pretty damn large, so the whole 60mb node module thing seems a bit ridiculous.
It grew, as projects do, out of its original simple use case and now it needs to be usable in scenarios where network access won't be available for most of the work day, which means I need to rebuild it --in whatever time I can manage to devote to it, dev not being my primary or even secondary responsibility-- to deal with that and better handle the functionality we tacked on later.
After a review of my options, which unfortunately doesn't seem to include writing a native application (for reasons I still may be able to work around), I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. Basically, just a client application written in JS. No special frameworks, no complicated toolchains. Even that is a pain in the ass because the web world hasn't quite worked out how to store local data in a non-stupid way.
I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is supported by all browsers and all you need to do is de/serialize your data to JSON when your data changes.
- Redux with a middleware that saves the whole state to localstorage automatically
- Some simple background timer stuff that uses ononline and onoffline events to know when to poll for updates, then dumps the JSON contents from the polling into the Redux store
- Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary
Then stick some Progresssive Web App stuff in there so the whole bundle can work offline entirely from browser cache.
I don't want to save the whole state automatically. The state isn't complicated. Even the data isn't complicated.
> Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary
Or I just write some javascript that creates a view of based on the data it has cached locally and updates that view when the user interacts with it.
This is what we're talking about. I have a relatively simple problem, I don't need to pull in additional dependencies in the form of a framework that's just going to make things more complicated and require me to learn its paradigms.
If you don't want to save the state, why mention localstorage in the first place? The point of using the Redux thing would be to automate that process, so that you don't have to manually save/retrieve anything to localstorage yourself.
No configuration of babel or webpack or whatever to worry about, just host your app as static files that point at your API.
https://riot.js.org/
`node_modules` directory topping 60+ mb means nothing when the final product is an optimized bundle or a `node` process loaded in memory. A large majority of developers don't care about this because they're just looking to get actual work done... not sure why you're trying to "fix this".
I'm also not sure what you're talking about when it comes to unclean code and complicated tooling. The tooling is dead simple... much simpler than the NuGet/IIS/OWIN nightmare that is C# development.
I think you're very close minded and you'll likely be stuck in .NET land forever. And that's okay if that's what you like or if it's what gets you a paycheck. But to completely dismiss this ecosystem as if it's not productive... it's just a sign of naiveté. Good luck.
With WebAssembly, C# Razor Components will soon be able to run either server or client side and still maintain the same highly productive development that's missing from JS.
Building a complex app is different though and much easier and faster in a proper environment that has strong typing, OOP, interfaces, reflection, dependency injection, a solid standard library, and more. Being able to use that same environment to create frontend views and code will greatly improve productivity compared to the current Javascript frameworks and limitations.
Strong typing is admittedly great and there are solutions to introduce that in JavaScript. However, this is hardly a dealbreaker in complex apps written in JavaScript.
OOP, interfaces: debatable and unnecessary fluff. There are plenty of productive languages without OOP. Example: Elixir. And there are plenty of productive languages without interfaces. Example: Go.
Reflection is unnecessary in JavaScript. You can access any property within an object dynamically and the language is interpreted, so there's no need to perform fancy reflection operations at runtime.
Dependency injection is an engineering pattern. You can apply this to almost any language. And ironically, plenty of JavaScript backend and frontend frameworks have attempted to use it successfully: Angular, Ember. Hell I even wrote my own DI layer once upon a time. https://github.com/divmgl/nwire
I'm sorry, I really disagree with you. I believe C# has the ability to be productive, but there is just no way you're going to convince me that it's superior to JavaScript and its ecosystem. There's a lot of disdain on Hacker News for JavaScript and it's honestly beyond me.
Writing your own http server is difficult in both.
Vue cli new project run.
New asp.net project run.
It’s identicle.
Try to write both for scratch is hard.
So no node/npm/http server is no easier than .net/iis/owin.
I use Rails, but Rails views are a disaster. You can use a lot of different patterns/gems, but still, logic is highly coupled with the view layer. Personally, I like Phoenix approach with templates + views. But still writing script tags makes me cringe a little bit.
But I wouldn't discourage people from using SPAs, though. If you are gonna have a lot of buttons, modals, different tables, charts, forms and stuff like that, I would go SPA. Or first serverside -> SPA. Especially, when you are working in the team, it's so much easier to tell one person to craft this json api and another to craft this design with a consumer for the json api.
That become long... in short: if you have a small team or solo go server side 99%. If you have a big team or app that's gonna be very heavy UI -> go full spa or go server(mvp) -> spa
For example maybe an Order only needs a price when it's created, but needs a invoice number (and some other validations) when marked as paid, but an admin should be able to override those validations at any stage. If you are doing something like that with standard Rails the model is going to end up as an untestable mess, where as the form objects can be tested on their own.
My only complaint is that the creators of Trailblazer really don't seem to like Rails, so trying to get them to both work together can sometimes be a bit tricky. And the documentation is lacking if you want to do some more complicated things.
React was introduced in 2013 and angular 2 was created in 2015.
The only server side rendering I'll be doing in the future is with the likes of nextjs or similar.
Aha, by mistake you corrected your grammar! HNers cargo cult everything, including grammatical mistakes like "an SPA" ( see literally everywhere in this thread). Just say it out loud, "I start with an SPA", does that roll off the tongue? No, neither does, "I'm going to buy an sailboat". However, "It either needs to be a SPA, ..." is totally natural.
While this comment may not seem on topic/useful, it's a useful meta comment -- please don't take offense.
Now I can read SPA posts without cringing...
I'm reading it as "an S-P-A" now and it feels so, so much better :)
1. Reusable web components. 2. Clear separation of backend and frontend logic. 3. Using the latest version of javascript.
I really like HTML/CSS/JS as tools for building GUIs, but I feel HTML/CSS specifically suffer from the inability to make components.
I think there are definitely instances where there is no need for these tools. I would genuinely like to know how to manage the items listed above when this is the case. ie Recommended tools for when I go "SPA seems like overkill for this... what are my other options for this functionality?"
They offer a ton of advantages, especially speed of development if you have a clear separation of frontend & backend logic. If you can mock your backend & develop the front end all by itself without any other code needed, you can go at crazy fast speed. You are also able to focus on UX/UI without needing to think at all about the backend. I feel there is a ton of value in this, whether or not your app is a SPA or not.
I think tools like Gatsby will make building actual SPAs easier down the road. They offer huge speed advantages the longer someone is on the site. Though one could gain a lot of these with just preloading content & HTTP/2 as well. As the article said "It all comes down to tradeoffs". I would also argue what resources you have available & the value of speed on your site.
Are you familiar with CustomElements? https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
The current culture is to only keep a job for ~2 years before moving on, why wouldn't they adopt that attitude?
One day I just ditched the SPA and rebuilt the whole architecture with NodeJs and Express. I was done in a few days. It could have gone even faster, but the original static site was really a mess with years of accumulated bad decisions embedded in it.
I know this is just one data point and not really proof of anything. Nevertheless, the linked article made a lot of sense to me. Most of the bulleted points resonated with me, but none more than the SEO issue. There are solutions to the SEO issue, but I personally did not find them easy to implement. If I were part of a big professional team, and we really needed a SPA, I would have called this one differently, but I was working on my own, and I didn't really have the sense at first to see that I didn't need a SPA to achieve my goals. I was perhaps a bit too susceptible to the hype without enough experience to really understand the issues involved.
You get streamed JS, with pre-rendered HTML for SEO.
Or nosql.
Or containers.
Or graphql.
Free tech is not zero cost tech. Size your stacks to your actual needs.
But in reality...I only need it because people on the other side of the interview table expects every engineer to have 3-5 years experience of x,y, z.
This article says traditional web servers are stateless, but in the case of SPAs servers are stateful. The opposite is true. Traditional web servers have session state, but in the case of SPAs the servers can be stateless because all servers are responsible for is persistence and query/search.
This article says maintaining browser history is a mess in SPAs. Not true. The same MVC architecture that works so well on the server can be done just as easily on the client, see this lib: https://github.com/Rajeev-K/mvc-router/
This article says server-rendering has fewer more mature tools. That may be true. There are so many new tools for SPAs. But you can ignore them and build SPAs trivially using the libs mentioned above.
This article says server-rendering is better for SEO. Not true anymore. Google and Bing crawlers now execute javascript to crawl your content. This is more work for Google and Bing but not more work for you.
If you know how to do it SPAs are the easiest and best approach because all the server needs to do is implement persistence and query/search using a REST API. If you later need a native mobile client this approach is already more compatible with mobile than if the server renders HTML in addition to persistence and query/search.
When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.
And React by itself is very simple, you don't even have to use JSX. It's a great templating library, with great documentation and a huge community.
Not true. With Redux you write reams of actions and reducers and other such unnecessary crap in the name of state management, when in fact most client apps don't have state, all they do is fetch data from the server, display it, send updates back to the server.
React used to be a simple lib, now it is getting more and more complicated. Look at the libs I mentioned they are way simpler.
>you don't even have to use JSX
But JSX is the good part of React. You get compile-time checking of your expressions if you use TypeScript and you get syntax coloring, intellisense etc for both HTML and JavaScript.
I agree JSX is very nice. It's one of the best features of React, and another reason React is a great templating lib. My point was you don't need it. React does a lot of other nice things like browser compatibility, event management. If you want a smaller implementation, use preact or some other template lib.
When dealing with React and Redux you are just dealing with functions. You could do everything in pure functions.
You don't have to deal with any of that crap.
The best part of React is DOM diffing and incremental screen update. Obviously this is only useful if your application needs to update screens it previously rendered. In fact I'd argue that React is only useful if you need to incrementally update complex screens, because simple screens can be re-rendered completely and no one will know the difference. Very few applications need to incrementally update complex screens. If your application doesn't have this need you can use simpler technologies that don't have the same "Care and feed" requirements of React, such as UIBuilder: https://github.com/wisercoder/uibuilder
Just because you use pure functions doesn't mean you don't get DOM diffing, that's silly.
But the very fact that we're having this debate is proving my point. React's programming model is unnecessarily complicated. JavaScript + DOM is all you need. The simple libs (each less than 500 lines) I pointed to get you close to this without sacrificing productivity or code maintainability while keeping the programming model simple.
React isn't complicated, you're making out to be.
Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build.
Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several changes, across directories and languages in both the front and back-end, and usually two different build chains.
You can do exactly the same with server side rendering. In all the applications I've built over the past decade, the only state I've had is an encrypted session cookie to say which user you are logged in as - but that's send by the browser on each request, so it doesn't matter which server handles it.
The urls I've built are basically the same as you would for a REST API, to view a widget you do a GET /widgets/1, to view the form to edit you do GET /widgets/1/edit, to save the update you to PATCH /widgets/1, which redirects you to the list of widgets at GET /widgets. I admit that trying to fit multi-step workflows into this scheme doesn't always fit so nicely, but with good API design (that's what you are building, an API for the browser to call directly without JavaScript) you can make it perfectly stateless.
If you provide an API schema, with a SPA the whole frontend can be developed separately of ever touching backend code. Okay, so you changed the name of model.thing to model.anotherThing - quick change in the reducer that is consuming that end point and call it a day.
What ? These are all javascript things, right ?
(If he means SASS vs SCSS syntax, I recall using SCSS ~8 years ago, so it's an odd choice to include either way.)
Once you've used grunt, using gulp is not a big logical jump. Then to webpack. Whatever, they're just build scripts! Roll your own shell scripts if you want! A day to learn them, or a lifetime of being a hater.
The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynamic UI elements.
And rewriting down the road because of the wrong gamble can be very costly. Make the wrong bet enough times and you'll see that it's not over-engineering but just engineering for changing requirements.
A classic example is thinking it will be simpler to avoid React and use a few .show()/.hide() toggles. Simple at first. Then as you take on complexity, you start to feel like the lumberjack who thought he could save time by skipping the axe sharpening.
Use JS rendering for all your pages but continue to use Laravel for routing/passing data to view: https://reinink.ca/articles/server-side-apps-with-client-sid...
We're getting closer to the best of both worlds, where we SSR pages and then "hydrate" them with JS components. The tooling around this isn't great yet, but it's definitely all there.
JAM-stack etc. just create static html/css/js and deliver it over a CDN of your choice, then hook into the services as you need them...
On the other hand, to get your Rails site to function that well takes a lot of work - it is by no means the starting point.
Systems like Next.js and Gatsby.js and others are attractive in that A) they offer the ability to use both server-rendered and client-rendered React, and B) exceptional performance is the starting point. It's up to you to slow it down, not speed it up.