Re:Making websites with vanilla JavaScript in 2019?
by laurentl on Wednesday March 27, 2019 @06:28PM
(#19506816)
(CTO, not front-end dev so will answer more on philosophy and strategy than nuts & bolts)
We recently upgraded our B2C website, which is a SPA/vue affair. After going through the development and upgrade of the site, and seeing first-hand what the code looks like after having to do some debugging in it, I will clearly keep the SPA/js hammer in the tool drawer unless I have a very specific nail to hit.
Our next project, which is a back-office/CRUD app, will be Django or flask with a sprinkling of vanilla js (maybe some jquery to make things easier) and plain, honest html. I expect the experience to be quite less eventful than building a SPA.
To answer the rest of the questions, some reasons for this: dev time per page seems higher with SPA (of course the fact that I talk about pages is a hint that SPA may not be the right fit); harder to reason about when what bit of page is displayed how; and cold sweats every time I look at the length of package.json (it may very well be that we don’t do things The Right Way, but The Right Way is easier with classical frameworks)
We recently upgraded our B2C website, which is a SPA/vue affair. After going through the development and upgrade of the site, and seeing first-hand what the code looks like after having to do some debugging in it, I will clearly keep the SPA/js hammer in the tool drawer unless I have a very specific nail to hit.
Our next project, which is a back-office/CRUD app, will be Django or flask with a sprinkling of vanilla js (maybe some jquery to make things easier) and plain, honest html. I expect the experience to be quite less eventful than building a SPA.
To answer the rest of the questions, some reasons for this: dev time per page seems higher with SPA (of course the fact that I talk about pages is a hint that SPA may not be the right fit); harder to reason about when what bit of page is displayed how; and cold sweats every time I look at the length of package.json (it may very well be that we don’t do things The Right Way, but The Right Way is easier with classical frameworks)