A Front End Does Not Have to Be Rich

https://www.apress.com/us/blog/all-blog-posts/your-front-end-does-not-have-to-be-rich/16537718

by cnorthwood • 7 years ago

115 81 7 years ago

ergothus2• 7 years ago

I feel odd dissing this article, because there's nothing wrong with it: Saying that you should consider your audience, focus on your content, and use "rich" (oh man, I remember when RIA was the buzz-de-jour) websites when, and only when, appropriate, is not controversial.

That said, I don't feel like there's much actually said. Just restating what is commonly advised (if not practiced) best practices, and not really doing anything to address WHY it isn't practiced. It also failed to mention the differences when you have an application that DOES benefit from being "rich", how progressive enhancement is still a good theory (I'll be honest, none of my workplaces have DONE it).

I've seen plenty of dismissive "web coders are trash" and "lol, Js, learn to code" comments (paraphrasing) in various discussions, as well as more informed discussions as to what is and is not a real cost/benefit of various approaches, but I've not seen much in-depth discussion about why the best practices really are rare, and how to fix that. I wish the author had gone beyond the basics and addressed that.

_hardwaregeek2• 7 years ago

Yep. There's a proliferation of reductive posts that essentially repeat the same truisms we've all heard: You don't need a SPA; NPM is a ghetto; Front end web development has too much churn.

Who cares? If you don't like the state of web dev, leave or learn to make it better. If someone were to write yet another NPM sucks article, BUT include in it a description of a PR they opened to improve the process, I'd happily upvote them. But instead people seem to be satisfied with complaining with little action.

cnorthwood• 7 years ago

I'm not sure how you drew the last 2 conclusions from this article. The point is to make sure people think twice before they default to an SPA to make sure it's the right decision - in my experience a lot of people are jumping to the SPA pattern without considering the alternatives. Do you not think an article like this, which aims to increase awareness of non-SPA architectures, is helping to make it better? What else would you like to have seen this article cover?

duncan-donuts3• 7 years ago

I agree with what is being said, but I don't really see any new thoughts here. This is such a tired conversation. I used to have opinions about this, but I've grown to have a position of, "ship over anything else". Do whatever you can to ship faster. If that is nextjs, great. If that just a bunch of PHP files on an apache server? great. None of it is one-sized fits-all. /shrug

collyw5• 7 years ago

In my experience going SPA seems to double the amount of code needed (at least).

williamdclt3• 7 years ago

Maybe (I would instinctively agree). But amount of code is not a good metric for almost anything.

What about amount of features? Time to ship? Time between releases? Number of bugs? User satisfaction? Development costs? ROI? Ease of hiring? Scalability? Reliability?

