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.
> 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 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.
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.
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.
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.
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.
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 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.
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).
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.
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.
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.
Not true. If you do proper caching and configure your nginx properly back-end rendering can be just as fast.
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 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.
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.
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.
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.
Any tips on how to start with the integration? Do you use node to serve the front end or is it served by django?
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..
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 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.
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.
(I work with Ember.js daily and am happy with it, just curious to see your thoughts)
