I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. So basically the same reason, except for managers to impress investors instead of developers to impress potential employers.
Not saying all SPAs are mistakes; some uses clearly are not. But most of them are.
Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technologies.
So a developer may even be aware it doesn't quite make sense to use a single page architecture, but they know that if they have it on their resume it'll help them make more money at the next job.
It's a whole maladaptive signaling phenomenon that arises out of organizations overvaluing the wrong things in hiring.
Some may be aware, but certainly not everyone.
1: Google's abandoned webapp toolkit where you get all of the drawbacks of writing Java code with none of the benefits.
Angular everything and everywhere and sprinkle it with Material Design!
I'm learning Clojure at the moment, don't think I would have heard of Google Closure otherwise
People use SPA frameworks and make SPAs with them and those SPAs end up functioning exactly the same as any Rails/Django/Laravel site except the URL bar doesn't change. MVC is still the way the web is built, except for the people who got bored and wanted to make web development even harder than it already is.
YAGNI.
The problem with that is, blogs are a poor barometer for that sort of thing. Nobody needs to write new blog posts about tried-and-true things that are already plenty well documented. The more solid and stable a technology is, the less incentive there is for anyone to bother writing how-to blogs about it.
For me the major advantage of vuejs over jquery is the way data drives UI
Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns out that the ask was coming from the C-suite, who wanted to put it on a slide somewhere because "everyone is doing machine learning, we need to do machine learning."
[1] https://www.informationweek.com/big-data/ai-machine-learning...
That being said, as someone who has done a lot of infrastructure work, I do like web technologies that can fit into something like serverless and Ruby/Rails really isn't there. Speed, file size, and boot time all become much more important. Or if you can make it work, fully static pages that can live on S3/Cloudfront and any dynamic needs are abstracted away to API gateway/Lambda and pulled in.
I would much rather have an app running inside of Lambda instead of having to manage a load balancer and AWS auto-scaling, or even elastic beanstalk.
So many problems can be dissolved down into people picking the wrong tool for the job.
I've worked at places in all four quadrants of should/shouldn't and do/don't use microservices.
They're GREAT when they're the right fit.
Most websites aren't really a right fit and do fine with a classic webserver->DB setup.
But in reality most work is very simple. Most work does not require new shiny technology. Most work is insanely mundane.
Outside the software business, on companies whose focus is totally unrelated to software, no one cares that much how things work.
They just have a couple of devs, or hire some freelancers do do some stuff, no matter how, it just has to look pretty.
There are clearly good uses for SPAs, but the author is totally correct that most sites are "open, check, close" experiences.
If it's not essentially a web based, desktop app...it's much harder to justify. Real tools. If it's not a tool and the user workflow is "open, check, close"...it's serious overkill.
Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.
This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.
The UI can manage the state in very responsive manner. No round trips, instant 60fps render.
And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.
Don’t throw the baby with the bathwater.
Most of the time I find the initial delay loading/parsing the js to be more problematic than the often tiny speed increase of subsequent loads.
Furthermore, these days it takes minimal to no tweaking to get server-side rendered pages to load fast enough to barely notice the difference (in particular if the client-side is retrieving and parsing JSON in the background through an API request). Perhaps non-webdevs are even less likely to notice this stuff.
> If done well you can totally run offline.
That's definitely an advantage, but most SPAs I encounter don't offer offline functionality, or it's entirely unnecessary to offer it.
> Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.
In some cases that's definitely an advantage. But it's entirely feasible to build an API-based backend and use that API internally for server-side rendering. If you want an app that plays nice with search engines you have to do this anyways.
> This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.
That doesn't make sense to me. One of the biggest issues I have with SPAs is that you now have to deal with the backend state (DB) and a subset of this state on the client, which dramatically increases complexity (state management, sync, etc.). I rather like the old-fashioned approach where all state remains in the backend, except perhaps for the tiny bits you'd put in a cookie (and I suppose the URL could be considered client-site state too).
> The UI can manage the state in very responsive manner. No round trips, instant 60fps render.
How many apps do you use where you really need anything below say, sub-second rendering? Frameworks like Phoenix and/or caching can be much faster than that even (in the order of microseconds).
> And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.
Clearly if so many SPAs are bloated Mb-size messes, it's not trivial to solve. And it's a problem you can almost entirely avoid if you keep the rendering on the server. After years of agonizing over bundle sizes, I find it incredibly liberating to not have to think about this anymore (much of the time, anyways).
> Don’t throw the baby with the bathwater.
I do agree that there are plenty of use cases for SPAs, but I also agree with many here who say they're very over-used.
I'll add that there are some interesting initiatives to have 'old-fashioned' applications that also get to be dynamic enough for many if most use cases. Phoenix LiveView [1], for example, takes advantage of very fast server-side rendering, websockets, and sending subsets of the templates as HTML snippets to the client, where morphdom simply diffs the HTML string with the element it's supposed to replace. With great performance.
[1]: https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
This may be even meaner, but they usually end up demonstrating they can’t. 99% of them are terrible. Even Google’s latest efforts are a bit on the slow, low-information-density side.
SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's.
server-side html generation now feels like cruft and an awkward way of building applications.
And yeah, they're also common in situations where they're not the right solution because either devs want to turn their current employer into the next Google, want to build up the CV to look good when interviewing for Google or have a boss/investors who like shiny things in general.
Citation needed. G-Suite's admin pages are half "modern" SPA monstrosities that suck up my RAM and peg my CPU to render a bunch of whitespace with bits of information strewn around, and ugly but functional regular pages whose performance is killed for being framed inside a SPA frankenapp.
If you're building web applications, it's usually easier to build with components than to think in terms of web controls. If you can separate state slightly from the components even better. This is why react + redux scales well. It makes very little sense in smaller apps, or those that are mostly static. It makes huge sense when you have hundreds or thousands of components, and a lot of application logic and structure.
It isn't just because management wants an SPA... sometimes an SPA is the best option.
Of course each application has different needs, but for large multi-developer UIs, I think a better option is to split your front end into distinct server based pages where you leverage React/GraphQL/SPA/PWA features for great DX within those pages. That way you can keep it fast and potentially limit some of the complexity.
Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.)
Is the "app" boundary further along the chain, like at Google Docs?
I think instead of trying to come up with definitions to classify things (and probably argue for the meaning of those definitions from the conclusions we want to draw) we should ask,
- Will this help developers?
- Will this make users lives better?
I remember a while back I wrote a blog post where the main topic was "You're not Google (unless you're Google)"[0]. It was related to micro-services but the same thing applies to SPAs too.
[0]: https://nickjanetakis.com/blog/microservices-are-something-y...
I mean for SEO sure, but I usually am not concerned with SEO at all.
Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS?
Many times SPA frameworks are used because it's flashy and more exciting than writing basic html and css, but more often than not that's all you need.
With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets, but while it was a lot of typing, it was all fairly easy, and if I wanted to change how an event was handled, it usually only involved a component and MAYBE the components immediately above or below it in the component tree. Data passed further than that was generally wrapped in objects and therefore didn't require code changes.
Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? I wrote a good amount of code in Redux, too--I worked on teams that used it--so this wasn't just pre-judgment. These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do.
And once you're doing that, you HAVE TO write an SPA, because any part of the page you want to be interactive gets pulled into Redux and your JS eventually eats the whole page. It's an infection.
When writing JavaScript now, I sometimes end up rolling my own version of the component style. It's an effective design pattern for UI widgets. But it hasn't been worth it to use React for a while now because the tooling and tutorials are all too conflated with Redux and similarly awful tools. And on a team, there's always the worry that someone on your team will infect your code with Redux and it will grow and consume your entire site. It's a real shame.
Redux offers a few benefits:
1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test.
2. Allows you to "time travel" the state of your store using the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably.
3. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild.
While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.
The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc.
If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces.
With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance.
What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.
2. This is only marginally more powerful than a debugger.
3. I would consider this allowing you to shoot yourself in the foot. Explicit is better than implicit, and explicitly defining your dependency tree is a benefit, not a downside. When you're feel the small pain of having to explicitly define a data dependency, that prevents you from introducing it if you don't have to, thereby avoiding the much larger pain of having an overly complex dependency graph. By adding Redux you're adding hours of debugging time on complex global dependencies to save yourself a few seconds worth of keystrokes.
As to other comments about logic in the View or State, it's bound to happen... the two aren't actually divisive concerns. Personally, I'm happier to use Redux than seeing prop drilling everywhere.
I'm not sure why you think the data is irrelevant, or why the component manages it "weirdly".
I'll point out that these top components actually share a lot in common with Redux, except that they can be duplicated and composed with other components, if for example you decide to drop your top component inside of a larger application, and the toplevel components actually don't end up managing data they don't have to (LESS "irrelevant" data than Redux, perhaps?).
Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience.
(Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)
Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though.
Often, as you learn about the structure of the data, it becomes useful to change how the data is structured and stored. In global state, you can change that in reducers, sure, but then all the places that render that data have to be updated. You don't have the option to represent the same data in different ways that might be more suitable for different parts of the application. You either have to change them all at once, or synchronize a bunch of states that really contain the same data (which is even worse).
With independent components, you do spend some time synchronizing data across components, but each component has the option of how to represent its data internally, so the effects of changing data representation in one area are usually very local, and each area of the code gets to represent the data in a way that's reasonable for what it's doing.
I'll also add that with independent components, you sometimes get components whose only real job is to manage data. That's actually sort of like a Redux! But you can spin up multiples of them without having to manage an array, and compose them or even nest them without issues.
> (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)
To be clear, I don't really care about boilerplate. It's easy to generate that stuff, but even if you write it by hand it's faster than debugging implicit, hidden complexity. Boilerplate ISN'T the problem with Redux, as far as I'm concerned.
If you keep your state in a component, you don't need any housekeeping, once the component is gone, the state is gone.
This is not true with Redux. You have to keep remembering to clean the state after you're done with something or you're going to introduce a bunch of bugs.
And I thank my teacher for knocking the bad habit out of me. So when I see global variables beyond the initialization of core objects, I take it as a bad code smell.
Many people just use setState.
Since my last Redux project in 2015, I did many React and React-Native projects and not one of them used Redux.
If you don't use redux, then keeping state synced with a server side rendered application because nearly impossible.
Could you explain what you mean by "server side rendering state"?
Fair point. But could it be possible that there are lots of people doing React that never went to college and never wrote Python or C programs?
Most apps are fine serving html, using plain old boring forms, and having the odd React or Vue component where necessary to do some heavy lifting for user interactions. Moreover, it's a lot quicker as a small team to iterate.
Not that react isn't great for traditional websites, I've just seen too many fullstack or backend devs struggle with it, so if they're going to be involved in the frontend it may be worth considering the alternatives.
The updates are handled by JavaScript and http calls.
You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.
Previously I had never built a real product in Rails, only the book store tutorial. I'm really happy with Rails so far. I don't have to worry about a lot of shit I had to worry about in JS land and now I can focus on the app itself.
Even JustWatch.com seems like it's fairly polished, still has it's quirks. So, I just end up using InstantWatcher.com instead. Hacker News works well as is too, except the search on the bottom can act up it seems once in a while.
Edit: How could I forget, Netflix. The UI, getting to the details of a show/movie. Browsing, discovery, searching, it all feels broken and unintuitive. The DVD site last I checked was still decent. Netflix seems like the poster child for usability and regression issues moving to a SPA.
Honestly, your website is probably the best implementation of a SPA website with multiple pages I have ever seen I can recollect. It still has quirks though. I just don't see why you would want to make a website like this a SPA.
Does that help a little? I wrote this quick, off the top of my head. I can try and provide more details maybe in an email or some other communication means too.
https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
I hope to see this idea brought to Rails, but the its websocket story doesn't seem there yet.
HTML rendering with Phoenix is lightning fast. https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...
so if i have to rewrite my js with this just so i could fake SPA then benefits are so much smaller
Compare this with rewriting your app as an SPA.
https://github.com/turbolinks/turbolinks/blob/master/README....
Turbolink is a crutch for people that are not able to server side render an html in a few milliseconds.
It's fetching and replacing the HTML that needs to be changed, but removes the need to do a full-page reload, so the browser doesn't have to re-load and re-parse all of the HTML, and JS, and CSS. Even though the browser will keep a lot of this stuff cached, Turbolinks can make a site feel a lot faster from a user's perspective. But regardless, it's more than just a loading bar at the top of the screen.
Whether it's the right fit or not depends a lot on what you're trying to do.
Then I tried mobx, I was able to write a small app after 15 minutes of reading the docs and now I love react.
Meanwhile, relying on setState alone for complex components ends up being very error prone and tedious. I still rarely use MobX for global state because I prefer the original appeal of React in terms of making modular, reusable components, but I often use MobX as the state mechanism for my more complex components and bypass having to rely on setState altogether for those components.
Not that either one was really all that necessary in the first place anyway.
I’d like to try and make it work offline. To do that, and do it well, you need a way to show the data in different ways even when you can’t call a server.
I often have "What the hell is this thing doing" moments as a web app hangs trying to complete a round trip over my mobile connection when I know it has already fetched the information on that page or I know it could be doing something useful despite not being able to connect.
The author is not proclaiming that SPAs are a bad idea. He's just pointing out how much extra work they are, and that some types of apps are worse as SPAs, or simply much harder with nothing to show for it. He even points out that not all the badness of SPAs is intrinsic to being an SPA:
Why does a website that orders food from restaurants need a Megabyte of javascript?
I tried to figure that out by inspecting the API calls. It turned out they were tracking every mouse event.
In short: 1) horses for courses, and 2) SPA apps are a lot more work and you have to decide when the benefits are meaningful. Less contentious but maybe less fun than trying to argue which is the one to rule them all.
On the other hand, I also maintain a public facing service that is mostly server-rendered with lots of JQuery snippets. I don't see a need to convert it to a SPA. It works well as-is.
I conclude from my experience that public facing services probably shouldn't be SPAs, while things that outgrow spreadsheets might be good candidates for SPAs. I wonder what other areas have been explored.
Saying stuff like this is sure to please the hacker-news hipsters. But... is this honestly anyone's experiencing using new web technologies?
I tend to be on the bleeding edge of tech, and I very rarely regret learning a new technology. And I do not feel like I am wasting all of my time flitting from technology to technology.
I just think this is a smarmy attitude disguised as wisdom. People should like what they like. And as someone who has had to climb that hill before: Waiting around not expecting the world to change around you is a losing bet every time.
The fool doth think he is wise, but the wise man knows himself to be a fool.
> The fool doth think he is wise, but the wise man knows himself to be a fool.
I fear that this wasn't meant to be ironic.
In the past a 'SPAs' was build on top of more solid foundation like smalltalk or later Delphi. Most issues is that the browser stack, put it in real terms, is not the "right tool for the job" and will never will, without serious re-engineering.
People can, and have written bad websites using every technology. I can think of plenty of badly written, hard to use MVC websites from my past.
It should come as no surprise, that bad developers have found ways to make badly written SPAs as well today.
I don't think we should judge a technology by its worst implementations.
If you start with how it's going to end -- it's not going to end well.
Having said that, what you're most likely seeing is that a ton of tools and frameworks are built for no other reason than 1) Coders need something to create to show other coders how awesome they are, and 2) People want something that works like everything they know -- it just does these one or two new things
This is a great way to make a mess over a decade or two, and you're right for waiting it out.
Make a SPA if you need a SPA. Key question: How do I know whether I need a SPA or not? (Or whether React makes sense, etc)
While SPA tooling like React are incomplete since they don't provide all of the client/server data communications that comes for free with a server side application. That is starting to become more "standard" as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who's spent their life with REST.
Most applications should be SPAs to create the interactions that users expect.
Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess.
Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.
1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong...
2) People either have huge functions that are spaghetti or tiny little functions to avoid complexity that are one line if statements.
Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.
React is about components and you can use React in something like NextJS which is not a single page app but a server rendered pages.
Also, SPA itself is getting outdated concept, now most apps are hybrid of initial bundle followed by a dynamically imported modules. Finally, MVC is a pattern for web pages, the complexity in the client side because what is the being shipped to the browsers are a client side apps with their own router, render functions, state management and APIs.
The modern, offline web is great. If we had to do this in a native app we would never have gotten the project off the ground, because we initially need to use BYOD phones which were evenly split from iOS/Android. We'd have had to use three languages, but a Mac, get developer licenses, and learn Swift and Java just to get an offline frontend, and sharing business logic code would be impossible.
React with well defined static content routing and server-side rendering is amazing at this because the first packets that the server sends the user is html/css jumble.
You can get your app to show text and formatting in as little as 20ms(depending on where you deploy it), then show images, then you don't care if the rest of App and all the js and 3rd party crap take another 2.5s and 3mb to load, The user will do a bit of reading and picture watching, before using a button or input field. However if they're on the go and loose connection, now they have a fully functional back button in their browser to read the next or previous cached html/css content.
We've been "server side rendering" since the inception of the internet.
If you build your pages with CSS at the top and JS at the bottom you're already achieving most of that effect right there, no extra tools needed.
The browser will load the css and content first, and then process the JS requests (Which are easily cachable by the server AND the browser).
I'm currently maintaining alone two large websites and only one of them is an SPA, that's definitely the harder one to maintain by far.
- Render all pages/routes/states into a single html file (size ~2mb) but each page/component/state hidden via style=display:none;.
- then write some hand crafted js (few hundred lines) to add event listeners to forms and show/hide the components depending on url change
- cache everything via appcache/serviceworker
- result: not so fast initial load (1-2 seconds) but really fast interaction afterwards even on old lowend devices, almost no time spent running js/react/vdom. even some scrolbugs I had to work round before when using react (eg replacing dom nodes but keeping scroll position of a parent container) resolved on their own.
That's only 1-2 seconds on a fast connection.
If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds.
Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.
nothing else because all images are already inlined as svg as well as all styles and the mentioned js code
> Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.
I only came up with doing it this way after previously having build the same app using react and old devices (eg android pre chrome) could not handle all the vdom diffing and add/removeNode.
Our users preferred a slightly longer initial load (even 10 seconds) and lightning fast interactions afterwards over fast initial load and sluggish UI for all the time using the app.
When doing client sit rendering you would still have to transfer and parse little chunks of json all the time.
As it turns out browsers are really good at handling even huges DOMs as long as you do not manipulate it to much.
Granted this way only works if you have a limited set of states/pages (eg a few thousand).
Do you have a public implementation available for review? I'm having trouble understanding why this would be the case (I am pretty familiar with React's implementation).
>Render all pages/routes/states into a single html file (size ~2mb)
That's not good at all for mobile web pages.
One option is to become a programmer for hire. You keep your skills up, and those skills are as much about getting a job as doing the job. You re-study data structures and algorithms. You can permute sets, find matching subtrees in binary search trees, and answer questions about how addresses in web browsers are resolve to web sites. You learn java, then GWT, then EJB, then spring, then struts, then you add a 2 to the end of struts, then Rails or Django, then you give it all up and do it again in Javascript, React, Vue, Ember. You also play the agile "estimate roulette" as you write down tasks and expected completion times in JIRA, and are asked about deadlines every morning in an almost inevitable corruption of the original methodology[1].
You would never do this for your own project. If you had an exciting new idea, the last thing you would do is go off and learn to find all subsets of a larger set that, when concatenated, form a member or the larger set, at the whiteboard, in 45 minutes. It's also fairly unlikely that you'd set out to write an SPA for many business ideas. But you'd definitely be doing this if you were applying for the next job, which you sort of always are doing, if you're a programmer for money. Even if you aren't looking to change jobs, you still do this, by and large.
Or, you can become the kind of programmer who creates a product, chooses the right tool for the task, and makes it work. The reason that this is difficult is that these jobs are rare. To really have this option, you often need to make the leap into doing your own thing.
That sort of entrepreneurial skill and mind-set seems to be orthogonal to most programmers. I couldn't tell you if it's innate or learned, but I do know that it's a big leap, involves risk, requires a period of economic uncertainty that is tough for people with dependents (or people just trying to pay rent and make it through the next few months in an expensive city). But it may be the best way out of the programmer-for-money quagmire.
The thing is, if you have that kind of entrepreneurial spirit... well I'm not sure you really need to be a programmer at all, there are all kinds of great opportunities out there.
[1] Yes, this is a bad case. Not a worst case, but a pretty bad one. I'd say all programmers for money have gone through some version of this more than once, but I'm putting them all together into something that is more grim than most have to put up with.
A lot of the "modern" toolsets just aren't worth the extra fluff they add.
Writing SPA's in React, Angular, etc. tend to result in a very heavy first page load, then api calls with poor UX for all actions.
Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
You can, but often that's not what's happening.
E.g. crates.io is currently built as an SPA. It is first receiving a HTML page that loads a javscript file, that performs an XHR request (actually, multiple) that answers with JSON that is used to create the final DOM of the page. The Javascript file is cached but that's about it, it still involves one additional needless roundtrip for the website.
The JSON sent is so badly designed that it alone is far more than the final DOM of the page.
Jus check out this: https://crates.io/crates/winapi
vs this: https://crates.rs/crates/winapi
Only the XHR requests for the crates.io page take up 99 KB uncompressed, while the entire crates.rs winapi page takes 103 KB uncompressed.
Because a user doesn't care if it's the initial frontload or not.
Did the company or the end user benefit from this? Hell no. Only one benefiting were the developers who ten left and asked for a 10k more salary on their next job for sporting that fancy new javascript framework. NICE!
I like separation. I know that one side ( ruby, rails, gems, pg, sql etc ) is all about data -> one mindset.
Another side is about views ( js, css, html, multiple select, date pickers, autocompletes etc ) -> different world.
I build my assets in one place, I work with my data in other. I wear one hat as a backend guy, and when I need refocus completely on front end work.
I wouldn't argue it's easier, but I think it's easier for me. I like it better.
Plus, the API will be consumed eventually by user-facing site and apps.
For that latter part, although I must recognize that the tooling has evolved into a quite complex pipeline (which is a cognitive investment, almost a gamble, in itself), I also clearly see the benefits of a set of ideas that have rapidly evolved in the turbocharged settings of the web development ecosystem:
React: the distillation of many programming paradigms (functional, composition over inheritance, etc) for building UI components.
TypeScript: the augmentation of JS with mature and powerful programming constructs.
Material: a visual language for UIs with a strong focus on coherence and being truly cross-platform.
All in all, although I'm well aware of the critiques that can be addressed to the modern webdev environment (the so-called "JS fatigue"), I feel like all these new tools empower me, and I really enjoy learning about them.
P.S. If you folks want a really small react-like SPA, I recommend either https://mithril.js.org or https://riot.js.org
And you can avoid state management complexity by using a pattern like http://meiosis.js.org
I don't want to go back to Rails/PHP/Python though. I like having a REST/GraphQL API. With Hasura I don't have to worry about backend anymore for 80% of the cases.
What I'm doing right now for the front end is using Jekyll with Vue. It's really liberating not having to worry about a router or managing application state anymore. For certain in-house projects I don't even have to use Babel or Webpack anymore and still get to use Async/Await.
Maybe that'll change if I decide to build games with HTML/JavaScript/CSS or want to make some sort of online version of a desktop program, but nothing in my current ideas list is app like enough to really warrant the SPA setup.
so, basically a "functional" front-end view-framework for client-side behavior, but with no routing.
1. Tons of existing jQuery components.
2. Ten of custom, loosely coupled ones.
3. Built-in PubSub for their communication:
$(document).on("custom-event", function() {...})
And you can do any SPA out there. Or not SPA.
I get the definition, but I don't see a lot of problems and etc .... necessary a part of SPAs.
Lol, a 3 year solution. I immediately feel sorry for the future devs jumping into a codebase like that on New Year's 2023 trying to figure out what broke overnight.
When you start thinking about field validations and having to duplicate them client and server side, it makes even more sense.
The speed benefits are noticeable on sites where you're doing a lot of internal navigation. But you can just as easily make a slow SPA (see JIRA).
So I guess in the end, do whatever takes less development time. Which usually isn't an SPA, just because there isn't really a good framework that reduces effort required. Rails and turbolinks are pretty legit.
Mr Goldstein would have known this if he had visited the Meteor blog (https://blog.meteor.com/) and Meteor forums (https://forums.meteor.com/).
It's a great tool if that is your goal. Otherwise why spend the extra effort?
Without JS, Server Side JS defaults to good old school MVC.
I had actually never seen that written solely as SPA even though I've worked as a react dev for 2 years now in Canada. I guess the acronym really is going obsolete.
IE. Purely JS driven, no browser-page loads after the initial page has loaded.
Are there any barebones tutorials out there for CRUD apps that don't require Node.js, Python etc, and can be learned using PHP, MySQL and HTML?
Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k).
Even if you make your site extremely lean, it's still a worse experience, and let not forget that for the majority of sites lean is far beyond them (not the least because you must integrate third party code such as social and analytics or fade into obscurity against those who do)
So some developers feel that the old way of doing things is just fine. There are always some of those. Probably the same ones who surf the web with js disabled. This is not even remotely what the average person expects and anyone who thinks they can build a website like that and compete are delusional (and hacker news is perhaps the exception that proves the rule. Even google is not html only anymore)
I used a lot of applications out there that aren't SPAs, I browse with JS turned on, and I believe that SPAs are nice in certain use cases, but for a large portion of web applications, you are primarily doing simple CRUD work, and don't need an SPA for that.
A proper example is something like: "Parking allowed on Fridays", which is an exceptional case to a rule that is implied: "No parking any other days."
Just a heads up, feel free to ignore.
If we are going by wikipedia definitions, then: "A rural village is "always" quiet. A local farmer rents his fields to a rock festival, which disturbs the quiet. In this example, saying "the exception proves the rule" is literally incorrect, but it is used to draw attention to the rarity of the exception, and to establish the status of the village prior to the exceptional event. "
Seriously, I've tried looking it up... https://acronyms.thefreedictionary.com/SPA
These, combined with Angular CLI or Create React App, allow me to be just as productive as the pre-spa days
Nobody worth their salt would recommend coupling display components and database manipulation together in an iOS or Android app. A webpage is the same thing, because it's not running on your server, it's running in the browser on the user's computer.
With this blog post, like most "I don't like X technology" blog posts, I find myself asking, "does the author not like this technology, or has he not taken the time to become a real SME in it?"
We had a SPA using OAuth.
I spent a few weeks adding docs, ran Swagger codegen, then declared it finished. Every call our front-ends used was now part of an API. Then we just trimmed out the parts we didn't want to officially support.
They override routing, they override SEO, they make it hard to use build in browser tools, etc, etc.
Additionally these frameworks are harder to debug thanks to leaky abstractions.
The only front end abstraction I've seen do it correctly is Elm. I'm not saying Elms' pattern or language is good or correct; (I have no comment about that) I'm saying that the abstraction isn't leaky. No javascript errors in Elm, just elm level errors. React Vue and all these modern frameworks need to be handled the same way.
I know technically that react is just a framework and not an entire language over javascript, but the ways and technology React is typically bundled with makes it a leaky abstraction and the common use case should be handled.