Not particularly saying an SPA is better at the criteria above (not saying it isn't either), but these criteria are way more important than "amount of code"

stackola• 7 years ago

Only if you count the node_modules

duncan-donuts3• 7 years ago

I haven't had that experience. I will agree -- going with a SPA has pretty much always made things more complicated than they needed to be. I've always liked SPAs, but won't use them if I'm building a site that doesn't have complex interactions. Idk, there's a pro/con for any tech in your stack. It depends on what you actually want to be stuck supporting.

sbhn• 7 years ago

Yay, the world is waking up, google search is not spa, Ebay is not spa, Wkipedia is not spa, Youtube is not spa, Stack exchange is not spa, Duck Duck Go is not spa, HomeIdea3D.com is spa though

sbov• 7 years ago

When it comes to speed of delivering, the most important thing is usually what you have experience in. If most of your experience is in SPAs then go for it.

dunk010• 7 years ago

Hear, hear!

baldeagle2• 7 years ago

I've been wondering over the last couple years what the state of the art is on server side rendering. There seems to be a lot of energy on the FE side with react and angular, but other than dockerization, I don't hear about the same class of big FAANG shiny backend rendering tools. Even the article is just pointing out that server side exists. I'm working on setting up a small website for my wife's business and am still thinking of running Flask/gUnicorn just like I did years ago. Maybe there is something with Elixer / Erlang, but that seems niche. What should I be looking at, if I want to skill up to the new shiny in server side rendering.

timw4mail6• 7 years ago

Server-side rendering doesn't really have "new shiny". It works, just as it has, and that is a feature, not a bug.

baldeagle2• 7 years ago

This is why the next generation of dev's is going to be FE heavy, I think. Because the big marketing of mindshare and talks is going to all the developments on FE, vs server side where it is steady and reliable.

dagoat• 7 years ago

I think it makes sense to just stick with what you know, unless you have good reasons not to. But since you asked (and mentioned Elixir), Phoenix live view or https://github.com/grych/drab.

williamdclt3• 7 years ago

For React, AFAIK Next.js is the main guy for SSR

underwater• 7 years ago

Next seems to do a lot right. But there are some big gaps that they need to fill to be the canonical SSR framework.

For example getInitialProps being isomorphic means there is no good way to define controller-like behaviour (redirects, error codes, data fetching). Their examples literally tell you to have the function check whether you're executing on the server or client and have the implement the desire to behaviour for both environments.

Their new APIs seems to be pushing people towards building functions for data loading that are deployed as standalone lambdas. This is not nearly as elegant as the solution they have for pages (any thing stored as "pages/:name.js" is renderable).

Eire_Banshee3• 7 years ago

SSR React = Next.js

SSR Vue = Nuxt.js

Django is all SSR and is solid, if a little dated.

paperpunk• 7 years ago

Equally it's acceptable to go down the single-page-application route and just make sure you prioritise performance. A lot of SPAs/"rich" web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.

Perhaps just because I've dedicated a lot of time to it but I think something like React makes it a lot easier for me to find where my performance bottlenecks are and eliminate them vs. mixed server-side dynamic HTML / progressive enhancement.

Benjammer• 7 years ago

web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.

Do you think code quality is affected at all by framework choices?

Remember, we're not talking here about absolutes in terms of possible performance, it's about performance per dollar for the business. If it is substantially harder to learn and/or write "good" code using one framework over another, I'm not sure it matters how much you "prioritize performance."

timw4mail6• 7 years ago

There are inherent performance disadvantages, including time-to-first-paint. Facebook using React makes a lot more sense than your average business website, because Facebook has a lot of dynamic content, with a complex interface.

There are definitely ways to improve performance, but only Google and Facebook seem to pull off real performance with these kinds of tools.

smacktoward• 7 years ago

A lot of SPAs/"rich" web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.

I feel there is a wrinkle here, though. SPAs aren't inherently slow, but they are built around models that will ineluctably tend towards slowness unless the developer works hard to avoid that.

SPA frameworks are all about breaking your site down into small, self-contained interface elements that can then easily be composed into a larger whole. When each interface element is acting independently, though, you end up with lots of network requests getting fired as each one builds up its state independently of the others. Network requests are slowwwwww, and it only takes one of them stalling out to make the whole page feel sluggish or broken.

There are ways to architect around this problem, but they require understanding that it actually is a problem, and they take away some of the "shared nothing" developer independence that made the SPA approach so appealing in the first place. So it's not surprising that so many SPAs either don't take advantage of them or do so incompletely.

barbecue_sauce• 7 years ago

To build on this, I think it may be an issue with the REST model specifically as opposed to SPAs themselves (which you may have been alluding to). It inherently encourages several small network requests. I'm not a huge GraphQL fanboy and I haven't worked with it closely, but it's a lot more conducive to batching data fetches into only a few requests. You can get around this by violating some REST assumptions like making heavy endpoints that return all of the data you know you'll need at the initial loading of an application, but then you open yourself up to criticism from pedants.

timw4mail6• 7 years ago

SPAs should just die out. As a user the experience virtually always means slow loading, large downloads, and more fragility.

Seeing a loading spinner makes me cringe.

collyw5• 7 years ago

There are some places where it makes sense, but they are overused.

timw4mail6• 7 years ago

Some, but most "web applications" are just overly complex websites.

willio58• 7 years ago

I’m implementing an SPA right now and I really don’t see why they get so much hate. Vue is what I’ve been using and with the right implementation is capable of being very fast, very secure, and easy to debug if you choose to go down the typescript path. The only real problem I see occurring down the line are issues with SEO, but better support from search engines and workarounds to pretender pages seems to make the positives of SPA outweigh the negatives

mmartinson• 7 years ago

Personally, I'd love if google maps stuck around. It'd be a bit of a bother if it was server rendered.

timw4mail6• 7 years ago

A great example of the exception that proves the rule.

maxxxxx2• 7 years ago

Google Maps is more like a desktop with local state so an SPA makes sense. Gmail is probably fine too.

davnicwil• 7 years ago

It's funny, I have the opposite association.

Usually with any website which involves booking tickets, if I see it's a SPA I think there's a good chance that the company spent some effort on this and therefore care and it's likely to work OK.

If it's a server-rendered forms type application, I almost expect it to be poorly implemented, be frustrating to use or fail completely.

My suspicion is that, because these server-rendered forms type frameworks are very mature and much easier and faster to build something with, they are the go to option when budget is low, i.e. when quality is not a priority, and I think that may explain the correlation I've seen. Nothing to do with the underlying technology of course.

jabart• 7 years ago

Personal experience, I've seen SPAs created with a one developer project, I've seen server-rendered forms created with a 30 person team. Both satisfied the needs of the business which was "to take data from text boxes and save them to the database".

didgeoridoo• 7 years ago

My experience matches yours for large organizations; fairly or not, if I’m booking a plane ticket through the airline, an SPA page makes me feel confident that there was some real work put into it, while a basic server-side forms + JS approach makes me worry it’s a semi-abandoned afterthought.

That’s reversed for websites & apps for small companies and startups. In those cases, SPAs tend to feel fragile, buggy, and full of weird defaults and unusual behavior, especially compared to the relative simplicity of a basic form with some JS sprinkles.

No idea why that is, or if the perception is even accurate.

greenhatman• 7 years ago

That just means the site is slow. That has nothing to do with SPA.

dugluak2• 7 years ago

business logic being implemented in the client

I disagree, typically business logic is implemented in the API not in the client.

duncan-donuts3• 7 years ago

Yeah, business logic in the client is not a great idea. What happens when you add a new client (mobile app?), and you get to relive all of the same bugs you fixed? Just don't do it.

dugluak2• 7 years ago

exactly, that's one of the advantages or the modern way of web development - decoupling business logic and UI (HTML)

btbuildem• 7 years ago

Another argument for keeping business logic server-side is, well, that your proprietary and presumably valuable code remains on the server instead of being widely disseminated.

Eire_Banshee3• 7 years ago

This is my biggest issues with SPAs. Its not that it is that hard, its just so much easier to keep it secure if its being done server-side.

tyre• 7 years ago

What's an example of something that would be proprietary, reasonably on the front-end, and stealable from minified source?

In my mind, anything complex would probably be server side anyway for performance reasons (though I admit there are many, many SPAs with seemingly little thought about performance.)

ppeetteerr• 7 years ago

Wouldn't the actual business logic remain behind an authenticated API endpoint? Even your relational data models would probably be turned into something more like a tree.

Only if you're going full REST will there be a risk of client-side business logic.

onion2k• 7 years ago

Equally, you can't build a server-side app that works offline. There's arguments for and against regardless of what you choose.

dvdkon2• 7 years ago

And the opposite to that argument is that making an SPA gets you an API "for free". If you want users to be able to write their own code that interacts with your platform, it might be beneficial not to write multiple server-side interfaces and to "eat your own dogfood".

myth20183• 7 years ago

Agree 100% with the need to consider the project in question. I don't know the context of you guys, but at least in mine, I don't see such kind of planning very often.

I'm currently involved with two projects. One is a youtube-like app and the other one, a business management application. In the former I'm using SPA and rich front-ends as if there is no tomorrow; in the last I'm coding as if it were 2000's, with form submits, page reloads and client javascript only to the minimum level needed to ensure a reasonable responsiveness.

However most projects I'm aware of are using Angular or even React + Material Components to build business apps with lots of data tables and input forms. In my opinion this is a serious drawback, since it increases the project complexity and adds basically zero value to end users, who get a good-looking application which, at best, does the same thing but it's more expensive to write and maintain.

P.S. those are my impressions about my local market (Brazil), your mileage may wildly vary.

jotato• 7 years ago

However most projects I'm aware of are using Angular or even React + Material Components to build business apps with lots of data tables and input forms. In my opinion this is a serious drawback, since it increases the project complexity and adds basically zero value to end users, who get a good-looking application which, at best, does the same thing but it's more expensive to write and maintain.

So what (if any) framework do you use for the business-like apps that don't need a rich frontend? I agree that using something like Angular can be bloated, but it does offer some nice "shortcuts" for even the blandest of UIs. Specifically model binding.

myth20183• 7 years ago

It depends.

I have routines using vanilla javascript, believe it or not.

Model binding is a requirement only if you are going to deal with your model in javascript. Maybe to perform an ajax call or something alike. But I often simply do a form submit like in the old days.

In more complex routines I may use Angular.js (not Angular). But not as a single page application, bundling code, minifying it etc. I often get away with an angular.js application locally to the page which is going to use that script.

I won't lie, the codebase is ugly, inconsistent and unpredictable as hell and new developers, when arrive to the team, get immediately convinced that the architecture was planned by some amateur who don't know what he is doing.

They are probably right, but get familiar with the project really quickly and understand that there is order under that apparent surface of chaos.

I'm pretty sure this leads to more code having to be written, but it's code easier on the brain, easier to split in tasks to different developers and so on. We are not typists after all, experience shows that it's best to spend more fingers and less brains.

This is the best I could do so far to make a fairly inexperienced team deliver at a reasonable pace while dealing with users changing their minds at relativistic speeds.

timw4mail6• 7 years ago

My experience with React has been that it adds boilerplate to forms that makes them more of a pain on the front end.

myth20183• 7 years ago

Indeed. I found it really great to build some more or less complex UI components, but I didn't have a good experience using it to build forms.

thieving_magpie• 7 years ago

I'm a really late comer to web development. I got introduced to it through angular and react SPA. At this point I don't know how to do anything except these types of projects and not a lot of time to dedicate to learning a new (or old, depending on your view) way of doing things.

I need some type of remedial web dev training.

halfjoking• 7 years ago

Just type "jquery" in front of every programming-related web search you do.

If you want something old-school but even more advanced... type "jquery plugin."

I know what you're thinking... I should write an ebook. But I'm too deep in mountains of jquery slop at work, I barely have time to write this comment.

cuddlecake• 7 years ago

No, we don't think you should write Yet Another E-Book. :(

writepub• 7 years ago

I think there's a conflation of client-side-SPA === rich/complex here. For all practical purposes, this may be true as SPAs have gotten reliant on complex frameworks like React, Vue, ..

In 2019, with ES6, I believe frameworks to be an overkill. When React was introduced, it did goad people into thinking in components, etc. However, classes and higher-order-functions in ES6 allow one to think modularly without a framework. And the Virtual-DOM's value proposition is questionable when DOM updates are properly batched ( like when using https://github.com/wilsonpage/fastdom ).

Complexity is bound to increase with features, either in the back-end or front. But SPAs (with PWAs) offer advantages of being fully functional when offline, or with spotty connectivity, which is a significant value proposition. Not to mention lower server-side costs (in use-cases where server costs are prohibitive, SPA-PWAs is the only economically viable option).

My takeaway is to evaluate not just the reliance on SPA/PWAs but also on complex frameworks with diminishing returns.

dvdkon2• 7 years ago

I actually tried to implement a SPA using just ES6 (in Typescript) some years back and ran into quite a few problems with data flow, which frameworks like Vue.js readily solve.

I think that (for example) Vue by itself is quite light (mu Vue apps were never slow, even on a computer that choked on most other webpages). The problem is that many web developers don't care about performance and will hapilly fire tens of HTTP requests while loading the page, which happens to be over 1M because of all the unnecrssary JS and CSS libraries (looking at you, Bootstrap!).

igl• 7 years ago

Going back to the early 2000s with freemarker/twig/mustache is what he means I guess? Nextjs and Gatsby are what they are for very good reasons and backend apis can be written in whatever you please these days... Why would you consider using those dinosaurs again? When that is all you and your team is comfortable with?

amelius• 7 years ago

Product designers and managers might disagree.

je422• 7 years ago

agreed:

everything that you must do client-side because of latency, offline and/or device capabilities: do it client side.

everything else should go to the server.

ehnto• 7 years ago

Considering we have had an entirely new paradigm shift in front end development, I have yet to see anything that has blown my mind for usability or UI. Usually it's the same site and design except now it jiggles about as stuff loads asynchronously or repaints. I see way more degradations than I do improvements. I would love to see the creme of the crop, if anyone has any good applications using new tooling they think are a good example?

A Front End Does Not Have to Be Rich

Related Stories