7 ms·

A Front End Does Not Have to Be Rich

115 points by cnorthwood 8y ago

ergothus 8y 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.
- _hardwaregeek 8y 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 8y 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?
    - _hardwaregeek 8y ago
      The last two points are not specific to the article but to the category of vaguely contrarian points about modern web development in which the article resides. And I’m a little skeptical of the premise, which is that we need to increase awareness of non-SPA architectures. Even though there is a lot of hype around SPA’s and fancy front end driven architectures, I’d bet that the vast majority of code written and new developers minted are primarily focused on server side web applications. It’s just nobody ever says “yknow what’s new and hot and the thing everybody should use? Java servers!”
duncan-donuts 8y 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
- collyw 8y ago
  In my experience going SPA seems to double the amount of code needed (at least).
  - williamdclt 8y 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"
    - collyw 8y ago
      If you view code as a liability then more code is worse.
      - lubonay 8y ago
        Well okay, but is it the ultimate liability? What if 2x the code gives you 10x the value?
        collyw 8y ago
        OK, I'll expand my comment to say that "more code for the same functionality is a liability".
      - 8y ago
baldeagle 8y 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.
- timw4mail 8y ago
  Server-side rendering doesn't really have "new shiny". It works, just as it has, and that is a feature, not a bug.
  - baldeagle 8y 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 8y 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 https://github.com/grych/drab.
- williamdclt 8y ago
  For React, AFAIK Next.js is the main guy for SSR
  - underwater 8y 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).
paperpunk 8y 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 8y 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."
- timw4mail 8y 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 8y 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.
timw4mail 8y 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.
- collyw 8y ago
  There are some places where it makes sense, but they are overused.
  - timw4mail 8y ago
    Some, but most "web applications" are just overly complex websites.
  - willio58 8y 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 8y ago
  Personally, I'd love if google maps stuck around. It'd be a bit of a bother if it was server rendered.
  - timw4mail 8y ago
    A great example of the exception that proves the rule.
  - maxxxxx 8y ago
    Google Maps is more like a desktop with local state so an SPA makes sense. Gmail is probably fine too.
- davnicwil 8y ago
dugluak 8y ago
> business logic being implemented in the client I disagree, typically business logic is implemented in the API not in the client.
- duncan-donuts 8y 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.
  - dugluak 8y ago
    exactly, that's one of the advantages or the modern way of web development - decoupling business logic and UI (HTML)
btbuildem 8y 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_Banshee 8y 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 8y 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.)
    - Eire_Banshee 8y ago
      Anything you would normally stash in an API gateway. API keys, anything that handles auth, etc.
    - creatornator 8y ago
      An inexperienced dev might do something like put API keys in frontend code. You can even do an advanced search of Github to find people's keys to steal to get access to paid APIs.
      - Can_Not 8y ago
        Inexperienced devs already leak keys into front end code before SPAs.
- ppeetteerr 8y 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.
myth2018 8y 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 8y 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.
  - myth2018 8y 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.
thieving_magpie 8y 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 8y 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 8y ago
    No, we don't think you should write Yet Another E-Book. :(
kimjongman 8y ago
We sell React to customer. But in reality we just code basic erb. Client just doesn't know and care about the website as long it is fast.
writepub 8y 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 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.
- dvdkon 8y 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 8y 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 8y ago
Product designers and managers might disagree.
- deleted 8y ago
  [deleted]
je42 8y 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 8y 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?

115 points by cnorthwood 8y 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.

_hardwaregeek 8y 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 8y 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?
  - _hardwaregeek 8y ago
    The last two points are not specific to the article but to the category of vaguely contrarian points about modern web development in which the article resides. And I’m a little skeptical of the premise, which is that we need to increase awareness of non-SPA architectures. Even though there is a lot of hype around SPA’s and fancy front end driven architectures, I’d bet that the vast majority of code written and new developers minted are primarily focused on server side web applications. It’s just nobody ever says “yknow what’s new and hot and the thing everybody should use? Java servers!”

duncan-donuts 8y 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

collyw 8y ago
In my experience going SPA seems to double the amount of code needed (at least).
- williamdclt 8y 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"
  - collyw 8y ago
    If you view code as a liability then more code is worse.
    - lubonay 8y ago
      Well okay, but is it the ultimate liability? What if 2x the code gives you 10x the value?
      - collyw 8y ago
        OK, I'll expand my comment to say that "more code for the same functionality is a liability".
    - 8y ago

baldeagle 8y 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.

timw4mail 8y ago
Server-side rendering doesn't really have "new shiny". It works, just as it has, and that is a feature, not a bug.
- baldeagle 8y 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 8y 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 https://github.com/grych/drab.
williamdclt 8y ago
For React, AFAIK Next.js is the main guy for SSR
- underwater 8y 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).

paperpunk 8y 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 8y 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."
timw4mail 8y 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 8y 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.

timw4mail 8y 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.

collyw 8y ago
There are some places where it makes sense, but they are overused.
- timw4mail 8y ago
  Some, but most "web applications" are just overly complex websites.
- willio58 8y 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 8y ago
Personally, I'd love if google maps stuck around. It'd be a bit of a bother if it was server rendered.
- timw4mail 8y ago
  A great example of the exception that proves the rule.
- maxxxxx 8y ago
  Google Maps is more like a desktop with local state so an SPA makes sense. Gmail is probably fine too.
davnicwil 8y ago

dugluak 8y ago

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

duncan-donuts 8y 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.
- dugluak 8y ago
  exactly, that's one of the advantages or the modern way of web development - decoupling business logic and UI (HTML)

btbuildem 8y 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_Banshee 8y 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 8y 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.)
  - Eire_Banshee 8y ago
    Anything you would normally stash in an API gateway. API keys, anything that handles auth, etc.
  - creatornator 8y ago
    An inexperienced dev might do something like put API keys in frontend code. You can even do an advanced search of Github to find people's keys to steal to get access to paid APIs.
    - Can_Not 8y ago
      Inexperienced devs already leak keys into front end code before SPAs.
ppeetteerr 8y 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.

myth2018 8y 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 8y 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.
- myth2018 8y 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.

thieving_magpie 8y 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 8y 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 8y ago
  No, we don't think you should write Yet Another E-Book. :(

kimjongman 8y ago

We sell React to customer. But in reality we just code basic erb. Client just doesn't know and care about the website as long it is fast.

writepub 8y 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 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.

dvdkon 8y 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 8y 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 8y ago

Product designers and managers might disagree.

deleted 8y ago
[deleted]

je42 8y 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 8y 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?