Create your own dysfunctional single-page app | Hacker News Reader

Create your own dysfunctional single-page app

tinnedfruit.com

208 pointssemanticist138 comments

IMHO the whole advantage of single-page apps is about separating the UI and the data + using the browser as a cross-platform UI toolkit, runtime and deployment engine. The reason for SPAs to exist is that browsers are the only way to deploy an app that runs on every OS, looks pretty, automatically updates in an instant every time you run it and can be discovered and ran by everybody in a single click. Just imagine a world where something like WPF was made a truly free standard with full-featured 100%-compatible open-source implementations available on all the major OSes (Windows, Mac, Linux, Android, iOS) from the beginning and packed with efficient support for apps to be ran straight from a URL.

I imagined a world of apps designed with xaml /me shudders

Why? Doesn't it suit designing apps better than HTML or anything?

you tell me. Real world examples lead me to believe otherwise..

After doing that for the last four years, the prospect of focusing again in Web is what makes me shudder.

Interesting, i've had the exact opposite feeling with XAML. I've written a bunch of Silverlight and WPF, and always felt it to be probably the best UI framework i have worked with. Certainly beats all the web frameworks, and imho it was also better than Swift and Interface Builder.

I mostly like WPF (and use it a lot), but there are a few design issues that drive me nuts. The most common one is ObservableCollections--if I have a List in the model that is going to update as something happens, how do I bind that to something in the view? Does my model throw events that trigger the Viewmodel to update an ObservableCollection?

In Angular it's trivially easy to bind to an array and have it update. In WPF, it's hard enough that I architect my applications around that one single problem.

> I imagined a world of apps designed with xaml /me shudders

Mmm...XAML/WPF has one thing going for it though...you can be assured that a code-base you haven't touched for year will still work :)

Great point!

Java is pretty much all these things, except the highly subjective "looks pretty". It's kinda funny how Java was hated for not using native widgets, and now using native widgets is considered a negative.

Java WebStart has been discontinued and never worked fast. JavaFX is great but it seems it's too late for it already and Oracle seems having no enthusiasm about promoting it (did they ever have any interest in anything Sun but the patents anyway?).

"Pretty" is indeed subjective but it's not hard to understand what does it mean for the majority of non-geeks.

Despite the Oracle hate from developers that actually never placed Java applications in production, the Java community appreciates the work of Oracle and in many domains they have delivered a better work than Sun was doing in the last years.

JavaFX has been separated from core JDK, to allow for quicker development and integration into other vendors JDKs. Until now the Oracle JDK was the only one supporting JavaFX.

I hope this is going to help.

The Java plugin, like Flash, was a security nightmare and poorly integrated with the rest of the stack.

Not having a bundled set of widgets is probably an advantage, flexibility wise.

People like to bash (ha!) JavaScript, but I think it’s begginer friendliness is often overlooked. Just look at how easy it is to get something done compared to Java in the browser.

That and load time probably contributed to its success more than anything else.

> The Java plugin, like Flash, was a security nightmare

Neither is inherently less secure than javascript running in a web browser.

> and poorly integrated with the rest of the stack.

Yeah, but, so? Maybe I'm too old and curmudgeonly but I preferred it when applications acted like applications and websites acted like websites. Now I have to deal with websites that are half application, without the responsiveness of either and built on a pile of franken-code.

> Neither is inherently less secure than javascript running in a web browser

Why do you think that? I’ve heard a lot of vulnerabilities in Java and Flash plugins but JavaScript not so much.

Because they where vulnerabilities in the JS engine of all browsers and they have similar issues. See the browser release notes for the last ten years. e.g. https://chromereleases.googleblog.com/2016/03/stable-channel...

Thing is the browser engines where are not so diligent about CVE's and they are necessary evil, while Java/Flash where optional evil. With the Flash plugin being significantly worse quality than the Java ones.

java plugin was a reputable good security sandbox. Features were added and some subtile security problems were found. Oracle repeatedly failed at fixing these problems because it wanted to avoid breaking old applications. The consequences of this bad management is that the reputation of java plugins is bad and they are prohibited in many enterprises. The problem is only a management problem, there were not technical reasons. The idea of having java application in a safe sandbox is perfectly viable except oracle.

