Do you really want a single-page application framework?(mmikowski.github.io)
mmikowski.github.io
Do you really want a single-page application framework?
https://mmikowski.github.io/no-frameworks/
104 comments
You're cherry picking.
One of his key points is that frameworks aren't "just architecture + libraries". Read his 2nd point, "Frameworks and the inversion of control".
Also, MV* hasn't been done in javascript for a decade. jQuery itself only came out a decade ago, MV* frameworks started appearing 5 or 6 years ago.
10 years ago most browsers in the wild were still IE6 which could barely handle 100 element for loops, let alone an mvc framework.
One of his key points is that frameworks aren't "just architecture + libraries". Read his 2nd point, "Frameworks and the inversion of control".
Also, MV* hasn't been done in javascript for a decade. jQuery itself only came out a decade ago, MV* frameworks started appearing 5 or 6 years ago.
10 years ago most browsers in the wild were still IE6 which could barely handle 100 element for loops, let alone an mvc framework.
There are certainly JS MV* frameworks older than 5 years... Dojo and puremvc come to mind.
> 10 years ago most browsers in the wild were still IE6 which could barely handle 100 element for loops, let alone an mvc framework.
Heh, I should tell you a story about 'enterprise' level frameworks of the 2005 era, and the abomination of entangling them with ActiveX.
Somehow, no one cared how slow a page was running, so long as it did it's job.
Heh, I should tell you a story about 'enterprise' level frameworks of the 2005 era, and the abomination of entangling them with ActiveX.
Somehow, no one cared how slow a page was running, so long as it did it's job.
I've done exactly what this author advises - that is, build a complex, real-world single-page app using nothing but jQuery and some plugins.
I didn't do this because I wanted to make some kind of point about architecture or overengineering. I did it because, at that time, front-end frameworks weren't a thing, and the phrase "single-page application" hadn't yet been invented. I didn't even know that was what I was building, because it hadn't been formalized as a concept. I just knew I had a problem to solve, a deadline to meet, and a contract to save.
Which I did. And it was terrible.
There's a point to be made about overengineering. If your app takes five seconds to rebuild after a single-line change, maybe there's a problem. But treating that as cause to throw the baby out with the bathwater amazes me in its foolishness. It makes exactly as much sense as saying that, because airplanes very occasionally fall out of the sky, they're not worth having at all.
I've been seeing a lot of this weird nostalgia lately, this technological-romanticist attitude that there was a better time before web frameworks because everything was so much simpler then. Well, I was there, and it was not. The problems were just as complex; the only real difference was that the tooling sucked. Now it doesn't. We no longer have to build complex applications from jQuery and bearskins. Speaking as one who has done so, that is not something to regret, and neither is a situation in which the major complaint we now have about our tools is that they do too much. As far as problems go, that's a really nice one to have!
I didn't do this because I wanted to make some kind of point about architecture or overengineering. I did it because, at that time, front-end frameworks weren't a thing, and the phrase "single-page application" hadn't yet been invented. I didn't even know that was what I was building, because it hadn't been formalized as a concept. I just knew I had a problem to solve, a deadline to meet, and a contract to save.
Which I did. And it was terrible.
There's a point to be made about overengineering. If your app takes five seconds to rebuild after a single-line change, maybe there's a problem. But treating that as cause to throw the baby out with the bathwater amazes me in its foolishness. It makes exactly as much sense as saying that, because airplanes very occasionally fall out of the sky, they're not worth having at all.
I've been seeing a lot of this weird nostalgia lately, this technological-romanticist attitude that there was a better time before web frameworks because everything was so much simpler then. Well, I was there, and it was not. The problems were just as complex; the only real difference was that the tooling sucked. Now it doesn't. We no longer have to build complex applications from jQuery and bearskins. Speaking as one who has done so, that is not something to regret, and neither is a situation in which the major complaint we now have about our tools is that they do too much. As far as problems go, that's a really nice one to have!
> If your app takes five seconds to rebuild after a single-line change, maybe there's a problem.
I don't see it as a problem with the app, I see it as a problem with the whole Babel -> Browser compile chain using lots of tiny files and imports.
My Python app which is 10x the size of the javascript one has a startup of 2 seconds. The JS app, is less than 5k lines and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-side.
I can't wait till browsers have native imports, and support all of ES2016. If even one does so, I'll switch to that for development and only compile for production.
I don't see it as a problem with the app, I see it as a problem with the whole Babel -> Browser compile chain using lots of tiny files and imports.
My Python app which is 10x the size of the javascript one has a startup of 2 seconds. The JS app, is less than 5k lines and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-side.
I can't wait till browsers have native imports, and support all of ES2016. If even one does so, I'll switch to that for development and only compile for production.
> and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-sid
That's crazy, you should check you're not running more stuff through babel than necessary. (Edit: also why are you compiling via Webpack serverside at all, that sounds like a bad idea)?
> I can't wait till browsers have native imports, and support all of ES2016 ...
Same except once we have native imports, I'd happily stop with what Chrome has now/then, give up the rest of ES2016 for not having to have a build step for local dev.
That's crazy, you should check you're not running more stuff through babel than necessary. (Edit: also why are you compiling via Webpack serverside at all, that sounds like a bad idea)?
> I can't wait till browsers have native imports, and support all of ES2016 ...
Same except once we have native imports, I'd happily stop with what Chrome has now/then, give up the rest of ES2016 for not having to have a build step for local dev.
> why are you compiling via Webpack serverside at all, that sounds like a bad idea?
Because it turned out to be faster to handle the compile serverside, then use hot-reloading.
Why are we using Webpack? Well because we use ES2016 for everything. I tried cutting down on the # of Babel transforms used, but some Babel plugins rely on the transform output of others (e.g. decorators/static members relies on ES2015 class transform), and so I ended up having to use 80% of all the 'standard' plugins anyways, plus everything up to stage 0.
The alternative was to go down to 3-4 second compile times, by eschewing everything that isn't implemented natively in Chrome. I rejected it as workable because our codebase was already pretty heavily leveraging decorators, but it's something to think about for other projects.
If you only use Chrome implemented features of ES2015, then all you need to make a build is a linker like Webpack/JSPM.
> That's crazy, you should check you're not running more stuff through babel than necessary.
Ah, I think you're saying this because of my 5k line of code figure for the JS project. I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).
The same is true for the Python project though, but Python is simply faster at linking pre-compiled files than Babel is. JSPM-client side is worse because it has to load each file individually in the browser and then check to compile it. Loading Babel itself in the browser via JSPM takes like 2 seconds.
Because it turned out to be faster to handle the compile serverside, then use hot-reloading.
Why are we using Webpack? Well because we use ES2016 for everything. I tried cutting down on the # of Babel transforms used, but some Babel plugins rely on the transform output of others (e.g. decorators/static members relies on ES2015 class transform), and so I ended up having to use 80% of all the 'standard' plugins anyways, plus everything up to stage 0.
The alternative was to go down to 3-4 second compile times, by eschewing everything that isn't implemented natively in Chrome. I rejected it as workable because our codebase was already pretty heavily leveraging decorators, but it's something to think about for other projects.
If you only use Chrome implemented features of ES2015, then all you need to make a build is a linker like Webpack/JSPM.
> That's crazy, you should check you're not running more stuff through babel than necessary.
Ah, I think you're saying this because of my 5k line of code figure for the JS project. I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).
The same is true for the Python project though, but Python is simply faster at linking pre-compiled files than Babel is. JSPM-client side is worse because it has to load each file individually in the browser and then check to compile it. Loading Babel itself in the browser via JSPM takes like 2 seconds.
> I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).
I think you misunderstood. You aren't supposed to run your dependencies through Babel.
I think you misunderstood. You aren't supposed to run your dependencies through Babel.
I had the same experience building a SPA with jQuery. Updating the view and keeping it in sync was atrocious.
I also made the mistake of making a non SPA recently, using jQuery on the front end. It's a nightmare. I did this so a friend could collaborate and learn, but I really dread writing code for the front end anymore.
Coming back to the old ways from Angular, Backbone, etc feels like a HUGE step backwards in terms of the amount of time. Like if for some reason I decided to ride a horse instead of drive a car.
I also made the mistake of making a non SPA recently, using jQuery on the front end. It's a nightmare. I did this so a friend could collaborate and learn, but I really dread writing code for the front end anymore.
Coming back to the old ways from Angular, Backbone, etc feels like a HUGE step backwards in terms of the amount of time. Like if for some reason I decided to ride a horse instead of drive a car.
I've got through the same pain. There's a reason why all these frameworks arose in the first place: frontend programming without them absolutely sucks.
JS dev is a shitshow because of npm, because of how fast things are moving, because of how many different frameworks and build tools exist. And most of all because of all the hipsterism, using new things because it's cool.
JS dev is a shitshow because of npm, because of how fast things are moving, because of how many different frameworks and build tools exist. And most of all because of all the hipsterism, using new things because it's cool.
[deleted]
I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc.
What's worse, a custom framework won't be known by any new developers, so you'll have to spend more resources onboarding them than, say, if you just had to show them how you're using Angular in your company (i.e. they'll already understand things like directives, components, etc.)
Finally, you lose the advantages of having an ecosystem of plugins, support, etc.
It just doesn't make any sense to me to roll your own. Any initial speed you gain you end up paying for later on. To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google whose only job is to think about the best way to write SPA frameworks.
Why would I not take advantage of that?
What's worse, a custom framework won't be known by any new developers, so you'll have to spend more resources onboarding them than, say, if you just had to show them how you're using Angular in your company (i.e. they'll already understand things like directives, components, etc.)
Finally, you lose the advantages of having an ecosystem of plugins, support, etc.
It just doesn't make any sense to me to roll your own. Any initial speed you gain you end up paying for later on. To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google whose only job is to think about the best way to write SPA frameworks.
Why would I not take advantage of that?
I find that when you start rolling your own framework, you just end up making crappier versions of what's in Angular, Ember, etc.
And that's a good thing.
The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.
The reason those frameworks you list are so "bloated" is that their developers have spent so much time polishing them up and general-purpose-izing them so that Everybody can use them for Everything.
Your thing is only for You to do Your Thing, so it can be much lighter and to the point.
And that's a good thing.
The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.
The reason those frameworks you list are so "bloated" is that their developers have spent so much time polishing them up and general-purpose-izing them so that Everybody can use them for Everything.
Your thing is only for You to do Your Thing, so it can be much lighter and to the point.
>The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.
Strongly disagree.
Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake.
The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time.
IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.
Strongly disagree.
Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake.
The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time.
IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.
> The second your application grows in an unexpected way, you need to augment the entire framework to suit
The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.
The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.
To be a devil's advocate: That's true, but still it's the last 10% that is hard when using a well-known framework, compared to 100% when you handcraft everything in a basement.
If you use a well-known fwk, you can tell junior devs and new devs to google stuff when in need (as a first line of help), otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.
There's no one-fits-all solution, depends on the project, team, constraints etc.
If you use a well-known fwk, you can tell junior devs and new devs to google stuff when in need (as a first line of help), otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.
There's no one-fits-all solution, depends on the project, team, constraints etc.
> To be a devil's advocate: That's true, but still it's the last 10% that is hard when using a well-known framework, compared to 100% when you handcraft everything in a basement.
I am saying they are about the same. The last 10% is about as much work as bootstrapping a specific solution.
The new junior dev point is irrelevant if you stick to plain vanilla javascript, and hire junior devs that actually know javascript. Your devs should know how to read code and tests.
> otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.
No I don't.
Junior dev: "hey how does this work?" Me: "Did you run the tests?"
I am saying they are about the same. The last 10% is about as much work as bootstrapping a specific solution.
The new junior dev point is irrelevant if you stick to plain vanilla javascript, and hire junior devs that actually know javascript. Your devs should know how to read code and tests.
> otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.
No I don't.
Junior dev: "hey how does this work?" Me: "Did you run the tests?"
Whilst this may be true in general, I find that when it comes to Javascript, things are already so sandboxed and reliant on the DOM api, that there's little you can do to shoot yourself in the foot.
At worst, your site won't be cross-browser compatible, but it's not like it's serverside where the framework is legitimately doing heavy lifting in a high performance environment.
At worst, your site won't be cross-browser compatible, but it's not like it's serverside where the framework is legitimately doing heavy lifting in a high performance environment.
> but you're making a really good problem specific framework that exactly fits the thing you're building.
Except when you don't. A lot of people, when they realize they're building a framework, start over-engineering (YAGNI). Another issue is that they, for example, build a template renderer but miss a lot of edge cases, opening their application up for script injection and other such nasty things.
Ten or so years ago, PHP had the same disease - people thinking they're hot shit, building their own frameworks, writing wrong tutorials on how to e.g. connect to a database because they thought they knew how that worked. This resulted in a huge amount of SQL injection issues, millions if not billions of hacked accounts, and billions in damages.
TL;DR don't write your own framework, please.
Except when you don't. A lot of people, when they realize they're building a framework, start over-engineering (YAGNI). Another issue is that they, for example, build a template renderer but miss a lot of edge cases, opening their application up for script injection and other such nasty things.
Ten or so years ago, PHP had the same disease - people thinking they're hot shit, building their own frameworks, writing wrong tutorials on how to e.g. connect to a database because they thought they knew how that worked. This resulted in a huge amount of SQL injection issues, millions if not billions of hacked accounts, and billions in damages.
TL;DR don't write your own framework, please.
PHP did not have a useful package manager back then. It has now.
Custom solution built on top of stable components > general purpose framework
Custom solution built on top of stable components > general purpose framework
Id agree, but add my own plea: please dont write an spa if you dont need one.
Yes I left that a bit ambiguous, but it is harder to manage and work witha rails and ember app than a reg'lear ol rails app. Thats cool if are genuinely getting something out of it. "Ember experiece" on your resume doesnt count.
Except that it does, bummed, but i do understand.
Yes I left that a bit ambiguous, but it is harder to manage and work witha rails and ember app than a reg'lear ol rails app. Thats cool if are genuinely getting something out of it. "Ember experiece" on your resume doesnt count.
Except that it does, bummed, but i do understand.
[deleted]
Well, every app is a snowflake, but there's now a pretty good snowflake framework. Meaning: programming is all about abstractions, and if you hit the right level, all applications pretty much converge.
Considering the manpower invested into today's frameworks and tooling, any single individual or small team doesn't stand a chance.
Though the learning curve is much too steep at the moment. It's improving, mostly because 10-level deep callbacks are being replaced with promises/await/async, but especially the tooling is still a daunting challenge for many.
There are now a few promising methods to get something running fast (create-react-app), but that seems to lead to opaque systems that usually work, but are prone to end up completely broken and incomprehensible when you're trying to customize them – because, for example, they do not validate their config files, use inconsistent naming, or deeply nested json where any deviation from the expected structure leads to silent failure.
Considering the manpower invested into today's frameworks and tooling, any single individual or small team doesn't stand a chance.
Though the learning curve is much too steep at the moment. It's improving, mostly because 10-level deep callbacks are being replaced with promises/await/async, but especially the tooling is still a daunting challenge for many.
There are now a few promising methods to get something running fast (create-react-app), but that seems to lead to opaque systems that usually work, but are prone to end up completely broken and incomprehensible when you're trying to customize them – because, for example, they do not validate their config files, use inconsistent naming, or deeply nested json where any deviation from the expected structure leads to silent failure.
you're making a really good problem specific framework
You really aren't. Well -- I don't know you personally, but speaking statistically, your homegrown one-off framework only makes sense to you and will require a major rewrite to accommodate that feature you want to add next week. And you're going to spend all your time until then debugging a glitchy state transition.
You really aren't. Well -- I don't know you personally, but speaking statistically, your homegrown one-off framework only makes sense to you and will require a major rewrite to accommodate that feature you want to add next week. And you're going to spend all your time until then debugging a glitchy state transition.
> The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.
But are you really? I'm not against rolling my own framework, but there needs to be very specifics reasons. The are so many reasons why using a popular framework is a good thing, that there have to be some very good reasons to roll my own.
> Your thing is only for You to do Your Thing, so it can be much lighter and to the point.
Unfortunately every time I have seen this reasoning used, it falls apart after starting. Rarely is software static, and instead it continues to grow. The custom framework may be lighter and to the point when you start and 6 months from now it is a bad copy of a common framework you could have just used off the shelf.
But are you really? I'm not against rolling my own framework, but there needs to be very specifics reasons. The are so many reasons why using a popular framework is a good thing, that there have to be some very good reasons to roll my own.
> Your thing is only for You to do Your Thing, so it can be much lighter and to the point.
Unfortunately every time I have seen this reasoning used, it falls apart after starting. Rarely is software static, and instead it continues to grow. The custom framework may be lighter and to the point when you start and 6 months from now it is a bad copy of a common framework you could have just used off the shelf.
[deleted]
I understand that rather than rolling out your own web framework we can just use existing frameworks. What are your thoughts about using libraries and not frameworks, like what what is popular with the Go language?
> Your thing is only for You to do Your Thing, so it can be much lighter and to the point.
And also doesn't handle things that didn't occur to you, like accessibility. Some of that bloat is actually useful, even necessary, to someone.
And also doesn't handle things that didn't occur to you, like accessibility. Some of that bloat is actually useful, even necessary, to someone.
> To me, using something like Angular means I can harness the experience and expertise of dozens of superstar coders at Google
You give them too much credit, and yourself not enough.
You give them too much credit, and yourself not enough.
> You give them too much credit, and yourself not enough.
On the contrary, the framework developers at Google, Facebook, etc. spend time on things that most web application developers do not. For example, accessibility for people with disabilities. If more web application developers would use these frameworks and follow the associated best practices, rather than all wanting to do things their own way, then maybe someday web applications will be accessible by default.
On the contrary, the framework developers at Google, Facebook, etc. spend time on things that most web application developers do not. For example, accessibility for people with disabilities. If more web application developers would use these frameworks and follow the associated best practices, rather than all wanting to do things their own way, then maybe someday web applications will be accessible by default.
I think in the best case scenario there should be a framework that doesn't need dedicated plugins - just using e.g. jQuery ones (because it has gazillions of them (plugins) already) - that would be wonderful
Disagree. Angular is a giant piece of bloated cheap that tries to do everything.
I'm so glad someone wrote preact
By using tools that do one thing and one thing very well it's easy to couple them together in interesting ways.
I'm so glad someone wrote preact
By using tools that do one thing and one thing very well it's easy to couple them together in interesting ways.
To me the question is more "do you really need a SPA" rather than "do you really need a framework for your SPA".
Way to many websites are using unecessary SPA which create more oportunities for things breaking, being incompatible, or taking longer to load than plain old server side html (plus with a flicker effect).
If you are really running an html application like an online trading platform then yes. But if you are a banking website and just want to display an account balance or the last 30 transactions, I fail to see why using a SPA makes sense. And I am not even talking about podcast websites or blogs where using an SPA is just absurd.
But as I noticed where I work, developpers are too often choosing technologies not based on the problem they are trying to solve, but based on the sort of keyword they want to see on their CVs. So I end up having to use hadoop for accessing 10MB csv files and dealing with similar moronic design decisions.
Way to many websites are using unecessary SPA which create more oportunities for things breaking, being incompatible, or taking longer to load than plain old server side html (plus with a flicker effect).
If you are really running an html application like an online trading platform then yes. But if you are a banking website and just want to display an account balance or the last 30 transactions, I fail to see why using a SPA makes sense. And I am not even talking about podcast websites or blogs where using an SPA is just absurd.
But as I noticed where I work, developpers are too often choosing technologies not based on the problem they are trying to solve, but based on the sort of keyword they want to see on their CVs. So I end up having to use hadoop for accessing 10MB csv files and dealing with similar moronic design decisions.
Bingo.
SPA is what I like to call "non-existent technology," meaning a buzzword that is neither a real technology people can download and use, nor a specification people can refer to. Other examples: "Cloud computing," "NoSQL," "SOA." It only really exists on people's resumes and on blog posts. Non-technical people have no way of knowing that it is not real.
There are good reasons why web applications have backends. There are also good reasons why you would use that backend to serve pre-rendered HTML. There are also good reasons why you would use page transitions to take the user from one screen to another. These concepts are lost on many developers nowadays. I'm not saying you never want an SPA, but it's really freaking hard to do because you're going against the grain on a platform with 20 years of progress in another direction.
What happens when non-existent technology makes up the greater part of the beginner's stack? When instead of the LAMP stack or Ruby on Rails, people graduate coding bootcamps with a specialty in building functional SPAs using NoSQL and cloud-based BFFs?
SPA is what I like to call "non-existent technology," meaning a buzzword that is neither a real technology people can download and use, nor a specification people can refer to. Other examples: "Cloud computing," "NoSQL," "SOA." It only really exists on people's resumes and on blog posts. Non-technical people have no way of knowing that it is not real.
There are good reasons why web applications have backends. There are also good reasons why you would use that backend to serve pre-rendered HTML. There are also good reasons why you would use page transitions to take the user from one screen to another. These concepts are lost on many developers nowadays. I'm not saying you never want an SPA, but it's really freaking hard to do because you're going against the grain on a platform with 20 years of progress in another direction.
What happens when non-existent technology makes up the greater part of the beginner's stack? When instead of the LAMP stack or Ruby on Rails, people graduate coding bootcamps with a specialty in building functional SPAs using NoSQL and cloud-based BFFs?
For cloud computing not being real, there is a lot of money being spent/made on it.
"Cloud computing," "NoSQL," "SOA" are concepts/ideas. They aren't "technologies" per say. There are, however, technologies that implement these ideas (AWS, CouchDB, Ostrich).
"Cloud computing," "NoSQL," "SOA" are concepts/ideas. They aren't "technologies" per say. There are, however, technologies that implement these ideas (AWS, CouchDB, Ostrich).
I am only making a point that concepts/ideas are not the same as technologies, and shouldn't be treated as if they are. It's gotten so out of hand now that I half-expect people to start attaching version numbers to them, like "NoSQL 2.0". It's as if the phenomenon of a "technology buzzword" has been totally divorced from the technical product the buzzword is supposed to refer to, which is frustrating.
If I have a resume full of concepts/ideas and no actual technologies, then the fact is that I can't be trusted to extend or repair any real system. The beauty of open source is that I do have skills I can take from company to company. I can use my Rails experience at one company to hit the ground running at another. If we start replacing actual technologies with mere concepts in our trade, then we still have a shared language but no shared skills. So the end result is eventually the same as if open source never happened and every programming environment was proprietary. End rant.
If I have a resume full of concepts/ideas and no actual technologies, then the fact is that I can't be trusted to extend or repair any real system. The beauty of open source is that I do have skills I can take from company to company. I can use my Rails experience at one company to hit the ground running at another. If we start replacing actual technologies with mere concepts in our trade, then we still have a shared language but no shared skills. So the end result is eventually the same as if open source never happened and every programming environment was proprietary. End rant.
Sure, put down details on your resume.
But calling SPA a "non-existent technology" is like calling SUV a "non-existent sandwich".
No one claims SPA is a "technology" any more than they claim REST is a technology. It's a paradigm.
But calling SPA a "non-existent technology" is like calling SUV a "non-existent sandwich".
No one claims SPA is a "technology" any more than they claim REST is a technology. It's a paradigm.
[deleted]
There are points in this article that go beyond SPA. In fact, I'd drop "for your SPA" from the title, and just use SPAs as an example. The author didn't, because, you know, he has a book to sell on SPAs, but let's let that slide. ;)
All the arguments he makes can be made about any framework, including server-side. Every point of pain he cites I can relate to from use of frameworks like Rails, Symfony, hell the abuse of Wordpress might qualify here.
Rails in particular: I was coding in Rails pre-1.0. Every major version upgrade has been hellish at some level. Often developers don't quite know what's going on only to find that callbacks or validations aren't working as expected.
We can still write awesome Ruby applications using all the libraries that make up Rails, but would I start with Rails these days? I'm not sure I would unless I was going to be working with a team that was quite junior where the gains from conventional layouts and inner workings might give us some gains.
That said, I'd also be transparent with them and myself about the costs of choosing a framework, any framework, and Rails is cheap in the short-term but I've seen it get expensive in the long term. Not because it's Rails or Ruby, but because it's a framework.
I used to think the lack of a decent CQRS framework in most languages was a problem. I now think it might be an advantage. As that pattern becomes more popular for complex domains, it's forcing developers to write better software, and I think somehow most of them are realising this is the way to go. Perhaps that's just my bias.
And it's also why Go is refreshing to me, personally. Frameworks are resisted by the community, primarily for performance reasons, but I actually think the author's arguments apply there too: with good enough library support we can get reuse whilst also not suffering IoC issues.
All the arguments he makes can be made about any framework, including server-side. Every point of pain he cites I can relate to from use of frameworks like Rails, Symfony, hell the abuse of Wordpress might qualify here.
Rails in particular: I was coding in Rails pre-1.0. Every major version upgrade has been hellish at some level. Often developers don't quite know what's going on only to find that callbacks or validations aren't working as expected.
We can still write awesome Ruby applications using all the libraries that make up Rails, but would I start with Rails these days? I'm not sure I would unless I was going to be working with a team that was quite junior where the gains from conventional layouts and inner workings might give us some gains.
That said, I'd also be transparent with them and myself about the costs of choosing a framework, any framework, and Rails is cheap in the short-term but I've seen it get expensive in the long term. Not because it's Rails or Ruby, but because it's a framework.
I used to think the lack of a decent CQRS framework in most languages was a problem. I now think it might be an advantage. As that pattern becomes more popular for complex domains, it's forcing developers to write better software, and I think somehow most of them are realising this is the way to go. Perhaps that's just my bias.
And it's also why Go is refreshing to me, personally. Frameworks are resisted by the community, primarily for performance reasons, but I actually think the author's arguments apply there too: with good enough library support we can get reuse whilst also not suffering IoC issues.
I think many of the arguments in this article might have been applicable back in 2012 when single page application frameworks were the new and popular thing. We can all agree that Angular 1 served us well at the time, but introduced added complexity and issues of its own (digest cycle being the main one). Some of the frameworks/libraries out there right now are stellar.
I have been using Aurelia for 1.5 years now and honestly, I could never go back to jQuery and other libraries again. I've worked with React, Vue, Angular 2 and dipped my feet into Ember. Of all of those, I would say Angular 2 was by far the most non developer friendly framework of them all. Ember is the most opinionated and some developers like that, but for me, I have settled on Aurelia and I do not plan on switching anytime soon.
Having said all of that, sometimes you don't need a SPA framework, sometimes jQuery or even Lodash will serve your needs. When it comes to needing support for routing, data-binding between view and some kind of view-model, I'll pick a SPA over jQuery and having to hack together something that is far less efficient than existing SPA solutions any day of the week.
Assess your needs and choose whatever works for you.
I have been using Aurelia for 1.5 years now and honestly, I could never go back to jQuery and other libraries again. I've worked with React, Vue, Angular 2 and dipped my feet into Ember. Of all of those, I would say Angular 2 was by far the most non developer friendly framework of them all. Ember is the most opinionated and some developers like that, but for me, I have settled on Aurelia and I do not plan on switching anytime soon.
Having said all of that, sometimes you don't need a SPA framework, sometimes jQuery or even Lodash will serve your needs. When it comes to needing support for routing, data-binding between view and some kind of view-model, I'll pick a SPA over jQuery and having to hack together something that is far less efficient than existing SPA solutions any day of the week.
Assess your needs and choose whatever works for you.
Did you mean "non-developer friendly" or "non developer-friendly"?
I think we can use context to easily infer what was meant: Looking at Angular, I don't see how a non-developer could even get started :-)
I mean, what would a non-developer do when given this (and that's a very simple example)? https://github.com/AngularShowcase/angular2-sample-app
I'm not making a quality statement, it's just that it is a complex framework for complex programming projects.
I mean, what would a non-developer do when given this (and that's a very simple example)? https://github.com/AngularShowcase/angular2-sample-app
I'm not making a quality statement, it's just that it is a complex framework for complex programming projects.
Thanks, I have no experience with it and could not tell (although yeah I was leaning for your interpretation)...
Maybe I'll reconsider this ng2 training then :)
There are legitimate disagreements to be had here but insulting the OP isn't one of them.
When I switched from Polymer to Angular (1) I found a pile of incoherent design decisions which hobbled performance. It's better than writing everything from scratch, but that's not saying much. Maybe Angular 2 is much better, but I understand why it was a total rewrite.
When I switched from Polymer to Angular (1) I found a pile of incoherent design decisions which hobbled performance. It's better than writing everything from scratch, but that's not saying much. Maybe Angular 2 is much better, but I understand why it was a total rewrite.
> insulting the OP
I misspoke, I mean the "original author" not the OP.
That doesn't make your reply to me
> insulting the OP
Oh Christ, I totally misread your post! I took "I don't see how a non-developer could even get started" as being in the first person. I'm sorry!
Angular 2, non-developer friendly? Not happening.
Angular2 is «some kind of developer» friendly. The kind that loves framework but hate the underlying problem.
It is like an heavy diving suits made for monkeys that loves to climb the height of frameworks complication.
But there are some other kind of developers that feel naturally at ease with swimming in the water of the problem at hand, without requiring the framework.
There is a class of expert coders that are in love with the tools, but really forgot that tools are a mean not an end. Imposing frameworks is for these monkey coders the way they can pay their enormous student debts. And they cannot live in a world where they have to adapt.
On the other hand, there are coders who can and prefer to swim and are infuriated at the absurdity of being a fish trapped in a heavy diving suit.
It is like an heavy diving suits made for monkeys that loves to climb the height of frameworks complication.
But there are some other kind of developers that feel naturally at ease with swimming in the water of the problem at hand, without requiring the framework.
There is a class of expert coders that are in love with the tools, but really forgot that tools are a mean not an end. Imposing frameworks is for these monkey coders the way they can pay their enormous student debts. And they cannot live in a world where they have to adapt.
On the other hand, there are coders who can and prefer to swim and are infuriated at the absurdity of being a fish trapped in a heavy diving suit.
No, we can't all agree that Angular 1 served us well. Terrible architecture IMO. Used it on one small project (just to be open minded) and never touched it again. React, on the other hand, is well founded, but has its own flaws, as does everything. Nothing is truly stellar.
I was amused by this HN comment saying that React is a tax Facebook imposes on startups https://news.ycombinator.com/item?id=12217170
I do think there's a kernel of truth to it--issues raised in this article and framework choice aside, it's good to ask whether your site needs to be an SPA at all. Because if so you are committing to a lot of time and resources spent on the front end.
I do think there's a kernel of truth to it--issues raised in this article and framework choice aside, it's good to ask whether your site needs to be an SPA at all. Because if so you are committing to a lot of time and resources spent on the front end.
On the other hand, it saves a lot of time in backend development if all you have there is an API.
HTML rendering, form handling, etc take up a lot of time in the backend too. And with the interactivity that is expected now for many pages (forms just as an example), you end up having to duplicate a lot of things on backend end frontend. And you end up using a framework on the backend too, because you really don't want to hand roll all the routing, templating and form handling. You don't. Trust me.
As long as you are comfortable with a JS stack (or have specialized devs for that) and have a good way of server side rendering figured out, I don't think an SPA incurs a big overall tax.
As an additional plus, there can be a lot more decoupling between frontend and backend work. You can stub out the API and work on the frontend independently in a much cleaner fashion.
HTML rendering, form handling, etc take up a lot of time in the backend too. And with the interactivity that is expected now for many pages (forms just as an example), you end up having to duplicate a lot of things on backend end frontend. And you end up using a framework on the backend too, because you really don't want to hand roll all the routing, templating and form handling. You don't. Trust me.
As long as you are comfortable with a JS stack (or have specialized devs for that) and have a good way of server side rendering figured out, I don't think an SPA incurs a big overall tax.
As an additional plus, there can be a lot more decoupling between frontend and backend work. You can stub out the API and work on the frontend independently in a much cleaner fashion.
It's not React itself that consumes time. On the contrary, React reduces the time it takes to develop UIs. Sometimes drastically.
What sucks is everything that surrounds React, or all other SPA frameworks for that matter. For instance, every time I end up having to deal with Webpack et al, I want to put a gun in my mouth and pull the trigger.
What sucks is everything that surrounds React, or all other SPA frameworks for that matter. For instance, every time I end up having to deal with Webpack et al, I want to put a gun in my mouth and pull the trigger.
Managing tooling and dependencies is the worst part of modern front end work.
I don't see why we have to weave such a complex dependency tree and asset pipeline. Every project does it differently too, so you end up relearning the same tool with a different name and in different configurations. Too bad if the previous developer didn't commit the dependency manager manifests or task runner file too, you can't reverse engineer an asset pipeline if all that's left is CSS and raw JS.
If anything goes wrong, you end up chasing issues through half a dozen abstractions you had never heard of. I can't keep all of this plus my actual project requirements in my head. Let me write some darn code already!
I don't see why we have to weave such a complex dependency tree and asset pipeline. Every project does it differently too, so you end up relearning the same tool with a different name and in different configurations. Too bad if the previous developer didn't commit the dependency manager manifests or task runner file too, you can't reverse engineer an asset pipeline if all that's left is CSS and raw JS.
If anything goes wrong, you end up chasing issues through half a dozen abstractions you had never heard of. I can't keep all of this plus my actual project requirements in my head. Let me write some darn code already!
Yes, especially the notorious npm which is hell bent on installing the entire Internet when I do npm install. God knows what and why it installs the things it does
Facebook's yarn [0] is a drop-in replacement for 'npm install' that significantly improves install times. Really makes me wonder what npm install is doing.
[0] https://github.com/yarnpkg/yarn
[0] https://github.com/yarnpkg/yarn
> Really makes me wonder what npm install is doing
Pattern matching.
For every dependency listed in package.json, npm install downloads and tests every JSON payload publicly available on the Internet until it finds one that produces the desired npm package.
Pattern matching.
For every dependency listed in package.json, npm install downloads and tests every JSON payload publicly available on the Internet until it finds one that produces the desired npm package.
I don't think parent was complaining about install times.
I use React all the time and don't currently work on a single SPA. Most of the time they are composable widgets that spit out hidden tags on a form. Even for simple things, React is usually much easier for me to reason about than the old jQuery way of transforming data and then transforming your DOM separately (or even worse, transforming your DOM, which is the same as your data).
As a library, its comparable in size to jQuery, which is pretty much ubiquitous these days.
As a library, its comparable in size to jQuery, which is pretty much ubiquitous these days.
People keep up-voting rants like this about how terrible front-end frameworks are, but EVERY SINGLE TIME I see an ambitious, high-quality web app upvoted, I check the source, and it's using a front-end framework. 99% of the time it's React or Angular.
If frameworks are these terrible monoliths that stop you getting anything done, how come the teams who are actually getting stuff done, and getting attention for its scope and quality, are the ones using them?
If frameworks are these terrible monoliths that stop you getting anything done, how come the teams who are actually getting stuff done, and getting attention for its scope and quality, are the ones using them?
It sounds like you saw some great apps using the right tools to solve the problem space and then you saw some unhappy devs who didn't pick the right tool for the job.
At this point, I can't really imagine writing a large web app without some sort of framework.
I've been using mithril.js a lot this year, and have found it to be unopinionated, minimal, performant, and fairly powerful. You are definitely not locked into some singular way of building applications.
It's a vdom framework, and its views are fairly similar to React (from what I hear, I haven't played with React much). You create a hierarchy of components, which each have a render function written in javascript. I've found this incredibly liberating. I love not having an unnecessary context switch between a limited template system and the rest of my application. Also, you can apply any desired javascript refactoring approaches to your views, instead of relying on pre-ordained approaches like template partials.
The only potential downside to the unopinionated-ness is that you have to decide how to structure things and what higher order patterns you want to use. This has slowed me down a bit, but it has also helped level up my architecture skills, which has been quite rewarding.
I could have chosen React, and I would probably be similarly happy. My main reason for not doing so is that things seemed a bit chaotic in the React world during 2015, and there also seemed to be a lot of spilt milk about doing things the "perfect way". I imagine it the ecosystem has calmed down a bit this year.
I've been using mithril.js a lot this year, and have found it to be unopinionated, minimal, performant, and fairly powerful. You are definitely not locked into some singular way of building applications.
It's a vdom framework, and its views are fairly similar to React (from what I hear, I haven't played with React much). You create a hierarchy of components, which each have a render function written in javascript. I've found this incredibly liberating. I love not having an unnecessary context switch between a limited template system and the rest of my application. Also, you can apply any desired javascript refactoring approaches to your views, instead of relying on pre-ordained approaches like template partials.
The only potential downside to the unopinionated-ness is that you have to decide how to structure things and what higher order patterns you want to use. This has slowed me down a bit, but it has also helped level up my architecture skills, which has been quite rewarding.
I could have chosen React, and I would probably be similarly happy. My main reason for not doing so is that things seemed a bit chaotic in the React world during 2015, and there also seemed to be a lot of spilt milk about doing things the "perfect way". I imagine it the ecosystem has calmed down a bit this year.
But the point is, neither React nor Mithril are frameworks, they are just unopinionated libraries where you write plain JavaScript code.
It's much closer to a framework than jQuery. Mithril also provides a few core things beyond just views - basic routing, an ajax helper, and a few others.
I admit the boundaries do seem to get a bit fuzzy. Do you think the article author would consider React or Mithril as libraries he could use? Or as frameworks to be avoided?
I admit the boundaries do seem to get a bit fuzzy. Do you think the article author would consider React or Mithril as libraries he could use? Or as frameworks to be avoided?
The answer is will a monolithic framework or a set of libraries help you build the best product with quality and quickly. Whichever one will help you build a better product is different depending on the context, project, scope, team and timeline.
In the end I am not a big fan of monolithic frameworks, I prefer libraries much like OP describes that can be swapped or changed for parts of the app (routing, data, templating, scripts, style, etc). But sometimes you are on teams and need a common baseline/plane to keep consistency so you go with frameworks sometimes rather than having to educate/train on custom.
In the end, what helps you ship faster and helps you focus on your product is always the best choice. If you are spending all day learning how to use the framework, going to conferences to learn it, building things in it and jimmying things so you can get it to do what you need by jumping through hoops, then it may be a drag on a good product.
Typically frameworks get you 90% of the way fast and the final 10% or customizing too much is painful, not to mention updates where APIs change wholesale. Custom gets you there slower but you can finish faster at the end as the control is immense. Custom usually allows more flexibility and changes that are on your schedule not the new versions of frameworks that might throw a wrench in timelines from time to time. Simplicity is the key to good custom apps to beat the maintenance time of monolithic frameworks.
A framework is an abstraction and you have to decide if that abstraction is worth it, the real platform is javascript, css, html in the end, how much stack do you want on top of that is a question that changes by project.
In the end I am not a big fan of monolithic frameworks, I prefer libraries much like OP describes that can be swapped or changed for parts of the app (routing, data, templating, scripts, style, etc). But sometimes you are on teams and need a common baseline/plane to keep consistency so you go with frameworks sometimes rather than having to educate/train on custom.
In the end, what helps you ship faster and helps you focus on your product is always the best choice. If you are spending all day learning how to use the framework, going to conferences to learn it, building things in it and jimmying things so you can get it to do what you need by jumping through hoops, then it may be a drag on a good product.
Typically frameworks get you 90% of the way fast and the final 10% or customizing too much is painful, not to mention updates where APIs change wholesale. Custom gets you there slower but you can finish faster at the end as the control is immense. Custom usually allows more flexibility and changes that are on your schedule not the new versions of frameworks that might throw a wrench in timelines from time to time. Simplicity is the key to good custom apps to beat the maintenance time of monolithic frameworks.
A framework is an abstraction and you have to decide if that abstraction is worth it, the real platform is javascript, css, html in the end, how much stack do you want on top of that is a question that changes by project.
Solid advice for anybody who is already an experienced developer and capable of authoring an SPA framework of their own.
For regular devs with deadlines, the need to onboard new team mates, and produce a readable and maintainable codebase, a modern SPA framework will be of benefit.
For regular devs with deadlines, the need to onboard new team mates, and produce a readable and maintainable codebase, a modern SPA framework will be of benefit.
"Well, actually, we do. If our overhead for producing working development code is greater than say, oh, 5 seconds, then somebody out there is definitely kicking our ass on cycle times. That developer can fail 300 times in an hour. If it takes 200 failures before success, it will take a miniumum of 40 minutes to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes because of all the multi-compile overhead, our minimum time for success will be 72 times longer, or over two full work-day. So we can pick 40 minutes or 2.1 days to resolve an issue to the same level of completeness. You make the call."
Interacting with other people is what takes my time, not trying to break the Guinness record of code changes per day.
Interacting with other people is what takes my time, not trying to break the Guinness record of code changes per day.
I am new to front end development - javascript and html. I am dismayed at how slow and unproductive I am trying to develop simple web apps. People advise me not to use jquery anymore because ES6 makes it redundant. But I am not sure.
I don't know if I want a framework, but I do want a library that lets me write less code, rather than solving boring problems that I am sure have been solved a million times before. But I guess at the same time, I want a fast loading web app. Where's the balance?
Interesting bit about the javascript transpilers. Some of them look cool, but I don't know how much static typing I need in something I am constantly refreshing and prodding. And it's another layer of complexity..
I don't know if I want a framework, but I do want a library that lets me write less code, rather than solving boring problems that I am sure have been solved a million times before. But I guess at the same time, I want a fast loading web app. Where's the balance?
Interesting bit about the javascript transpilers. Some of them look cool, but I don't know how much static typing I need in something I am constantly refreshing and prodding. And it's another layer of complexity..
Developing JS + HTML + CSS applications on a stack created for interactive documents, feels like stone age when compared to the RAD GUI tooling of the 90's.
It always feels like an whole generation was raised on the web without ever trying out proper tooling for native development.
For me it feels like a Roman taken from the apogee of the Imperium time traveling into the middle dark age.
EDIT: CS => CSS
It always feels like an whole generation was raised on the web without ever trying out proper tooling for native development.
For me it feels like a Roman taken from the apogee of the Imperium time traveling into the middle dark age.
EDIT: CS => CSS
> whole generation was raised on the web without ever
> trying out proper tooling for native development.
Most of the utilities - selectors, animations, xmlhttpwhathaveyou - have in the past ten years been moved from jQuery to being natively supported by browsers, so with that in mind, html5/css/es6 has made jquery obsolete - see also http://youmightnotneedjquery.com/ and similar sites.
The balance, it depends. I think the main value in opinionated frameworks - and typed languages - is in large applications, multi-person and multi-team companies.
Re: the article, 'vanilla' JS / jQuery does not scale to more than 10K LOC - if you are at that level, you're already building your own framework basically (NIH). Angular and other SPA frameworks are intended to help you not do that. More importantly, they imply a certain way to structure your application which others - that are added to the project later - can get up to speed a lot quicker than when you've rolled your own framework.
No, it might not be for you if you're a 31337 rockstar programmer that only works on their own projects and has never worked in the same codebase with other people, but if you're working on serious applications with a serious team, consider using an opinionated framework and a more restricting language.
The balance, it depends. I think the main value in opinionated frameworks - and typed languages - is in large applications, multi-person and multi-team companies.
Re: the article, 'vanilla' JS / jQuery does not scale to more than 10K LOC - if you are at that level, you're already building your own framework basically (NIH). Angular and other SPA frameworks are intended to help you not do that. More importantly, they imply a certain way to structure your application which others - that are added to the project later - can get up to speed a lot quicker than when you've rolled your own framework.
No, it might not be for you if you're a 31337 rockstar programmer that only works on their own projects and has never worked in the same codebase with other people, but if you're working on serious applications with a serious team, consider using an opinionated framework and a more restricting language.
I have to say that visiting http://youmightnotneedjquery.com/ has had the opposite effect on me. I may not need jquery, but I sure as hell want it.
Try mithriljs. It's the same idea as react for the view.
I was having the same experience as you setting up angular and react applications and wanted to go back to jQuery.
Having done some react I wanted something similar that I could use the chrome debugger in easily and didn't require any transpilers.
Very impressed with it so far. It only took a few hours for me to grok the documentation and start feeling productive.
I was having the same experience as you setting up angular and react applications and wanted to go back to jQuery.
Having done some react I wanted something similar that I could use the chrome debugger in easily and didn't require any transpilers.
Very impressed with it so far. It only took a few hours for me to grok the documentation and start feeling productive.
> I don't know how much static typing I need
A type system installs roads and rails, you still have the freedom to move but only on those roads. You have to install restrictions in any case: In your code, in your head. The type system makes them explicit, meaning they are easier to share in space and in time, with yourself (a week or a month later) and with other people.
Yes, it's one more tool to learn, but there is a reason it was invented instead of relying on "just code" and context. The good news: You can start simple and easy. No need to use complex type definitions right away. A lot of what the type system does is make restrictions explicit that exist anyway.
To be clear - I wasn't discussing the merits of static types. They are useful tools, and - all else being equal - I use them where available. It was more weighing up the cost benefit analysis of using something like Typescript, which would increase the complexity and the "cycle time" mentioned by the author.
Ah yes. Add to that that you have to choose between TypeScript and Flow - not as easy as one might think. Normally I go with the more wide-spread tool, but Flow has some good arguments on its side too, for example that it's "just types".
Answering the question in the title: no, probably you don't.
Many developers today do not understand what a SPA is and when one should choose this architecture. Writing a client side and a server side code is more complicated task that writing just a server side code so it should be justified.
Client side code is necessary when building interactive applications like spreadsheet or when an application has to work offline or store data locally. When a website feels more like a desktop application than a plain web page. There should be reasons to complicate architecture.
Most of a web sites are just a collection of pages, not applications. Using SPA there gives no advantages. For examples, developers of this website [1] used a megabyte of Javascript and API to display a list of 10 links. I do not see a single benefit from using SPA here over serving a 5Kb HTML file with those links. Everything just got worse.
And it looks like some JS frameworks authors do not understand it too. For example, I looked at Ember documentation and saw a tutorial [2] on building a rental site. Using Ember there gives no advantages over good old server-side generated pages (optionally using github-style AJAX page reloading). This over-engineered approach just makes a website load slower, comsume more CPU and memory resources, increases complexity, complicates deployment. If they are presenting Ember as a tool to build applications they should provide an example of application, not a plain old HTML 1.0 website.
[1] https://whosfiring.com/
[2] https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/
Many developers today do not understand what a SPA is and when one should choose this architecture. Writing a client side and a server side code is more complicated task that writing just a server side code so it should be justified.
Client side code is necessary when building interactive applications like spreadsheet or when an application has to work offline or store data locally. When a website feels more like a desktop application than a plain web page. There should be reasons to complicate architecture.
Most of a web sites are just a collection of pages, not applications. Using SPA there gives no advantages. For examples, developers of this website [1] used a megabyte of Javascript and API to display a list of 10 links. I do not see a single benefit from using SPA here over serving a 5Kb HTML file with those links. Everything just got worse.
And it looks like some JS frameworks authors do not understand it too. For example, I looked at Ember documentation and saw a tutorial [2] on building a rental site. Using Ember there gives no advantages over good old server-side generated pages (optionally using github-style AJAX page reloading). This over-engineered approach just makes a website load slower, comsume more CPU and memory resources, increases complexity, complicates deployment. If they are presenting Ember as a tool to build applications they should provide an example of application, not a plain old HTML 1.0 website.
[1] https://whosfiring.com/
[2] https://guides.emberjs.com/v2.9.0/tutorial/ember-cli/
I suggest people check out http://aurelia.io
Otherwise I have to say this is the worst advice for any engineer building a commercial website. Maybe if someone went back in time 10 years, this might look like a solution, but there is a reason all of this is left behind. I've been a web developer for 20 years now and browser development has finally graduated to real software engineering.
The author has a laundry list of grievances based on their own experiences. It's clear that these are merely opinions though, and they can be taken at face value.
"Frameworks and complexity === insanely long cycle times"
This is simply not true and it's purely subjective. Any developer using Continuous Development can roll out changes to production in a matter of hours, if not a few days. Sophisticated apps need to be modular and engineered for a simple workflow, automated testing and a clear separation of concerns. There is no point to setting yourself up for defeat, and if anyone followed this advice, that's exactly what would happen.
There's a clear distinction between the FUD of naysayers compared to people with more sophisticated levels of development experience. I am not sure someone with this mindset could even get past a phone screen. egad.
Otherwise I have to say this is the worst advice for any engineer building a commercial website. Maybe if someone went back in time 10 years, this might look like a solution, but there is a reason all of this is left behind. I've been a web developer for 20 years now and browser development has finally graduated to real software engineering.
The author has a laundry list of grievances based on their own experiences. It's clear that these are merely opinions though, and they can be taken at face value.
"Frameworks and complexity === insanely long cycle times"
This is simply not true and it's purely subjective. Any developer using Continuous Development can roll out changes to production in a matter of hours, if not a few days. Sophisticated apps need to be modular and engineered for a simple workflow, automated testing and a clear separation of concerns. There is no point to setting yourself up for defeat, and if anyone followed this advice, that's exactly what would happen.
There's a clear distinction between the FUD of naysayers compared to people with more sophisticated levels of development experience. I am not sure someone with this mindset could even get past a phone screen. egad.
I started web development by learning Angular 1, maybe I'm the minority, but I actually liked it in the beginning, and only grow to dislike after dived deep into it.
I was a web newbie but experienced developer in other field. The attraction of a framework like angular is it lets you write relatively large chunk of 'flat' code without having to worry about the structure of your code. So for a newbie it's easy to get started, of course you'll eventually face the dark side. But then you have to make a choice to either abandon angular and go for something else, or keep on going and make yourself good at angular.
Another thing is, there are plenty of good resources for learning frameworks like angular and react. Can anyone point to me some good up to date resources of building a functioning website from scratch by using purely jQuery?
I was a web newbie but experienced developer in other field. The attraction of a framework like angular is it lets you write relatively large chunk of 'flat' code without having to worry about the structure of your code. So for a newbie it's easy to get started, of course you'll eventually face the dark side. But then you have to make a choice to either abandon angular and go for something else, or keep on going and make yourself good at angular.
Another thing is, there are plenty of good resources for learning frameworks like angular and react. Can anyone point to me some good up to date resources of building a functioning website from scratch by using purely jQuery?
Well, actually, we do. If our overhead for producing working development code is greater than say, oh, 5 seconds, then somebody out there is definitely kicking our ass on cycle times. That developer can fail 300 times in an hour. If it takes 200 failures before success, it will take a miniumum of 40 minutes to resolve an issue with a 5s cycle time. If our cycle time is 5 minutes because of all the multi-compile overhead, our minimum time for success will be 72 times longer, or over two full work-day. So we can pick 40 minutes or 2.1 days to resolve an issue to the same level of completeness. You make the call.
I'm presently working my way through Programming in the 1990s. In it's controversial premise, it states:
Basically we are taught to guess our programs, and then to patch up our guesses. Our errors are given the cute name of "bugs". Fixing them becomes puzzle-solving, as does finding tricks that exploit or avoid poorly designed features of the programming language. The entire process is time-consuming and expensive.
And while I appreciate short cycle-times between code and result; I find "guessing my program into existence" is the most sure-fire way to shoot myself in the foot.
Now I don't write a specification for every program. However one doesn't have to these days to gain the benefits of fore-thought and reasoning. Functional programming has revealed many patterns and algebras for programs that work well in practice. If compiling a higher-level, soundly-typed language into Javascript takes an excruciating 5 seconds it'd still be worth it because I will have fewer bugs in my code, by design, over the developer that continually adds code in a hurried frenzy.
In spirit I agree that frameworks are restrictive but I don't see how Javascript is there to help prevent you from writing errors. A framework would at least give you the ground work to avoid egregious ones. Though better still, use functional programming patterns or languages if you can and compile down to Javascript if you must. Works well.
I'm presently working my way through Programming in the 1990s. In it's controversial premise, it states:
Basically we are taught to guess our programs, and then to patch up our guesses. Our errors are given the cute name of "bugs". Fixing them becomes puzzle-solving, as does finding tricks that exploit or avoid poorly designed features of the programming language. The entire process is time-consuming and expensive.
And while I appreciate short cycle-times between code and result; I find "guessing my program into existence" is the most sure-fire way to shoot myself in the foot.
Now I don't write a specification for every program. However one doesn't have to these days to gain the benefits of fore-thought and reasoning. Functional programming has revealed many patterns and algebras for programs that work well in practice. If compiling a higher-level, soundly-typed language into Javascript takes an excruciating 5 seconds it'd still be worth it because I will have fewer bugs in my code, by design, over the developer that continually adds code in a hurried frenzy.
In spirit I agree that frameworks are restrictive but I don't see how Javascript is there to help prevent you from writing errors. A framework would at least give you the ground work to avoid egregious ones. Though better still, use functional programming patterns or languages if you can and compile down to Javascript if you must. Works well.
The author has an entire section on long cycle times (time to make a change, compile/transpile it, and try it out) but it hasn't been nearly as bad for me. The worst case I've experienced was a large Grails app using Babel transpilation that could take a minute to compile all assets on first startup. But that worst case only happened after a full clean. Incremental builds took about 2 seconds. I've never experienced a 5 minute cycle time due to a transpiler.
In our case the productivity gains from ES6 features easily outweighed the compilation time.
In our case the productivity gains from ES6 features easily outweighed the compilation time.
Just feels like a rant tbh. I've developed spa's as well as django and rails app. I've seen bad spa's been written as well as bad server side routing apps. Shit code is shit code wherever/whatever language it's written in. To say you don't need some sort of FE framework is prob a bit much. You get so much for free and websites are getting more and more dynamic not less. Sure don't use flavour of the month frameworks. But I'd argue ng1, ng2, react, Vue etc are not flavour of the months.
Shitty code is one thing. Shitty choice of the solution for the problem at hand is on another level.
At http://www.reportdash.com we use backbone with backbone layout manager and jade. We have been able to design a pretty robust report and dashboard builder with just a single front-end developer.
Never once did I regret the choice, nor has been limited by the choice. I pretty much could implement everything I thought with minimal effort.
I would say backbone with backbone layout manager has the bare minimal abstraction. It just boils down to picking the right pattern. I use a state variable to hold everything related to the dom, and re-render the dom whenever the dom needs to be updated. May not be as fast as 'react', but at least in my case, it is good enough. ( Since my 'views' are nicely factored, I often has to re-render only a small part of the dom)
Without the framework, I would have taken double the time for sure. And boy, the code is nicely organised as well.
I did have some experience in developing spa's using jquery alone. Well, that was in 2009. On any day, I would vouch for Backbone+ Backbone Layout Manger + Jade over simple jquery
I used to wonder why it hasn't been as popular as react or angular.
Never once did I regret the choice, nor has been limited by the choice. I pretty much could implement everything I thought with minimal effort.
I would say backbone with backbone layout manager has the bare minimal abstraction. It just boils down to picking the right pattern. I use a state variable to hold everything related to the dom, and re-render the dom whenever the dom needs to be updated. May not be as fast as 'react', but at least in my case, it is good enough. ( Since my 'views' are nicely factored, I often has to re-render only a small part of the dom)
Without the framework, I would have taken double the time for sure. And boy, the code is nicely organised as well.
I did have some experience in developing spa's using jquery alone. Well, that was in 2009. On any day, I would vouch for Backbone+ Backbone Layout Manger + Jade over simple jquery
I used to wonder why it hasn't been as popular as react or angular.
You don’t need any of this stuff to build a great web app. You don’t need react, you don’t need fancy javascript syntax that requires you have a complicated build infrastructure. Babel has over 40,000 files. Think about that for a moment. 40k files for some shorthand syntax. Your "build" times may only be a few seconds now (anything that is over one second imo is too long), but just wait. They will get to 30+ seconds in no time and then you'll have to go dive into the belly of that 40k file beast to find out how to unfuck yourself. I've been there.
You don’t even need a framework most of the time. Most of the frameworks I’ve used are poorly designed (I'm looking at you Ember. If there are any Ember devs reading this, I'll meet you in the parking lot...) and represent the design choices of a someone working on some project probably a lot different than yours. It feels good to give up control and let someone else make some choices for you, until you realize you’ve built an application based upon their poor design, and then you’re stuck.
All you need is semantic HTML, the DOM, and some plain old javascript. Organize your code, write simply, don’t overcomplicate and try to make things too general because your problems probably are very likely concrete anyway. Don’t buy into the hype. Just because big company X uses something, doesn’t mean you need to use it on your projects too. Have you seen Facebook? Their product hasn’t changed or innovated appreciably in years so you shouldn’t be taking any lessons from them in how to build ‘scalable’ applications, whatever that means.
Don’t dump a 500 KB framework on the page to save a few milliseconds in incremental rendering. Or think you need to worry about performance or complexity before you even have an app.
Is it odd to anyone that the entire battle cry of React is rooted in pre-optimization? The myth that the DOM is somehow evil, or all pages will one day have millions of elements to manage? This is gladly spoonfed to people who don't understand how the browser works, and never learned the basics. Take away their framework and they don't know how to build apps!
It violates my sense of pragmatism to save a few ms in rendering when you delay the initial page load by 500 ms or more? I also personally find the mixing of declarative and imperative programming styles and JSX to be absolutely horrid and the debug experience of many of the immutable libraries to be terrible. And, if you actually performance test the stuff you'll see they are full of either outright lies or fabrications to make the authors look good. Hint: if every time you call a getter on an object it causes the framework to go 30 stacks deep you're not going to have good performance. Just try it in your framework of choice today. You're swear we're working in java these days with the stack traces so deep and abstracted they have lost all touch with reality.
My favorite recently is to find all kinds of bizarre wrappers for javascript libraries that could have been used well enough on their own. The wrappers don't really do anything other than hard-code the original author's API and basically act as a middle man. I guess everything needs to be wrapped in a react component to be useful these days huh?
You don’t even need a framework most of the time. Most of the frameworks I’ve used are poorly designed (I'm looking at you Ember. If there are any Ember devs reading this, I'll meet you in the parking lot...) and represent the design choices of a someone working on some project probably a lot different than yours. It feels good to give up control and let someone else make some choices for you, until you realize you’ve built an application based upon their poor design, and then you’re stuck.
All you need is semantic HTML, the DOM, and some plain old javascript. Organize your code, write simply, don’t overcomplicate and try to make things too general because your problems probably are very likely concrete anyway. Don’t buy into the hype. Just because big company X uses something, doesn’t mean you need to use it on your projects too. Have you seen Facebook? Their product hasn’t changed or innovated appreciably in years so you shouldn’t be taking any lessons from them in how to build ‘scalable’ applications, whatever that means.
Don’t dump a 500 KB framework on the page to save a few milliseconds in incremental rendering. Or think you need to worry about performance or complexity before you even have an app.
Is it odd to anyone that the entire battle cry of React is rooted in pre-optimization? The myth that the DOM is somehow evil, or all pages will one day have millions of elements to manage? This is gladly spoonfed to people who don't understand how the browser works, and never learned the basics. Take away their framework and they don't know how to build apps!
It violates my sense of pragmatism to save a few ms in rendering when you delay the initial page load by 500 ms or more? I also personally find the mixing of declarative and imperative programming styles and JSX to be absolutely horrid and the debug experience of many of the immutable libraries to be terrible. And, if you actually performance test the stuff you'll see they are full of either outright lies or fabrications to make the authors look good. Hint: if every time you call a getter on an object it causes the framework to go 30 stacks deep you're not going to have good performance. Just try it in your framework of choice today. You're swear we're working in java these days with the stack traces so deep and abstracted they have lost all touch with reality.
My favorite recently is to find all kinds of bizarre wrappers for javascript libraries that could have been used well enough on their own. The wrappers don't really do anything other than hard-code the original author's API and basically act as a middle man. I guess everything needs to be wrapped in a react component to be useful these days huh?
Since the article doesn't define the acronym and I had to look it up:
SPA means Single Page Application.
The term is written in the third paragraph, but not clearly connected to the acronym.
SPA means Single Page Application.
The term is written in the third paragraph, but not clearly connected to the acronym.
JQuery solved a real problem when it was created. But the problem no longer exist, the standards has settled. But at least you can just stop using it and use CSS and standard API's instead. But when it comes to a framework, especially if it has a compilation step, it's not easy to just stop using it.
A need to use frameworks is the unification matter. Unification is necessary for serious/big projects for obvious reasons. Ie you can find people on the market who are able to start working quickly due to the familiar tools/structure used, not dealing with some "homemade" frameworks.
I feel this way about backend frameworks, but to me if you take the time to learn something like Angular, it saves will reduce the bulk of the code substantially, compared to using jQuery for example. A listener for this, a listener for that? No, just data-bind and be done with it.
There are challenges of course. Once you are in, you are all in, and you will be maintaining this application for its lifetime or rewriting it. Javascript frameworks these days move at the speed of sound, so if you start writing it today at while your framework is at v1.0, there is a good chance that your framework will be v1.5 by the time you release, with several breaking changes. This is probably the most aggravating part to me.
I have thought that perhaps the diversity of opinions on these sorts of issues, and the speed at which these frameworks are written and rewritten are symptoms of a larger problem, namely the browser as a platform.
There are challenges of course. Once you are in, you are all in, and you will be maintaining this application for its lifetime or rewriting it. Javascript frameworks these days move at the speed of sound, so if you start writing it today at while your framework is at v1.0, there is a good chance that your framework will be v1.5 by the time you release, with several breaking changes. This is probably the most aggravating part to me.
I have thought that perhaps the diversity of opinions on these sorts of issues, and the speed at which these frameworks are written and rewritten are symptoms of a larger problem, namely the browser as a platform.
[deleted]
I'd rather have a good, easy to use library than a framework.
Developers want declarative widgets mainly. Obviously web components are supposed to solve all that but they are still not widely supported by browsers.
To answer the question, yes. Yes I do.
just use http://Bubble.is
No, not at all.
Yes
This is insane.
Even keeping two different views in sync in different parts of an application without a framework is so much work it's not worth the effort, let alone building a whole SPA.
But to each their own.
Even keeping two different views in sync in different parts of an application without a framework is so much work it's not worth the effort, let alone building a whole SPA.
But to each their own.
Then goes on to say When we use a sound architecture and libraries instead - well, guess what? Frameworks are just architecture + libraries! In fact, your plan to release an "npm module" with architecture, diagrams and library dependencies is a framework, a mishmash of solutions of varying quality!
Of course they have varying levels of coupling - it's probably hard to replace parts of Angular, but Mercury for example is just a bundle of easily swappable libraries, like many others. React itself is not a framework.
It also completely overlooks the architectural differences that have come to exist in modern SPAs. What he proposes in the linked slides is just MV*, which everyone already has done for a decade. Flux-style state management + reactive rendering is a huge improvement over that and you won't get that just by using jQuery.
The author actually maintains a virtual-css library (PowerCSS) which benefits from the same principles, yet fails to see the value of doing the same with the DOM. This library + jQuery is already as large as many frameworks.