12 ms·

Create your own dysfunctional single-page app

208 points by semanticist 8y ago

fouc 8y ago
>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
- mygo 8y ago
  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.
nobody271 8y ago
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.
- DaiPlusPlus 8y ago
  All we need now is a MySQL client written entirely in JavaScript.
  - nobody271 8y ago
    Then it will be everyone's fault.
  - pjmlp 8y ago
    Nah, just use WebAssembly and put MySQL on the browser.
  - marcodave 8y ago
    given today's Halloween, you just gave me a sincere spook there
  - marcosdumay 8y ago
    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.)
tracker1 8y ago
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.
- expertentipp 8y ago
  > 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.
iamleppert 8y ago
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.
- jaggederest 8y ago
  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.
  - stephengillie 8y ago
    If web browsers could interpret another language, would you make the same argument against it?
    - itronitron 8y ago
      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
      - tambourine_man 8y ago
        Please explain what’s poorly documented in current browsers render loop.
        itronitron 8y ago
        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 :)
emersonrsantos 8y ago
This remembers me the timeless "Do Things that Don't Scale" by @pg. http://paulgraham.com/ds.html http://paulgraham.com/ds.html
- Scarbutt 8y ago
  I don't see the connection to the article, what do you relate to it?
  - emersonrsantos 8y ago
    Why create a framework when you just want to display html?
tim44 8y ago
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.
stephengillie 8y ago
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 https://sparational.com and you're welcome to suggest any improvements.
- Scarbutt 8y ago
  Its working beautifully.
- nkozyra 8y ago
  Either masterful satire or, ahem, you may want to check your server.
  - invalidusernam3 8y ago
    Breaks without www: https://www.sparational.com/ https://www.sparational.com/
    - marcosdumay 8y ago
      Seems to break on browsers older than last week too.
- duncan-donuts 8y ago
  What problem is this solving?
- dguo 8y ago
  The site doesn't load for me, but a very similar project is Jasonette: https://jasonette.com/ https://jasonette.com/ "Native app over JSON markup"
- bigtunacan 8y ago
  You need to update your cname record so that www forwards.
qwerty456127 8y ago
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.
- ct520 8y ago
  I imagined a world of apps designed with xaml /me shudders
  - qwerty456127 8y ago
    Why? Doesn't it suit designing apps better than HTML or anything?
    - ct520 8y ago
      you tell me. Real world examples lead me to believe otherwise..
  - pjmlp 8y ago
    After doing that for the last four years, the prospect of focusing again in Web is what makes me shudder.
  - colde 8y ago
    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.
itronitron 8y ago
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.
- jbergens 8y ago
  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.
- mosselman 8y ago
  " 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.
diddid 8y ago
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.
- temporallobe 8y ago
  “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.
  - diddid 8y ago
    "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.
- collyw 8y ago
  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.
temporallobe 8y ago
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.
hardwaresofton 8y ago
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.
tylerjwilk00 8y ago
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.
- platz 8y ago
  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.
  - jbergens 8y ago
    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
    - collyw 8y ago
      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.
- deleted 8y ago
  [deleted]
- LiterallyDoge 8y ago
matchagaucho 8y ago
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.
- TeMPOraL 8y ago
  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.
deleted 8y ago
[deleted]
tobyhinloopen 8y ago
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
- andybak 8y ago
  > 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.
  - tomatotomato37 8y ago
    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
  - LiterallyDoge 8y ago
    If he is advanced, a normal distribution will look about like this to him.
- collyw 8y ago
  So do relatively experienced developers chasing trends.
collyw 8y ago
This describes the monstrosity I am maintaining just now incredibly accurately.
martin_drapeau 8y ago
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.
- WA 8y ago
  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?
  - mantas 8y ago
    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 :)
    - martin_drapeau 8y ago
      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.
      - 8y ago
Agathos 8y ago
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.
chvid 8y ago
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.
- LiterallyDoge 8y ago
  State management is hard. It goes boom because lots of things are going on, not because browsers are naughty.
GorgeRonde 8y ago
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.
- LiterallyDoge 8y ago
  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.
- Raphael 8y ago
  IFrames create security obstacles, additional requests, take up memory, share CPU threads, and are usually the wrong size.