Oracle ended up breaking Applets many times anyway. As someone who worked on a very complex applet during this period, the amount of times they changed security settings was crazy. Even some of those changes that had to be made in the manifests, broke security in the previous jvm version.

perhaps that every single web page malware has been served by javascript?

You know when it is a website, when it takes multiple seconds to load a page of text, that then appears empty because some random JS script from one of the 20+ different domains was blocked from loading ;-)

That, and the way what I'm reading keeps jumping around as images load in and f' up the layout.

Truly this is the progress we all hoped to see in computing in 2018.

Who said anything about a plugin? JNLP, or jdeploy, or shipping a jar.

Sun made a big mistake shipping Java 1.0 without serialization.

Back then I was writing applets for science education that would do things like send a mesh to a finite element solver and get the mesh back with stress information.

Back then 2/3 of the code and most of the loading time came from hand-written code to serialize and deserialize data structures. Eg. an applet could have been small and fast loading if serialization was built into the platform.

Java 1.1 added serialization, but it took a long time to get into browsers, Netscape added their own lame serialization scheme, etc... By then the rot was already setting in.

Although small applets can make sense some times I can hardly see a reason (but a habit) why would anybody want an application to run inside a browser window.

> it’s begginer friendliness

Isn't JavaScript code written by beginners almost as bug-prone as C/C++ code is? I wouldn't rely on code written by a beginner unless it is written in a strongly-typed mostly immutable functional language.

I would also disagree that is beginner friendly to write a webapp in javascript.

Unless the op, just meant getting "hello world" on the screen from an HTML file, but that is a meaningless metric imo.

Writing a web app in JS is hard, getting the workflow all sorted, and then writing bugfree code. IS more a herculean task than "beginner friendly"

I meant a step above from hello world. Doing something simple is simple.

The node, webpack, react stuff is very complicated indeed

The problem came with E.E I think.. You have to edit like 10 XML files before even getting to the source code files. Granted with today's JS tooling we approaching that again :(

Without the static typing and IDE completion support thanks to XML Schema.

I will take XML over JSON every time I am the one setting the rules.

Most editors I use (e.g. Visual Studio Code) provide validation and completion of JSON using JSON Schema - which works pretty well.

I much prefer JSON to XML for most scenarios.

How do you validate comment locations?

Well, as JSON doesn't have comments that's not really a problem :-)

NB Not having comments is perhaps the biggest problem I have with JSON when it is used for things like configuration files that will be hand crafted. 99% of the JSON I work with is generated and consumed programmatically so comments aren't really an issue.

My favourite way to go about comments is to have them inline, as first class data members. (Not that I think either JSON or XML are good ideas. Hierarchical structures are really hard to handle).

Isn't it very easy to add comments support to JSON? Why not just agree to allow /* ... */ anywhere inside it and add this feature to JSON parsers? Honestly I didn't even knew this is not supported to the moment. If nobody bothered so far, doesn't this mean only a tiny portion of people needs this?

Good summary ! I agree and would add the SPA(craze) also bought us the JS-Frameworks(pick anyone you like with more than 100 stars). I don't like JS-Frameworks... I just LOVE them more than JQUERY Projects ! :/

There are cases where a SPA might be a good idea, I think those cases can be counted on one hand. I don’t mean the products, but use cases.

I could imagine it would be more complex to build Slack using traditional server-side rendered HTML than building it as an SPA.

Nowadays though you see blogs, CRM systems, etc being built as SPAs, which just makes it more complex to work on them.

SPA blogs? So the individual posts don't have their own URLs?

One example is the Ludum Dare site (ldjam.com). They migrated from Wordpress to a custom blog which I would call a SPA. It loads posts from JSON and won't render anything without Javascript.

A good SPA uses `pushState` and URL routing to have individual URLs for views.

Feeling enthusiastic about SPAs in general can't stop me from saying this souds like a horrible, fundamentally pervert idea.

