That's what nearly everybody does, when they're one person hacking on a one-off project.
I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
https://github.com/johnpapa/angular-styleguide
We didn't need an expert.
I don't want to be hunting all over my code base just to figure out what is happening in a controller or component.
JPs styleguide is awesome!
Or we could just adopt good coding standards and build with reasonable software architecture. That's been working for longer than anything like the modern Web has existed, to build software orders of magnitude larger than any web app by any useful metric I can imagine, without the need to resort to huge frameworks to keep growing code bases organised and consistent.
Now that I think about it, the zeitgeist here really does feel like those cheesy "Learn C++ in just 20 minutes a day!!!!!" books
There seems to be a new generation of developers who think that 10,000 lines of code is a big program, a web app doesn't need to last more than a year or maybe two at most, and any sort of in-house programming or software design work will be inherently inferior to any external code you can import instead. These people are probably doomed no matter what they do.
There's a certain irony that in the one clear exception to that rule -- if you really are building a throwaway MVP in the expectation that it will either fail quickly or succeed enough be be worth rewriting properly later -- it mostly doesn't matter what tools or practices you follow. As long as you have some basic competence regarding security and you're keeping any important data somewhere safe so it can be transferred reliably to a new system later, the strategy is what it is. However, that also means many of the claimed advantages of frameworks are irrelevant to such projects, because you don't really care about things like longevity or being able to hire more developers already familiar with the framework or keeping growing teams consistent in how they design a growing code base.
This one made my day xD
10kLOC is a top limit for my programs (I say that whatever has higher line count starts boring me), and those were just small tools for sysadmins since forever.
Web frameworks have architecture to them, but their value lies in solving technical problems, not architectural ones.
I respectfully disagree. You don't need a framework to do any of those things.
I do a lot of work with relatively complicated browser-based UIs. In my experience, the DOM/layout thrashing and jank issues that have been getting a lot of attention lately only became a big deal in the first place because the early frameworks were so horrifically slow compared to just doing manual updates of exactly what you needed to change. Even in the most demanding applications -- and not many web apps actually are this demanding -- you could achieve pleasant, smooth results with some modest attention to how you applied updates so you didn't cause the browser to regenerate layout unnecessarily. (This would be an example of a useful coding standard, BTW.)
Flashes of unstyled content/text/whatever are a symptom of serving web pages in chunks and how browsers render incrementally as more of the chunks are available. Again, dealing with these effects just requires some understanding of what causes them and a little care in how your site/app is served and does its initial setup. The frameworks don't do anything magic that you can't do in your own code.
And finally, we were solving cross-browser portability problems with script repositories and then libraries like jQuery a long time before any of the modern frameworks were on the scene, and in a much more varied environment in the early days. IE has certainly had its issues over the years, but for the most part at least the issues were well known and you could just work around them. And again, there weren't really that many horrible issues, and this was an area where having some basic coding standards worked OK even if for some reason you didn't want to just use one of the many utility libraries.
Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it.
So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity.
(I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)
> The library is very useful for (?) UI problems...
Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it".
Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines.
> ...toolchain fetishism which tends to cloud React's fundamental simplicity
This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about.
myMod.component('Foo', {
template: '<h1>{{$and.better.templating}} {{see()}}</h1>',
controller: function() {
var and = {this_one: 'does_stuff'};
}
});Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems.
React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
It's perfectly possible to just use React on its own, without getting bogged down with all the other buzzword-of-the-week stuff around it.
React itself has been reasonably stable for a long time in Web terms. It is much more tightly scoped and smaller in its interface than most JS frameworks. There are a couple of major design trade-offs, which often seem to get overlooked in React advocacy, but if you have a bit of experience using it and understand the practical pros and cons then you can quickly decide whether the balance is favourable for some new project.
People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
Some people who work with React might. Plenty of others don't.
When I first started with React, it felt awesome - just React still feels great. But I had just started then and then got introduced to redux (I had been using something similar custom built). That was good too, until I learnt react-redux. I get the concepts, I understand every bit of it and have used it correctly in many large apps - it is useful. But react-redux just feels awkward many times and I consistently feel something is wrong with it - but I don't know what. React-Redux just feels disconnected with the idea of independent web-components.
On a side note - If one is okay moving to Typescript, Angular2 is just amazing.
Define "meaningful".
You might want to spend some introspection time on that statement.
Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.
Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses.
So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.
Yes. If anyone has evidence of this I'd love to see it.
If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade.
Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives.
If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.
It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated".
Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb.
My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage.
Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.
There are a lot of things that you have to do regardless of how the app is delivered - you need to work out what the app actually needs to do, you need to design the business logic, you need to design the look and feel, you need to get the UX right, you have to throughly test it. On a decent size app, the job of actually writing the code is about 25% of the work required. In my opinion, something that represents a quarter of the project probably shouldn't drive the entire process.
https://developers.google.com/web/fundamentals/getting-start...
As it is though, the API for file system access in JS might not be standard yet (and might never be) but it works well in Chrome: https://developer.mozilla.org/en-US/docs/Web/API/File_System...
If that's not the case, it's pointless to create a web-based product. Just offer the full thing as an app and a simple web UI.
I looked at the WaPo link that you posted and it seems to be exactly this type of product with an identity crysis - my browser already allows me to save pages for later reading and if that won't work, there are a multitude of offline reading apps to choose from, I don't need a WaPo "progressively enhanced" app for that.
For such an app, having a longer load upfront in order to facilitate vastly better UX than using purely server-side rendered pages is a huge win for our customers, and having the time to load & interact being low also adds tremendous value to the customers, to the point that they flock to us over our competitors.
I don't find myself having a problem with frontend web app architecture - most of the problems out there are already solved or solvable with a little time spent on thought, but the knowledge is not widespread, and so we have a lot of people who have never seen what good structure looks like.
There's always cases where it makes sense to make use of particular technologies. It absolutely does not make sense to transform most websites into web apps that are completely broken without JavaScript, which is what's happening right now.