LiterallyDoge 8y ago
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.
- MrPowers 8y ago
  Nope, he is a "Front-end web consultant and coach": https://tinnedfruit.com/ https://tinnedfruit.com/
pier25 8y ago
We're experimenting with Jekyll + Vue and it's working great so far.
pier25 8y ago
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.

208 points by semanticist 8y ago

fouc 8y ago

>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

mygo 8y ago
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.

nobody271 8y ago

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.

DaiPlusPlus 8y ago
All we need now is a MySQL client written entirely in JavaScript.
- nobody271 8y ago
  Then it will be everyone's fault.
- pjmlp 8y ago
  Nah, just use WebAssembly and put MySQL on the browser.
- marcodave 8y ago
  given today's Halloween, you just gave me a sincere spook there
- marcosdumay 8y ago
  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.)

tracker1 8y ago

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.

expertentipp 8y ago
> 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.

iamleppert 8y ago

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.

jaggederest 8y ago
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.
- stephengillie 8y ago
  If web browsers could interpret another language, would you make the same argument against it?
  - itronitron 8y ago
    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
    - tambourine_man 8y ago
      Please explain what’s poorly documented in current browsers render loop.
      - itronitron 8y ago
        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 :)

emersonrsantos 8y ago

This remembers me the timeless "Do Things that Don't Scale" by @pg. http://paulgraham.com/ds.html http://paulgraham.com/ds.html

Scarbutt 8y ago
I don't see the connection to the article, what do you relate to it?
- emersonrsantos 8y ago
  Why create a framework when you just want to display html?

tim44 8y ago

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.

stephengillie 8y ago

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 https://sparational.com and you're welcome to suggest any improvements.

Scarbutt 8y ago
Its working beautifully.
nkozyra 8y ago
Either masterful satire or, ahem, you may want to check your server.
- invalidusernam3 8y ago
  Breaks without www: https://www.sparational.com/ https://www.sparational.com/
  - marcosdumay 8y ago
    Seems to break on browsers older than last week too.
duncan-donuts 8y ago
What problem is this solving?
dguo 8y ago
The site doesn't load for me, but a very similar project is Jasonette: https://jasonette.com/ https://jasonette.com/ "Native app over JSON markup"
bigtunacan 8y ago
You need to update your cname record so that www forwards.

qwerty456127 8y ago

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.

ct520 8y ago
I imagined a world of apps designed with xaml /me shudders
- qwerty456127 8y ago
  Why? Doesn't it suit designing apps better than HTML or anything?
  - ct520 8y ago
    you tell me. Real world examples lead me to believe otherwise..
- pjmlp 8y ago
  After doing that for the last four years, the prospect of focusing again in Web is what makes me shudder.
- colde 8y ago
  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.

itronitron 8y ago

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.

jbergens 8y ago
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.
mosselman 8y ago
" 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.

diddid 8y ago

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.

temporallobe 8y ago
“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.
- diddid 8y ago
  "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.
collyw 8y ago
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.

temporallobe 8y ago

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.

hardwaresofton 8y ago

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.

tylerjwilk00 8y ago

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.

platz 8y ago
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.
- jbergens 8y ago
  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
  - collyw 8y ago
    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.
deleted 8y ago
[deleted]
LiterallyDoge 8y ago

matchagaucho 8y ago

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.

TeMPOraL 8y ago
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.

deleted 8y ago

[deleted]

tobyhinloopen 8y ago

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

andybak 8y ago
> 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.
- tomatotomato37 8y ago
  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
- LiterallyDoge 8y ago
  If he is advanced, a normal distribution will look about like this to him.
collyw 8y ago
So do relatively experienced developers chasing trends.

collyw 8y ago

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

martin_drapeau 8y ago

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.

WA 8y ago
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?
- mantas 8y ago
  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 :)
  - martin_drapeau 8y ago
    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.
    - 8y ago

Agathos 8y ago

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.

chvid 8y ago

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.

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

GorgeRonde 8y ago

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.

LiterallyDoge 8y ago
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.
Raphael 8y ago
IFrames create security obstacles, additional requests, take up memory, share CPU threads, and are usually the wrong size.

LiterallyDoge 8y ago

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.

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

pier25 8y ago

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

pier25 8y ago

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.