Don't ask me, I am not the inventor of such advanced technology ;). Apparently there is some benefit to server-side rendering of blog posts.

I'm pretty sure that's the only place where SPA ( or MPA ) aren't a solution in search of a problem is a site/application that needs distributed compute due to a number of requests it receives in a short amount of time.

for webapps they are great.

However most websites are not webapps and are not needed. A page that is basically just text, a webpage equivalent of a magazine page does not need to be SPA - yet usually is sigh

'Webapp' is not a narrow enough use case. 'Chat app' would be more of the depth I am talking about and even there you can easily build a basic chat application using server-side rendering and smidgins of javascript to add new messages to a <div>.

Generally I would say that SPA are overkill.

In my experience, SPAs often grow to the point where the client-server boundary ends up being right in the middle of data, not between UI and data. The client-side starts to maintain its own complex state and set of data transformations not immediately concerned with UI given anything less than the perfect API.

You can separate the data with multiple page apps. Either by having different JS for each HTML, or even rendering the HTML on a server which in itself calls the API.

I love when people try to point the finger at a technology when in reality it is 100% the people who are using and implementing the technology. It's their fault. 99% of developers I know who create terrible SPA's have a long list of terrible things they've created. It's a mixture of incompetence, laziness, and poor management.

It's possible to create systems that are effectively impossible to use safely. I suspect that javascript on the web is a pretty well designed footgun, such that it's the exception to find someone who can't hurt themselves in their confusion.

If web browsers could interpret another language, would you make the same argument against it?

yes and no, the two big issues are that a) the SPA has to work within the very poorly documented render loop, for lack of a better term, of the browser and b) Javascript has some very idiosyncratic idiosyncracies and lacks some basic language functionality that is present in most languages

Please explain what’s poorly documented in current browsers render loop.

ok, if a div is added to the page body, and then another div is removed, what does the render loop do? any pointers to documentation are appreciated :)

Quick Googling:

https://developers.google.com/web/fundamentals/performance/c...

https://developers.google.com/web/fundamentals/performance/r...

I think a big part of the problem is precisely the interpreted and web browser part of your post, so you're right, but I think at this point it's difficult to disabiguate the browser, the DOM, and JavaScript. I think JavaScript as a language also has problems that make it difficult to do large scale engineering with, thus transpilers.

Maybe WebAssembly will provide fruitful ground for new, simpler, and more rigorous languages.

I also think that much of modern web apps could be accomplished better with HATEOS apps doing pure server side. But I will allow that my beliefs there are at least partly nostalgic

Using Elm, even a little bit, has given me a perspective on what a different language can do in the browser.

If you subscribe to Gary Benhardt’s Capability/Suitability theory of programming history [1], JavaScript is the highly capable technology that can be used for any sort of architecture you can imagine, and Elm is a turn towards suitability that says, “some of those architectures are unsound or have a very low floor for quality.”

You might want to abstract over DOM APIs for different reasons, but at their semantic core they are fine.

[1] https://m.youtube.com/watch?v=NftT6HWFgq0

I think that JavaScript is a really interesting and unique language. I would rather have had Perl in the browser. JS seems more appropriate as a relatively obscure academic language. Note that I tend to view trying to enforce types or use classes in JS as being misguided and futile, which does not seem to be a mainstream view.

It is somewhat prone to that since you're on your own to cobble various frameworks and tools together. Not to say you can't build a good one, but it's harder when good advice is fragmented by tech choices.

>It's a mixture of incompetence, laziness, and poor management.

Don't forget the constant, unrelenting pressure to keep up with trends or you'll get summarily banned from ever having a developer job again. SPAs got trendy, so naturally everyone had to jump in on it when normal MVC applications work perfectly fine. There's a bit of hyperbole in my previous sentences, but please don't write off the endless articles and forum posts telling people to keep up with X technology because it does influence people.

Like seriously, we're constantly prodding devs into technologies they don't want to get comfortable with, then we're suddenly surprised at the lack of competence.

Any dev worth his salt can be productive in any language (sooner or later).

It’s when they’re hiring for technology instead of skill that I get antsy.

