This seems like a great writeup with some good information in it.
But to be picky, the title needs work. It isn't as describe. In fact it contradicts itself.
The title is:
> Front-end Walkthrough: Building a Single Page Application from Scratch
Half way down the article:
> When it comes to building a SPA, you can either do things from scratch or use a library to help you out. Building from scratch is a lot of work and adds a lot of new decisions to be made, so we decided to go with a framework.
I would be very interested to see an article in 2017 that is actually from scratch. Bonus points for not using a ES6 transpiler. Like "Linux from Scratch" (the book)... useless from a practical standpoint but awesome from a learning standpoint.
Edit: as a side note, when I started making web apps, jQuery was still in beta so I didn't even use it. A lot has changed, obviously, for one SPA didn't really exist then.
> The title was editorliazed by the poster, the orginal articles title does not contain "from scratch":
I actually copied and pasted my quote from the article title not the HN title. They were the same but they changed the article title (maybe after seeing my comment?). Which is completely OK, it's a good change.
It's increasingly harder to find non-legacy single page apps that aren't using React or Angular (Vue and Ember are distantly trailing behind). Corollary: it's increasingly harder to find jobs for anything other than React or Angular.
After technology du jour becomes popular, people will use it not because it's good or even necessary, but because it will ensure their employment. And then the rationalizations sink in afterwards.
My personal problem is that people start to present themselves as "React" or "Angular" developers, which is kind of scary for me personally.
It is also hard to explain that you can pick up their framework (e.g. switch to Vue.js from React), many companies just say "no" unless you can provide strong experience. Some companies have better policies and they insist only on core knowledge and principles, but, unfortunately, I personally find them to be in a minority.
Yep. When I'm working on my resume it's a balance of trying to use the right relevant buzzwords to get past HR and enough content to get a callback from the person hiring. In my experience on the other side, HR doesn't often know that Rails implies Ruby or React implies JavaScript. Wrong buzzwords === wrong experience and not a fit for the job.
The worst part about this is that it makes people (at work or in side projects) use these and other frameworks for every project ever for the resume padding. Doesn't matter if it's a CRUD app that just needs a form - it has to be a complex web app with a GraphQL backend and 50mb of React frontend.
Resume driven development is the way to go. Fulfilling the business case with minimal effort is good for the business but really bad for the engineer. You need microservices, NodeJS, react, cloud and whatever to stay employable. Even your own company won't be grateful for delivering a simple and robust solution.
Boy do I disagree with just about everything here. You need to keep your skills up to date, this is correct. Absolutely.
I think it's a much more important skill to acknowledge that you don't need things like microservices, node, and react when you can deliver a simple, robust solution without any of that stuff.
The problem is when you look for the next job or even when the next project starts at your company you won't get credit for delivering a pragmatic solution. They often will bring in new people who have the cool stuff on their resume.
This is the difference between how it should be, and how it is. When you solve something simply and pragmatically it won't impress the non-technical or semi-technical manager. They also want to see microservices, bells and whistles.
Believe it or not for many managers "I refactored something and fixed the problem in an hour" isn't very desirable. When you go to your next interviewer they won't be impressed either, though they absolutely should be.
who is the gatekeeper in the company that is going to say "we don't need this"? Everybody has a vested interest in resume driven development, and these days "netflix/google/amazon do it, so we should too" seems to be like the good old "nobody got fired for buying IBM" (whether or not doing what a company at 100x your scale does makes sense)
Many, many code horrors exist today due to a deep and abiding fear developers have of appearing insufficiently smart.
Most of the web apps that are being built today have no need for a complex front end and, if they do, it's only in a few places. But, as you quote, programming is pop culture, so every new Form => Datastore app is going to be built using a toolchain more complicated than quake was built with.
Personal anedocte: I decided to become a developer and studied first Javascript itself, then React; exactly for the reason of employability. A month ago I started at my first dev job, at a great place.... using Ember! :) I never had touched Ember before, and nothing on React around here.
Sorry, I should have qualified it as Single Page Applications, not web apps in general. Still, hard to find a front-end job that isn't about SPA anyways.
If you're going to make a SPA, why the heck wouldn't you use one of the frameworks that has tons of tutorials, walkthroughs, supporting libraries, and a zillion asked and answered questions on SO? In other words why not use one of the top 5 frameworks of the current time? It seems efficient to do so to me.
It's expedient for many reasons to use a major framework, but it doesn't mean there are no drawbacks.
There are learning curves, inner platform effect (have to do the framework way of doing things), major breaking changes and outdated information, opinionated authors you may not agree with, huge dependencies for users to download, performance bottlenecks and gotchas arising from not using the framework properly or even the framework itself is slow. These things are basically guaranteed.
I'm building my new front around two cutting edge technologies, jquery and bootstrap. My UI should be fairly simple, why complicate development and bloat the download?
I'm not even sure it's just to ensure employment; that's a very simplistic explanation.
Languages and frameworks are how programmers communicate with each other. The same argument could be made for the English language. Developers will naturally congregate around common language because there is value in that. It's wrong to dismiss that value proposition as mere pop culture.
I'm not going to argue for or against the existence of frameworks however any frameworks that exist become part of the conversation. They're a new set of nouns, verbs, and grammar to learn. And programmers will naturally try and avoid unnecessary duplication of this common language and focus around a few frameworks.
Wouldn't that also be the case if, for example, React/Angular were demonstrably superior technologies to the alternatives? groupthink doesn't have to be the only explanation.
JavaScript is the defacto standard... despite glaring issues and confusion (== vs === for example).
PHP is a massive player... despite incoherent implementations, inconsistent name spaces, glaring holes in functionality...
Both of those are popular not because they are the "Best"... but because they are popular. They came out at the right time and got the momentum in the right spots.
Granted... some of that might be my own opinion, but those languages have MASSIVE issues and shortcomings. They aren't at the top because of "demonstrable superiority". They are at the top in spite of the issues.
> people will use it not because it's good or even necessary, but because it will ensure their employment
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
Imagine going to a doctor and getting a prescription because "they like it".
>there is a wealth of knowledge on the internet about how to fix every little problem
Let's hope they're using the same version you're using.
>because it allows them to be productive with their peers
Productivity without a framework must be impossible...
>they learn something new
They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
> They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
You are underestimating the appeal and intellectual stimulation gotten from learning something new regardless of merit.
It's not utter nonsense. I've seen it happen time and again in multiple jobs.
Right now at my current employer "we" are about to embark on replacing our entire data pipeline with a very popular queuing system designed to process hundreds of GB or more of data per day. Our current pipeline moves a few tens to hundreds of MB per day (not second, minute or hour) from the point of intake to our internal data stores. There are two reasons as I see it for the choice: resume driven development by the "architect" who proposed it (and management who want to put the management portion on their resumes) and laziness to address other issues regarding why there are delays at certain points in the pipe.
You by your own admission have no idea what the architect was thinking and the motivations behind the design. There could be plenty of reasons such as additional future data sets or design decisions that you simply aren't privy to. Or often the reason is related to non functional requirements for example the fact that most companies live and die by enterprise support.
Before criticising something as "resume driven development" it might be better to actually have a detailed conversation first.
I know enough of the current data pipeline and strategic roadmap to know that the proposed solution is overkill for the foreseeable future and doesn't actually address the underlying problems. Just because he's the architect doesn't mean everyone else is an inexperienced junior individual contributor.
yet another web framework medium article with a misleading angular vs react comparison.
it isn't angular 2 anymore. it's just angular. it's been out for over a year and if people were having problems running it in production, we would hear about it. there are many sites running angular 2-4 in production, google it and see for yourself. just because google didn't rewrite gmail in angular doesn't mean you shouldn't use it.
I wonder if there is some highly ranked google search result that spreads this misinformation, months after some of these points were valid.
Every framework is going to have flaws, but if you perform a comparison I think there's a responsibility to accurately represent the frameworks being compared.
"We knew we wanted to build a single page application (SPA) in order to have more control over the user experience of our website, making it as smooth as possible. On top of this, it also helps speed our website up since there’s no longer a need for full page reloads. We only need to load the data that we don’t have yet, and then re-render the page."
I'm bothered by this perception that SPAs inherently provide a better user experience. They certainly can provide a different user experience, but "better" is entirely up to the developers. I'd argue its actually quite hard to create a better UX in an SPA than the simple page based UX metaphor everyone is used to that the browser provides. Netflix is an example of a great UX from an SPA, nba leaguepass is an example of a disaster SPA.
Also there is no inherent speed boost from an SPA. Anything that is slow on the server will still be slow, and its up to the developer to create a good UX for latency. In page driven applications, the browser provides a fairly standard UX for page loading that most people are used to. In SPA apps, the developer needs to roll this themselves. Widgets popping in all over the place at different times, moving things all over the page, is a common UX I see in SPAs that is not good.
I wish I would hear this expressed more often. Many, many web apps lend themselves well to a very simple page-based UI. The development community can just never seem to recognize or acknowledge how many of their decisions are based on whatever the latest fad happens to be.
> "Also there is no inherent speed boost from an SPA"
There is: superior caching & resource management. Even if your non-SPA perfectly caches resources (impossible with bundling), you are still wasting time on parsing/compiling/executing cached scripts on every page reload, which can take up to a few seconds on smartphones.
Don't know why this was downvoted, it is relevant. That's the main reason why hacks like PJAX/turbolinks were invented in the first place, not having to reparse the same JS and CSS for every page change has a noticeable impact in perceived performance.
In theory yes, and if you only aim your site at flagship smart phone owners.
In my experience in Latin America with 50-150$ Android phones, very few developers/managers in the "western world" actually care about their SPAs performance and in about 9/10 cases the simple backend rendered sites provide a better experience for me.
edit: Of course there also plenty of devs that add a ton of inperformant js to their backend rendered sites, destroying the experience.
A wonderful solution for this is the Turbolinks approach which is a part of the standard Rails stack.
The new page request takes place over Ajax, the server sends the whole page, and only the body gets replaced thus avoiding the need for loading common assets and initializing js.
You can create a simple page based UX metaphor using SPA. In fact it is the most common model around. You emulate routes client side and rather than refreshing the page you just change the inner content. Every demo, framework example and web site template I've seen uses has this as a reference.
And of course this is faster than server side model since you are only loading what is changed and not the entire page again. Also SPAs allow you to selectively bring in new Javascript components/widgets.
Also there is a common pattern for conveying the page loading to the user. It's the thin coloured progress bar that appears under the tabs. And there are dozens of plugins for implementing it.
SPA applications support the ability to update parts of a web page e.g. an article content might be 5K out of a 20K file. A server side website has to bring down the 20K page again and again as the user navigates through your site. Caching or web server configuration makes no difference here.
> A server side website has to bring down the 20K page again and again as the user navigates through your site. Caching or web server configuration makes no difference here.
Browser caching, not server-side caching. The browser doesn't have to "bring down" the 20k page "again and again", it gets the assets out of its cache (html, js, css, images, etc), and then the JavaScript loads the 5k article when the DOM is ready. Hope you're not trolling. Non-SPA websites can be basically just as fast as SPA's, and in practice they are often faster since they are usually built without frameworks and have less JavaScripts.
We aren't talking about CSS, JS, Images but purely about the HTML page. If you have a 20K page and 15K of that belongs to header, footer, sidebar then in a server side rendered site that 15K has to be downloaded for every page on the site. On a SPA site it only has to be downloaded once as you can dynamically switch out the other parts.
If there was a mechanism in the HTML spec to tag parts of a page for partial caching then we wouldn't need SPA in most cases. But browsers only cache the entire HTML.
That speed improvement is assuming that people are actually browsing around your app/site. Which might or might not be true depending on what your are building.
This is one of the reason why I really dislike most news sites or blogs using SPAs. I usually get to a page via direct link and leave immediately after reading. But every time i have to stare at a spinner or coloured progress bar until the styled plain text finally is revealed to me.
You can totally reimplement a model that the browser supports natively, but you close off basically every affordance that a page-based approach provides unless you commit to reimplementing things like (among others) accessibility support for screen readers or reader views, usability with nonstandard clients, and interoperability with the client's environment (I guarantee that your custom progress bar doesn't have the same semantics as the loading spinner on my browser tab). Most of these things come effectively for free with regular pages, so I don't see what benefit doing extra work to reduce your product's flexibility has if a page-based model already suits your content in the first place.
You are talking in abstracts. What does nonstandard clients or interoperability with the client's environment specifically mean ?
And all modern day screen readers support SPA applications. They wouldn't be much use if they couldn't and is the reason you have SPA sites amongst major enterprise companies (who always comply with accessibility policies).
Svelte allows isomorphic rendering (client & server side). Svelte also has a feature called rehydrate, which will bind the component to html rendered on the server side; sortof like serializing/unserializing.
This enables me to use Svelte for both client-side & server side rendering, replacing other template systems & having the best of both worlds (page caching, dynamic behavior on the client, a scalable front-end architecture, composition, etc).
Most of the issues cited with Angular and React aren't really issues in EmberJS right now. I always find it interesting that so many people jump right into frameworks that have design philosophies against maintainability.
The problem with Ember is that finding developers is a lot harder so nobody will use it. I'm not saying it's bad, but if I would start a company now and had to do a SPA (hopefully not) it would definitely be either React or Angular just because finding developers would be easier.
I am doing SPA with vuejs and django backend, its a huge step in the right direction as far as (my) web development goes. Initially I was sceptical of webpack, now I see what an asset it is in compiling static content and many other handy features. I prefer vuejs to react or angular but I haven't really given them much time, maybe one day
This is a debate that can be done to death (which is good, that's how these frameworks improve), but as someone that's used backbone/marionette, angular, and react react/redux, I can say the day I found the Vue docs was like a reawakening. I don't mean to get poetic, but I genuinely had a sense of "holy shit, this is what docs should look like!" I only got more and more excited as I read through and learned more about it.
Vue is fucking awesome. I'm just now learning it and I can't wait to build something more serious than a todo app with it.
I have. I once worked at a shop that tried to rebuild all of its web sites as SPA's with Vue. Four devs, two with deep JS experience, and it was a complete disaster. Vue isn't ready for enterprise, and the documentation is a joke.
I don't work there anymore, but looking at the sites now, I can see the old ones are still online — TEN months later, no sign of Vue.
Why don't you like the docs? I love how it has a great introduction guide[1] that really dives deep into the hows and whys, but also has a full API guide when you just gotta know one specific thing [2].
Can you point out some good resources that you used to integrate Django with vue? I have a full stack Django website and have often thought about using some js library and speeding things up on the front end (and reduce bandwith usage) but my (admittedly lazy) experiment with react/angular haven't gone anywhere much.
Any tips on how to start with the integration? Do you use node to serve the front end or is it served by django?
I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!! Vanilla JavaScript works for both small projects and big projects. And it performs well! (at least compared to the popular frameworks) and it's very nice to debug! There is no complication step! And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so.
"And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so."
This is a confusing assertion. How does using a framework make your software unsupported in ways that not using a framework would not? i.e. if I build an application, whether I use a framework or not, and then I stop touching it, forever, why is the non-framework code more resilient to not breaking in the future?
The framework will keep evolving, but you're under no obligation to upgrade, if you don't need to keep developing. It seems silly to complain about the code you didn't have to write.
There are trade offs when using existing software to do things you want to do, sure. But, you get the core web app functionality you needed to implement, anyway, and it's been tested by a lot more developers than your code likely ever will be. In fact, I'd argue compatibility with a framework will be better than implementing it yourself, assuming you cover the same amount of functionality in each app; again, because of the heavier testing a widely used framework gets.
Being able to upgrade the frameworks and platforms you choose to use is a legitimate concern.
When did you ever build a relevant application and stop touching it, forever? Any worthwhile software I've ever built has been maintained with continuous effort. On the web especially, "don't keep developing" is just a death sentence.
I'm not suggesting stopping development, I'm saying that the code you got for free (without any dev time) is not a loss, even if you have to do a little extra work to handle upgrades down the road. It's completely nonsensical to say obsolescence is a reason to not use a framework.
There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved).
I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve?
You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box.
You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework.
Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA.
I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff.
I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.
The devil is in the details. From experience, upgrading framework code is time-consuming. It's mainly because frameworks have a layer of architecture that you app needs to adhere to. When the architecture changes, so must the app.
When you roll your own, that is a non-issue. You can switch out libraries as you wish. I have made several major refactorings on my client's app with significantly less pain than it took to upgrade my previous clients' framework-based (i.e. Rails, angular) codebases.
When you roll your own, you can wait until libraries mature, or you can choose to use snippets of the essential code (thereby avoiding bloat).
I utilize patterns that minimize structural architecture, by utilizing dependency injection, es6 modules, promises, async/await, factory methods, agents with events. I avoid classes by utilizing factory methods.
I don't see how it can be. You've got to build and maintain it yourself now, instead of relying on a huge community of volunteers. If you're OK maintaining the entirety of the view layer framework (or whatever) yourself, where's the harm in starting from a known-good state? If you don't want to upgrade but want to add new features to the framework you picked, you can fork it and do that.
Now, if you don't like a given framework, having a framework is a loss because it'll suck to work on. I've seen this a ton. But, that's not the same problem and one that can be avoided by doing an extra day or two of due diligence and building a simple app before settling on your favorite. I dunno about you, but I've built libraries that I decided I hated after I was done with them. Sometimes, I rewrote them after I figured out why I was originally wrong about what I like, and sometimes I spent more time finding an appropriate replacement that somebody else made (this is usually the better choice).
> I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!!
You just end up inventing your own framework this way. You'll come across problems, come up with some solution you think is clever, come up with conventions to follow etc. Surprise! You've just manually rediscovered all the problems frameworks were created to solved and reinvented the wheel.
I'll use vanilla JavaScript or jQuery if the UI required is really basic but anything beyond that, you're going to save time using a well thought out framework rather than thinking you're smarter than whole communities who have spent years working on these solutions. Coders don't invent frameworks for the sake of it, they exist for a reason.
Recommendation for poki, make it easier to reach your website from your blog.
When I go to blog.poki.com, if I like what I read I typically delete "blog." to checkout what "poki.com" is about -- which should be the purpose of blogging. In this case it doesn't work, and I had to manually type "www.".
Rather than relying on URL rewriting by the reader (and, thus, specific URL relationships), it would be better just to put a prominent link to the (www.)poki.com website from the blog.
Relying on manual URL rewriting to navigate to a related page is missing the entire point of the web.
85 comments
[ 3.9 ms ] story [ 156 ms ] threadBut to be picky, the title needs work. It isn't as describe. In fact it contradicts itself.
The title is:
> Front-end Walkthrough: Building a Single Page Application from Scratch
Half way down the article:
> When it comes to building a SPA, you can either do things from scratch or use a library to help you out. Building from scratch is a lot of work and adds a lot of new decisions to be made, so we decided to go with a framework.
I would be very interested to see an article in 2017 that is actually from scratch. Bonus points for not using a ES6 transpiler. Like "Linux from Scratch" (the book)... useless from a practical standpoint but awesome from a learning standpoint.
Edit: as a side note, when I started making web apps, jQuery was still in beta so I didn't even use it. A lot has changed, obviously, for one SPA didn't really exist then.
The repo is here https://github.com/Bloomca/vanilla-web-app, if you are interested.
> Front-end Walkthrough: Designing a Single Page Application Architecture
> We documented our journey towards a shiny new stack.
I actually copied and pasted my quote from the article title not the HN title. They were the same but they changed the article title (maybe after seeing my comment?). Which is completely OK, it's a good change.
It's increasingly harder to find non-legacy single page apps that aren't using React or Angular (Vue and Ember are distantly trailing behind). Corollary: it's increasingly harder to find jobs for anything other than React or Angular.
After technology du jour becomes popular, people will use it not because it's good or even necessary, but because it will ensure their employment. And then the rationalizations sink in afterwards.
It is also hard to explain that you can pick up their framework (e.g. switch to Vue.js from React), many companies just say "no" unless you can provide strong experience. Some companies have better policies and they insist only on core knowledge and principles, but, unfortunately, I personally find them to be in a minority.
I think it's a much more important skill to acknowledge that you don't need things like microservices, node, and react when you can deliver a simple, robust solution without any of that stuff.
Believe it or not for many managers "I refactored something and fixed the problem in an hour" isn't very desirable. When you go to your next interviewer they won't be impressed either, though they absolutely should be.
Most of the web apps that are being built today have no need for a complex front end and, if they do, it's only in a few places. But, as you quote, programming is pop culture, so every new Form => Datastore app is going to be built using a toolchain more complicated than quake was built with.
There are learning curves, inner platform effect (have to do the framework way of doing things), major breaking changes and outdated information, opinionated authors you may not agree with, huge dependencies for users to download, performance bottlenecks and gotchas arising from not using the framework properly or even the framework itself is slow. These things are basically guaranteed.
Languages and frameworks are how programmers communicate with each other. The same argument could be made for the English language. Developers will naturally congregate around common language because there is value in that. It's wrong to dismiss that value proposition as mere pop culture.
Wouldn't that also be the case if, for example, React/Angular were demonstrably superior technologies to the alternatives? groupthink doesn't have to be the only explanation.
PHP is a massive player... despite incoherent implementations, inconsistent name spaces, glaring holes in functionality...
Both of those are popular not because they are the "Best"... but because they are popular. They came out at the right time and got the momentum in the right spots.
Granted... some of that might be my own opinion, but those languages have MASSIVE issues and shortcomings. They aren't at the top because of "demonstrable superiority". They are at the top in spite of the issues.
The reason they got popular because they solved a need, if I am not mistaken making dynamic web pages was a pain before PHP, PHP made it easy.
The "best" language is useless if most devs find it hard to use.
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
Imagine going to a doctor and getting a prescription because "they like it".
>there is a wealth of knowledge on the internet about how to fix every little problem
Let's hope they're using the same version you're using.
>because it allows them to be productive with their peers
Productivity without a framework must be impossible...
>they learn something new
They learn something about the framework at the present time, which may be worthless after the next breaking change, and is not generally applicable to the web platform itself.
I have some very troubling news for you...
You are underestimating the appeal and intellectual stimulation gotten from learning something new regardless of merit.
Right now at my current employer "we" are about to embark on replacing our entire data pipeline with a very popular queuing system designed to process hundreds of GB or more of data per day. Our current pipeline moves a few tens to hundreds of MB per day (not second, minute or hour) from the point of intake to our internal data stores. There are two reasons as I see it for the choice: resume driven development by the "architect" who proposed it (and management who want to put the management portion on their resumes) and laziness to address other issues regarding why there are delays at certain points in the pipe.
Before criticising something as "resume driven development" it might be better to actually have a detailed conversation first.
> Why we switched from Mongo to Postgres
Wow, no shit. A database that was made 21 years ago and is still maintained is actually better - who would've guessed?
it isn't angular 2 anymore. it's just angular. it's been out for over a year and if people were having problems running it in production, we would hear about it. there are many sites running angular 2-4 in production, google it and see for yourself. just because google didn't rewrite gmail in angular doesn't mean you shouldn't use it.
I wonder if there is some highly ranked google search result that spreads this misinformation, months after some of these points were valid.
Not fan of angular or any other framework in particular but this gets the job done so far. If only they finish angular universal faster..
I'm bothered by this perception that SPAs inherently provide a better user experience. They certainly can provide a different user experience, but "better" is entirely up to the developers. I'd argue its actually quite hard to create a better UX in an SPA than the simple page based UX metaphor everyone is used to that the browser provides. Netflix is an example of a great UX from an SPA, nba leaguepass is an example of a disaster SPA.
Also there is no inherent speed boost from an SPA. Anything that is slow on the server will still be slow, and its up to the developer to create a good UX for latency. In page driven applications, the browser provides a fairly standard UX for page loading that most people are used to. In SPA apps, the developer needs to roll this themselves. Widgets popping in all over the place at different times, moving things all over the page, is a common UX I see in SPAs that is not good.
There is: superior caching & resource management. Even if your non-SPA perfectly caches resources (impossible with bundling), you are still wasting time on parsing/compiling/executing cached scripts on every page reload, which can take up to a few seconds on smartphones.
In my experience in Latin America with 50-150$ Android phones, very few developers/managers in the "western world" actually care about their SPAs performance and in about 9/10 cases the simple backend rendered sites provide a better experience for me.
edit: Of course there also plenty of devs that add a ton of inperformant js to their backend rendered sites, destroying the experience.
The new page request takes place over Ajax, the server sends the whole page, and only the body gets replaced thus avoiding the need for loading common assets and initializing js.
I'm simplifying but hopefully you get the point.
You can create a simple page based UX metaphor using SPA. In fact it is the most common model around. You emulate routes client side and rather than refreshing the page you just change the inner content. Every demo, framework example and web site template I've seen uses has this as a reference.
And of course this is faster than server side model since you are only loading what is changed and not the entire page again. Also SPAs allow you to selectively bring in new Javascript components/widgets.
Also there is a common pattern for conveying the page loading to the user. It's the thin coloured progress bar that appears under the tabs. And there are dozens of plugins for implementing it.
Not true. If you do proper caching and configure your nginx properly back-end rendering can be just as fast.
SPA applications support the ability to update parts of a web page e.g. an article content might be 5K out of a 20K file. A server side website has to bring down the 20K page again and again as the user navigates through your site. Caching or web server configuration makes no difference here.
Browser caching, not server-side caching. The browser doesn't have to "bring down" the 20k page "again and again", it gets the assets out of its cache (html, js, css, images, etc), and then the JavaScript loads the 5k article when the DOM is ready. Hope you're not trolling. Non-SPA websites can be basically just as fast as SPA's, and in practice they are often faster since they are usually built without frameworks and have less JavaScripts.
We aren't talking about CSS, JS, Images but purely about the HTML page. If you have a 20K page and 15K of that belongs to header, footer, sidebar then in a server side rendered site that 15K has to be downloaded for every page on the site. On a SPA site it only has to be downloaded once as you can dynamically switch out the other parts.
If there was a mechanism in the HTML spec to tag parts of a page for partial caching then we wouldn't need SPA in most cases. But browsers only cache the entire HTML.
This is one of the reason why I really dislike most news sites or blogs using SPAs. I usually get to a page via direct link and leave immediately after reading. But every time i have to stare at a spinner or coloured progress bar until the styled plain text finally is revealed to me.
And all modern day screen readers support SPA applications. They wouldn't be much use if they couldn't and is the reason you have SPA sites amongst major enterprise companies (who always comply with accessibility policies).
This enables me to use Svelte for both client-side & server side rendering, replacing other template systems & having the best of both worlds (page caching, dynamic behavior on the client, a scalable front-end architecture, composition, etc).
https://svelte.technology/
Here's a quick post about my setup for static sites.
http://www.briantakita.com/posts/monorepo-static-sites-using...
Here's a post on converting from riotjs to svelte on a client project.
http://www.briantakita.com/posts/sveltejs-from-riotjs/
(I work with Ember.js daily and am happy with it, just curious to see your thoughts)
Vue is fucking awesome. I'm just now learning it and I can't wait to build something more serious than a todo app with it.
I don't work there anymore, but looking at the sites now, I can see the old ones are still online — TEN months later, no sign of Vue.
Why don't you like the docs? I love how it has a great introduction guide[1] that really dives deep into the hows and whys, but also has a full API guide when you just gotta know one specific thing [2].
[1](https://vuejs.org)
[2](https://vuejs.org/v2/api/)
It's solid and works much better than React or Angular.
- Better documentation. - Better ecosystem. - Better community. - Multilanguage (Chinese / English / Russian) - Proper scoping of concerns.
It really hits all the marks.
Any tips on how to start with the integration? Do you use node to serve the front end or is it served by django?
This is a confusing assertion. How does using a framework make your software unsupported in ways that not using a framework would not? i.e. if I build an application, whether I use a framework or not, and then I stop touching it, forever, why is the non-framework code more resilient to not breaking in the future?
The framework will keep evolving, but you're under no obligation to upgrade, if you don't need to keep developing. It seems silly to complain about the code you didn't have to write.
There are trade offs when using existing software to do things you want to do, sure. But, you get the core web app functionality you needed to implement, anyway, and it's been tested by a lot more developers than your code likely ever will be. In fact, I'd argue compatibility with a framework will be better than implementing it yourself, assuming you cover the same amount of functionality in each app; again, because of the heavier testing a widely used framework gets.
When did you ever build a relevant application and stop touching it, forever? Any worthwhile software I've ever built has been maintained with continuous effort. On the web especially, "don't keep developing" is just a death sentence.
There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved).
I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve?
You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box.
You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework.
Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA.
I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff.
I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.
When you roll your own, that is a non-issue. You can switch out libraries as you wish. I have made several major refactorings on my client's app with significantly less pain than it took to upgrade my previous clients' framework-based (i.e. Rails, angular) codebases.
When you roll your own, you can wait until libraries mature, or you can choose to use snippets of the essential code (thereby avoiding bloat).
I utilize patterns that minimize structural architecture, by utilizing dependency injection, es6 modules, promises, async/await, factory methods, agents with events. I avoid classes by utilizing factory methods.
http://www.briantakita.com/posts/sveltejs-from-riotjs/
I don't see how it can be. You've got to build and maintain it yourself now, instead of relying on a huge community of volunteers. If you're OK maintaining the entirety of the view layer framework (or whatever) yourself, where's the harm in starting from a known-good state? If you don't want to upgrade but want to add new features to the framework you picked, you can fork it and do that.
Now, if you don't like a given framework, having a framework is a loss because it'll suck to work on. I've seen this a ton. But, that's not the same problem and one that can be avoided by doing an extra day or two of due diligence and building a simple app before settling on your favorite. I dunno about you, but I've built libraries that I decided I hated after I was done with them. Sometimes, I rewrote them after I figured out why I was originally wrong about what I like, and sometimes I spent more time finding an appropriate replacement that somebody else made (this is usually the better choice).
You just end up inventing your own framework this way. You'll come across problems, come up with some solution you think is clever, come up with conventions to follow etc. Surprise! You've just manually rediscovered all the problems frameworks were created to solved and reinvented the wheel.
I'll use vanilla JavaScript or jQuery if the UI required is really basic but anything beyond that, you're going to save time using a well thought out framework rather than thinking you're smarter than whole communities who have spent years working on these solutions. Coders don't invent frameworks for the sake of it, they exist for a reason.
When I go to blog.poki.com, if I like what I read I typically delete "blog." to checkout what "poki.com" is about -- which should be the purpose of blogging. In this case it doesn't work, and I had to manually type "www.".
Relying on manual URL rewriting to navigate to a related page is missing the entire point of the web.