91–100 of 356 posts
You might not need a framework, but you'll need a structured approach to avoid those problems, and frameworks can help a lot with security.
The point of React isn't its performance (though that is nice). The point of React is the simplicity and composability of functional components. You can create this on your own of course (and I have), but the solution of "just use the DOM" ignores an enormous amount of progress that React made with component design , not performance.
The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against
Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a:
* client side router * data transportation/cache layer * view layer * model layer * build pipeline
... and more, in less code that just
`npm install -g ember-cli` `ember new my-app`
And then having a common app structure with thousands of other people that can provide help and insight.
You people really are kidding yourselves. I feel bad for whoever is paying your salaries.
Contenteditable is so annoying that the first thing most rich text editors seem to do is make their own selection state manager, because the native range implementation in the DOM is crap. Medium in particular pretty loudly got rid of it entirely, and that's the direction most modern web-based rich text editors are going.
So. The best thing to do here is find some kind of framework that helps you map from user intent into mutating a data model, and a separate way to translate that data model into the DOM. This sounds like a framework to me, and it especially sounds like one if you want it to work on lots of platforms.
Similarly, sure: I don't need a framework to do DOM manipulation. But I've been using angular (1.x) for a few years now, and I can say: it makes life a lot easier. If I don't have to debug lines of javascript looking for where different elements get injected into the DOM, I'm happy. I can just look at the template file for the html code I'm editing and see where classes get programatically changed based on state, not because I'm deep inside some MutationObserver, but because I can read an ng-class directive. Easy pie.
I sure don't need a framework. I could also program in ones and zeroes. Speaking as someone who's been doing web stuff since the 90s, where the first framework I ever wrote was a bunch of DIY C libraries to make writing cgi-scripts easier, I can say with all honesty: using a framework makes life easier.
Sure, it's annoying to learn, and sometimes the opinions of the framework are different from your opinions. That's why I use angular instead of ember (because I'm not a rails person, for the most part). Take your pick, learn it well, and it will make your life easier.
And if you're that worried about the weight of your library, stop loading so many hero images uncompressed.
(I will grant edge cases where library size is a big deal, but it's more of a premature optimization thing in most places, especially now that tree shaking is starting to make its way back into our build tooling).
I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came…
I didn't downvote you (and I thought it was a thoughtful post), but I could totally see somebody interpreting "web-boy" as some sort of weird emasculating epithet a la "fanboi". On the Internet it's super easy to take offense at things that weren't intended to offend, in fact some people seem to thrive on it.
I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came…
Honestly, it just sounds like you are bad at managing your own software projects and trying to blame it on the web team. If your code had been as easy to understand as you say it is there would have been no need to re-write it. Also, your acknowledgement that it was difficult to maintain makes my point for me.
I wanted it to be rewritten before I wrote the first line of code. My trust went to someone who does full-time web development (I'm alround, full-stack).
Earlier quoted context omitted.
Yeah I find it hard to believe that the people who go on about how convoluted web development is actually get paid to do web development. 1) Where are all the people hiring web devs who don't know a single library or framework? 2) Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?
So your suggesting that if you question the system, you shouldn't get hired, or paid? I don't think he's saying hire web developers who don't use a single library or framework; he's calling for some perspective by looking at the latest state of system. He answered #2 in the very beginning of the article: "React was created to solve the issues Facebook were facing with their massive amount of data, activity and size."…
No, I'm saying people don't typically hire developers who don't know ANY libraries or frameworks.
That's reality.
I'm really glad I don't have to work with people who think like this. You don't NEED a framework, just like you could theoretically build a car from scratch. If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. Frameworks do exactly what they say, provide a common framework for your team to work off of while they build a complex application. I fee…
If layers upon layers of frameworks really were the best approach for complex applications then why can't people get behind one clear winner? Why does there seem to be a new framework popping up all that damn time? How much money has been lost simply keeping up with the artificially hastened pace of change?
Now, I personally have nothing against frameworks individually, but collectively people seem to pile them on top of each other. One is enough -- the beauty of web standards is that there is a common language that one simply needs to speak to access.
You are profiting from the community's collective lack of technical rigor.
Earlier quoted context omitted.
> If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. That's the very mentality that gave us J2EE crapfest and poisoned JS. The idea that a complex app requires a kitchen sink approach and framework-itis...
Complexity requires structure in order to be maintainable. Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. Both are signs of inexperience.
"Another example is the Fetch API"... That API has very limited cross-browser support. One of the largest reasons web frameworks exist is to bridge the gaps between browser incompatibilities/offering legacy support. I don't know if this person has even really scaled and deployed a web application that must work across several browsers - especially older browser versions. I always wonder that whenever I see people bas…
Earlier quoted context omitted.
Complexity requires structure in order to be maintainable. Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. Both are signs of inexperience.
> Complexity requires structure in order to be maintainable. Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job. It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design. You know th…
A competent lead programmer will choose a structure that adheres to common best practices and is maintained by a community. Also known as a framework.
>If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
200,000 libraries, 50 of them good. My point exactly. A well written framework has already done the curation for you and has a community of people working to make those components even better for YOUR USE CASE.
>Both are signs of inexperience.
I guess I won't be hiring you then. If a candidate comes in and says "I don't trust frameworks because they are complex", I say "Thanks for your time."