The rate of which you get there matters though. Because the most expensive resource is your workforce. I think modern JS is reasonably productive, and I think getting there is too.

But we recently build a Blazor.net app, and even though it’s new tech, the production time was a lot lower than it would have been, had we used our standard graphql Apollo + Vue approach.

I think something like django might be even more productive, but good luck hiring for that.

It's not that people are writing SPAs badly so much as it's often unnecessary complexity. Like the "microservice all the things straight away" trope.

Sometimes a CRUD form should just be a CRUD form.

And sometimes something that should be a simple web page should be just that - I've not got anything against SPAs as such but I do hate looking at a spinner for 30 seconds to eventually look at something that is simply a static page with no interaction.

This is the problem 90% of the time. I hate the resume driven development nature that is almost encouraged in our industry.

The last few maintenance programming jobs I have worked on seem to have been written by people who have used a framework at peak hype cycle, without actually having a good knowledge of the framework.

Job ads never say "writes elegant code with a simple yet effective design". No they want "experience with React, Vue, Rails, Docker, etc".....

And at larger companies that's the fault of a totally separate team from the UI developers.

Several times I've run into the issue of an API developer misinterpreting "microservice" as "a separate endpoint for direct access to every DB row". Then you find yourself having to make half a dozen API calls for every form, just to keep the UX of the app from becoming a granular nightmare.

Or maybe the approach of reinventing the browser in the browser, shoehorning a document viewer into an application platform, retrofitting a language not designed for large-scale app development, coupled with hybris and lack of experience is an environment that attracts bad development.

(see: "Flash is buggy and crashes all the time." - Steve Jobs, 2010)

If you ran the developer edition of Flash back then, you'd have seen that 99.9% of Flash "crashing" was a totally avoidable, unhandled exception from a third-rate developer.

I like the hybrid approach - sprinkle SPAs where page reloads should be avoided. Have many SPAs in your product. Just keep them small and assign each SPA a distinct use case or area.

Let's take a CMS as an example. The "Edit blog post/page" function can be its own SPA avoiding page reload when the post is modified. Managing the list of posts/pages can be another. A page reload in between steps is fine. Nowadays internet speed is fast and latency is pretty low. Browsers are also very efficient and vive caching. If you keep your SPAs small, the user won't see the lag going from one page to another.

Multiple SPAs also allows you to keep things modular. Different teams can own different parts.

Do not however bundle the entire CMS into a single SPA. It will most likely contain a lot of code and resources to load. That will kill performance and slow down development over time.

I get the gist, but in practice, how do you:

Share code between your SPAs, for example, utilities?

What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?

Should every SPA have its own build tools?

What if there's an update to a library, should it be allowed that one SPA runs on an older library?

They wouldn't be completely separate SPAs. They'd rather be SPA-like widgets embedded in HTML pages. Using the same Vue/Rect/etc and sharing libraries together.

I'm super excited to see WebComponents support. It'll be (and already is if you don't care about IE support) possible to implement this without any frameworks/libraries/etc :)

An SPA by definition implies one one HTML document or page load by the browser. Following requests are all AJAX or async. So yes, they would be separate SPAs using the same code.

More like widgets, since each of them wouldn't be yet another HTML document. And "multiple SPAs" sound like multiple isolated instances of React/Angular/etc. Which wouldn't be the case either.

"Web Components" is a great name IMO.

These are good questions, but I'd also be curious to hear of some more concrete examples. In the interest of continuing the discussion, OP might be referring to some hybrid approaches like Backbone/Knockout where they aren't trying to solve some of the more interesting problems (e.g. bundling, dependency management, etc.). Of course, this ignores those problems and you could argue that different SPAs could be reduced to different "controllers" or some other framework specific abstraction.

You should be sharing the front-end architecture you choose across all SPAs.

Not OP, but where I work, we have a hybrid approach for our system.

> Share code between your SPAs, for example, utilities?

We alias a common folder for our utils with webpack which allows all our code to use the same utilities. We actually have two. One for shared frontend and backend, and one for just shared frontend

> What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?

Webpack code splitting is how we split our apps. We also build into multiple bundles to keep bundle size small. That does mean that React does get bundled with each, but if you split thing appropriately, you can potentially save off a few MB with caching each bundle from page to page.

> Should every SPA have its own build tools?

With webpack, you can build all your bundles with one config / command

> What if there's an update to a library, should it be allowed that one SPA runs on an older library?

We have a root package.json for all of our react apps. This means that we don't update a library unless we can update it across the board. It takes more time to test upgrades, but it also means smaller bundles, easier package management and easier maintenance in the long run.

I like what you've described but how different is that from just including jQuery to add some dynamicism to your page? Which, BTW, is what I think JS should really be used for.

Its no different. React/Vue are modern evolution of jQuery. They allow you to organize front-end code with strict conventions and best practices. You can achieve the same result with jQuery and Backbone for example. But you'll need to discipline yourself a lot and good luck hiring developers (they all want to work on React and Vue).

> React/Vue are modern evolution of jQuery.

I disagree. They are whole frameworks taking a completely different approach than jQuery, which is basically just a helper library.

jQuery is useful as a tool for operating within an externally organized application (or otherwise mostly static DOM tree). It simplifies low-level operations like DOM element manipulation.

Frameworks like React or Vue take a top-down, more declarative approach on how the DOM is built and updated. It's in many regards more powerful and more productive, but comes at a certain cost (setup complexity, total page size, certain aspects of performance).

So, which tool is best for your project really depends on the individual use case.

jQuery plugins are extremely powerful. Look at fullcalendar.io as great example. Web 2.0 was entirely built upon that. I hate to see people dismissing jQuery and its legacy as just a library. There is a huge community built around jQuery and thousands of plugins.

It ain't new and shiny but you can build anything with it. In fact, today jQuery is used on 97% of websites* while React and Vue are around 0.2%. I imagine that will change over time.

* Top 10M Alexa ranked: https://w3techs.com/technologies/overview/javascript_library...

Yeah, the minute you start reaching back to the server for a significant update to the client data model in order to support a view transition I think the benefits of SPA are lost.

Granted I've only deployed one SPA to prod and that was an Ember application but I'm not feeling the love based on that project.

Not GP, but I think the websites would be largely similar to the end user (multiple pages with dynamic bits). However, I think there is a notable architectural difference. Modern JS frameworks are much more focused on providing reusable components with clear methods of interop and communication. I think the codebase of a "multiple small SPAs" would be easier to reason about and develop than a jQuery tangle. But in terms of functionality, its probably not much different than sites from 10 years ago (I don't think this is a bad thing).

It's a spectrum and what's being advocated is using the right tool for the right job.

Rendering the marketing pages of the site -> HTML+CSS

Need to add the tiniest bit of interactivity -> jQuery

Have a "module" of functionality that -> SPA

jQuery is the old paradigm of micro managing the DOM with ES5 code.

The new paradigm is using data binding with the latest language features.

I think SPAs fail because a lot of teams just don't know what they need to do. It looks like a web page but needs to handle complex interactions/workflows and probably maintain state as well. The people with web dev expertise are used to dealing with pages and forms, and the people with experience developing sophisticated UIs (either complex or elegant) are used to working with UI frameworks that are knowable and predictable.

He mentions this in the article. I agree that building a SPA can be a bit hard and it is not very wise to use in-experienced develpers (without mentoring/lead) to do it all.

I have started to think about frontend development as at least two different types and sometimes business people and organizations mixes the two with bad results. I see some devs coming from html+css with a little js background and then a need for devs with more experience of data structures, state management, async code, good architecture etc. Some devs has this but comies from the backend and might instead lack experience in js and js frameworks/ecosystems. I think more organizations need to look where they are, which devs they have and how they can help getting everybody getting better at advanced frontend programming.

" It looks like a web page but needs to handle complex interactions/workflows and probably maintain state as well. "

'Needs' in this case might be where the money is. Most of the time it does not need to.

'complex interactions/workflows' usually comes down to CRUD in which case 'needs' is not true.

While I appreciate the commentary, I do disagree on a few points.

Starting towards the end. The comments about JS Framwork cadence doesn't nearly apply today as much as a few years ago. I mean Backbone was released in 2010 (8 years ago) and was probably the first JS SPA "framework" to gain significant traction. There have been many since then. Angular and Ember were also in 2010. React was first released in 2013 (over 5 years ago) and Vue was 2014.

Those have been the heavy hitters imho. All of which are pretty mature at this point. There are many others, of course, but that's been true of even desktop platforms. Yeah, Angular 2 was a big shift, but React, Vue and Angular are really the main players in this space. Most others take some queues from those three. Given that, it's a poor argument, and the language is more dated than the frameworks in question at this point.

Personally, I find SPAs are great for Line of business apps that need more complexity than a typical CRUD app can offer. Also, front end development IS DEVELOPMENT. Many snobby backend developers turn up their noses and feel it doesn't deserve the same level of consideration as backend development. They don't follow the same practices, consider use or lean on application designs already established in a number of toolkits.

Personally, I currently lean on React + material-ui. For the most part it has me covered, and I can find third party controls that at least match the styling. Read the Material Design guidelines. It isn't that hard and just try to follow the rules. Think about other applications you've used and push back on all features, punting as much as you can for as long as you can.

Avoid complexity at all costs. Break stuff apart into smaller pieces, and write code that's easy to replace.

Everything said and done, I think I'm just cranky at these types of articles that just indicate to me a point of view of someone unwilling to learn new things, or try new tools. I keep an eye on so much, and have for over two decades in dealing with web-based applications. I'm surprised how much the attitudes of some haven't changed in two decades.

> Many snobby backend developers

They are still "web". Try working with C++ hard-heads. Everything from Jenkins, cloud services, application release over the web, to SPA visualising 3D point cloud is a "stupid HTML website". All they want to know is WHY IS IT TAKING SO LONG?! At least that was the case in one of my workplaces.

> WHY IS IT TAKING SO LONG?!

Kind of how I feel waiting for C++ to compile

It's the linker.

Great read! There’s a lot of truth to this, but in my 18 years of being a dev, the major reason anything fails usually comes down to poor understanding and miscommunication from the higher-ups. Customers either don’t know what they want or are too lazy to articulate it. Management is usually technology-clueless and, as the article points out, has no idea how much time, money, and effort is truly required to build a high-quality maintainable app. Add to that the sea of frameworks, libraries, “tech stacks”, standards, and trends, and you have a recipe for disaster.

Technology is also becoming increasingly layered and interdependent on brittle infrastructure. Abandoned projects can be a huge time waster as well, especially when they break. For example I’ve been working on trying to fix an abandoned web application written in an odd combination of languages and frameworks with a testing suite filled with old libraries and test scenarios that no longer make sense.. This thing is not broken, it’s shattered. It’s taken our team two entire sprints to get it somewhat working again. That’s the reality of modern software engineering.

My go to point on this subject is even if you have the perfect front end it won't save you from a slow DAL. I'm not sure why we aren't allowed to be full stack developers anymore because having a say in both the front and back end is a great way to prevent frivilous work from being done.

All we need now is a MySQL client written entirely in JavaScript.

Then it will be everyone's fault.

Nah, just use WebAssembly and put MySQL on the browser.

given today's Halloween, you just gave me a sincere spook there

There is certainly a javascript extension for Postgres. Why use a client when you can run the same code on the frontend, backend, and queries?

(Here's a \s because I can imagine somebody saying the above.)

I'm convinced SPA are the future -- they're more than about fitting all your stuff on to a "single page", the concept of a page doesn't go away in SPAs, it's just the implementations and strategies for loading and state management that are different. A better way to think about them is as "client side rendered" applications. The reason I think SPAs are the future, the premises are simple:

- Processing power of client devices will only grow, compute will cheapen but communication costs (speed of light/fiber/etc) are cheapening at a much slower rate.

- Repeatedly sending layout is wasteful, given site architectures that render the same page repeatedly

- Separation of UI and data is generally a good idea

- Sufficiently advanced SPAs offer Server Side Rendering (SSR), which makes them almost equivalent and yet more reusable than the alternatives (Java's JSP stuff, ASP.NET's ASPX mess, Ruby's ERB + layouts + partials stuff, Django's Jinja + layouts + partials stuff)

Mark my words, when wasm is widely accepted and lots of languages start compiling to it, people are going to start porting the SSR alternatives (JSP, ASPX, etc) to run on the frontend to achieve this same exact goal. I can't wait to see someone post on HN about "JSP in the browser".

There are of course a few things to keep track of, If sophistication in quantum communications grows faster than everyone expects, the landscape changes drastically. As a complete layman it seems possible to me to imagine arrays of entangled atoms being used at ISPs (possibly forced to be closer together) to reduce RTT to effectively near zero which fallback to regular over-the-wire communication for error correction or whatever else.

Almost 100% of the problems I've seen expressed with SPAs is from tooling or developers doing it wrong. Maybe that's it's biggest weakness, along with being an approach prone to accidental complexity.

For the most part all you need to ask yourself is this:

Must full page reloads be eliminated?

(That's the real defining characteristics of SPAs)

For 95% of businesses a PWA with occasional full page reloads will be fine.

But for 5% of (mostly large) businesses, a kick ass SPA will be necessary.

That's a great technique that I prefer - full page reload for links that have large screen changes i.e. page navigation - spa for page-specific interactivity i.e. filters, edits, updates

Not having a client-side router strips out so much spa complexity.

maybe for apps where you really need persistent state i will use a router/full-spa, but a lot of apps don't need full persistent state across all page navigations.

In a way you are just moving the complexity back to the server code. I am not sure that helps in any way.

The server will now have to have state or reload state on every request and that state could include many things that are not obvious like

- what page are you on - which links should be shown in the menu - are there other things on the page that needs to be shown that has little to do with the current request-path

A lot of that complexity belongs on the back end.

Every front end page is likely to have a separate number of REST endpoints, so the code is effectively duplicated.

In my experience keeping as much of the code on the back end eliminates a lot of complexity, though I am far more competent with backend technologies, but I have yet to see a SPA app that reduced complexity.

Summary: inexperienced developers create bad software. Who knew.

Our SPAs are thouroughly tested (TDD, near 100% coverage). We make them mobile-first offline-first so they can be embedded in a phone app as well.

For CRUD, things that need to be searchable and things that need to work withoutJS, we usually have a rails/node app that renders views the classic way: server-side.

For static websites, we try to use static page generators like jekyll

> inexperienced developers create bad software.

A vast number of websites suffer from these problems. Therefore - your definition of "inexperienced" must apply to ~70% of web developers.

Maybe when the problem is this extensive it's time to stop blaming individuals and look for systemic problems.

In my opinion a large percentage of web developers really are unskilled. I blame the prevalence of those three week development bootcamps, you have a lot more of those for web development than backend/application stuff

If he is advanced, a normal distribution will look about like this to him.

So do relatively experienced developers chasing trends.

Again? Single page apps refresh and respond faster than their HTML counterparts. Sounds like a mad backend dev posting hate for the evolving front-end world because they don't want to learn new stuff.

Nope, he is a "Front-end web consultant and coach": https://tinnedfruit.com/

I'm building something that's very single-page app for the first time. A project to use flask, sqlalchemy, and ajax and really just do some fun flashy things, not necessarily practical things, but I do feel like the SPA space is much better than last I'd looked. I definitely see how it's easy to create something bad in a SPA doing it all yourself. My code right looks like that horse, with 500 lines of jquery full of repeating functionality still in snippet form. But really, the horses face is just as ugly as his ass.

Last year, I wrote a small single-page app engine that takes a JSON representation of HTML, and writes it to the DOM to build the page in the browser. The entire app is described in one JSON document, so it's quick to download and needs no network to change pages. I'm slowly starting to develop it again. The demo site is still up (with a SPA builder) at https://sparational.com and you're welcome to suggest any improvements.

Its working beautifully.

Either masterful satire or, ahem, you may want to check your server.

Breaks without www: https://www.sparational.com/

Seems to break on browsers older than last week too.

What problem is this solving?

The site doesn't load for me, but a very similar project is Jasonette: https://jasonette.com/

"Native app over JSON markup"

You need to update your cname record so that www forwards.

What about using an iframe and refreshing it with links targeting it ? Use <link rel="preload" ...> to make it really fast. Do so for any subcomponent of your page that can be updated independently of the rest of the page. Use browser caching for code assets/dependencies.

Pros: cheap & fast (?)

Cons: obviously the logical structure of your app must (somehow) follow the structure of nested iframes in the page.

I think iframes are inferior to the JS approach for a few reasons, one is usability for people with screen readers / etc - others would be standards compliance, bookmarking, managing state when pieces do need to talk to each other, etc.

IFrames create security obstacles, additional requests, take up memory, share CPU threads, and are usually the wrong size.

The problem is that there is a lot of immaturity within the JS world at the moment. And that makes the complexity go "BOOM".

Thing about it. Should things really get more complex just because we are moving more of the computation to the client rather than having it sit at the server? Done right it remains the same.

State management is hard. It goes boom because lots of things are going on, not because browsers are naughty.

My ability to rationalize and manage SPAs dramatically improved once immutable data and functional programming techniques were introduced.

But that can probably be said for any programming environment.

Learning ClojureScript w/ Reagent and re-frame made me feel for the first time like my sanity is not under constant attack when doing web work.

Still, building SPAs where a reloading site would suffice feels bad, and upgrading to CLJS is like adding a filter to a cigarette. Still not good for you or your surroundings.

Going from little jQuery scripts to full JS applications is difficult. People with desktop UI experience know this, but many JS devs don't.

Another problem is that we still haven't figured out the best way to write JS SPA applications. Even the React team is improvising as they go along. If you need any more proof just look at the new hooks api.

This describes the monstrosity I am maintaining just now incredibly accurately.

This remembers me the timeless "Do Things that Don't Scale" by @pg.

http://paulgraham.com/ds.html

I don't see the connection to the article, what do you relate to it?

Why create a framework when you just want to display html?

>Single-page web applications damage businesses.

plus some good points

p.s. I thought vue came before react, but it's the other way around. Interesting

Vue arguably began while it’s creator was working on Meteor, a monolithic full-stack platform for making reactive SPA’s with thick clients sending data over the wire. This was around the time where app front-ends we’re trending more towards data-reactivity as opposed to server-rendered AJAX-style. Vue’s creator Evan was part of the Meteor core team, which came before React. Evan left meteor to work on Vue, which was inspired by many front-end frameworks, such as Angular, Polymer, Handlebars, and React. React and Vue are contemporaries.

We're experimenting with Jekyll + Vue and it's working great so far.

TL;DR: try not to suck.

Seriously, if you're committing mistakes 1, 3, and 4, then your multi-page website is going to be awful, too. "SPA or not SPA" is far down the list of questions you need to be asking yourself.

This misses the main reason for SPAs which is separation of concerns. Keep your biz logic out of your UI. Test your tiers independently. Refactor your tiers as required and if you did it right you can rewrite you api without messing with your UI and the same the other way.

Want to change your backend from C# to go? Easy. Want to change from angular to vue? Easy.

But programming is hard, and doing things for the long game is harder, and finding people with the skill and experience to pull it off is harder still.

Or... you could put all your biz logic in stored procedures and wrap it all with a nice .net Razer frontend, throw in a bunch of third party controls and call it a day.

“Separation of concerns” is only possible if leadership deems it’s necessary. Often times devs are told to just put tbe business logic in tbe front-end because it’s easier and scrum masters get a pat on the back for completing more points. Technical debt be damned.

"Leadership" should not have any say in what is necessary for a domain they don't understand. If someone wants to sacrifice the quality of their trade then that's their own business. If I tell a plumber I'm OK with cutting corners and he listens, I don't want that person to be my plumber. Devs should take their job as seriously.

The SPA app I am working on is horribly coupled to the back end. In fact I don't think it would be easy to write a front end SPA or otherwise that doesn't know a fair bit about the back end and what it will be sending.

Reply on news.ycombinator.com