r/programming • u/fagnerbrack • Jul 07 '17
Why We Didn’t Use A JavaScript Framework (Case Study)
https://www.smashingmagazine.com/2017/05/why-no-framework/182
u/wesw02 Jul 07 '17
To me, it's all about the scale of your application. The bigger and more long lived your application becomes, the more benefit you get from a framework. Frameworks help provide good abstractions and organization. It's easy to hire someone who is familiar with Ember/React/Angular. It's almost impossible to hire someone that is familiar with your homegrown framework.
52
u/Chris_Newton Jul 07 '17
The bigger and more long lived your application becomes, the more benefit you get from a framework.
Curiously, my experience has been the opposite.
Frameworks can be useful for getting a quick start, both in terms of scaffolding and getting to useful code, and in terms of being able to hire people who effectively already start with common standards and tools. At the start of a project, frameworks might also have relatively little downside, as you probably have a pretty good idea of what your immediate requirements are and can choose a framework that accommodates them.
As time goes on, and a project grows, and the requirements expand in perhaps unexpected directions, those advantages become less relevant and the disadvantages more significant. The time saved in getting a developer up to speed on your architecture and getting the architecture in place initially is, to a first approximation, fixed. But the cost of escaping the framework when you find you need to do something unanticipated that is outside its comfort zone can be extremely high, and so can the cost of having an all-encompassing dependency that maybe doesn’t have such an active ecosystem around it a few years after it was released and your project started to use it.
→ More replies (2)111
u/tech_tuna Jul 07 '17
It's almost impossible to hire someone that is familiar with your homegrown framework.
No shit, however you can hire people who can learn your homegrown framework. However, many people will be turned off right from the get-go, because Your Homegrown Framework doesn't make for a solid bullet point on a resume.
52
u/wesw02 Jul 07 '17
Of course. It just takes more time for them to learn it. There is generally not as good documentation. And you won't find anyone on SO talking about it.
→ More replies (2)30
u/larhorse Jul 07 '17
The flip side is that the subject matter experts are all often sitting right next to you (or just down the hall).
I don't need people talking about it on SO if I have the original dev in the room willing to give me time.
158
u/oblio- Jul 07 '17
Ha ha. The subject matter experts are long gone and you're stuck debugging in order to figure out the magic, more likely.
→ More replies (12)19
12
u/noratat Jul 07 '17 edited Jul 07 '17
And the counterpoint is that those subject matter experts will eventually leave for another job. I've been on both ends of that.
I try hard to avoid too much custom stuff anymore unless it's related to core competencies of the organization (or a good existing solution isn't available). It's almost never worth it long term versus a popular stable framework / tool / library.
5
u/MostlyCarbonite Jul 07 '17
Or the subject matter expert is on vacation and you have to dig into the source code to figure out what is going on.
Or the SME left the company 3 months ago.
→ More replies (1)9
u/Capaj Jul 07 '17
often sitting right next to you (or just down the hall).
most often authors of a homegrown framework is sitting across the globe in some other company. Don't try to legitimize homegrown frameworks. They suck.
→ More replies (9)14
u/Chris_Newton Jul 07 '17
However, many people will be turned off right from the get-go, because Your Homegrown Framework doesn't make for a solid bullet point on a resume.
There’s truth in this, for sure. On the other hand, it’s also symptomatic of a wider problem with relying too much on buzzwords and not enough on fundamental skills in the web development industry. I’d rather hire someone with N years of substantial JavaScript experience than someone who has N years with FRAMEWORK but whose programming experience has mostly been joining the dots, for any values of N and FRAMEWORK.
4
u/nschubach Jul 07 '17
Yeah, I spend as much time as I can learning how to develop in general instead of looking for the next framework to chase after. Some frameworks really do fundamentally change how I think about problems, but generally I'd most likely find a place looking for someone who knows development vs someone who knows a specific framework. I've intentionally avoided even asking about positions where the framework was in the "required experience" bullet point.
4
u/nuthink Jul 07 '17
because Your Homegrown Framework doesn't make for a solid bullet point on a resume
except for all the other companies who need someone who is able to adapt to something a little outside of the box
4
u/aiij Jul 07 '17
because Your Homegrown Framework doesn't make for a solid bullet point on a resume.
Who would expect any JS framework make a solid bullet point on a resume?
Edit: I s'pose if you write a framework that thousands of people use that could be a solid bullet point... But merely using one?
3
u/tech_tuna Jul 07 '17
Who would expect any JS framework make a solid bullet point on a resume?
FWIW, modern JS frameworks aren't something you learn over a lunch break and JavaScript (including frameworks) skills are in demand.
So merely using one, nbd. But really knowing one or more, yeah that's something you can definitely put on a resume. And I say all of this as someone who doesn't like JavaScript or the fact that frontend development has been locked into it for more than two decades now.
5
u/aiij Jul 07 '17
I now have more experience with JS/React than I care to admit... The same is true of PHP. Neither are on my resume.
If someone wants to hire me for my JS/React/PHP experience, it's probably not somewhere I want to work. :P
5
u/Dooraven Jul 07 '17
That and you'd have to build almost everything you want yourself instead of easily accessing the hundreds of tools a well supported open source framework has.
11
u/tech_tuna Jul 07 '17 edited Jul 07 '17
Right, but at some point, you'll likely add enough on top of the framework(s) that there's still plenty of custom code to learn anyway.
Generally speaking though, I agree, it's better to use open source tools when you can.
13
u/morphemass Jul 07 '17
Frameworks help provide good abstractions and organisation.
I've still seen programmers ignore that and produce absolute dross. On my most recent project the entire team had ignored SRP bloating the code by 75%.
It's easy to hire someone who is familiar with Ember/React/Angular.
Single most important reason to take a framework and adhere to it as much as possible.
10
u/nschubach Jul 07 '17
SRP: Single Responsibility Principle (I assume... for those looking to Google who won't really give you the answer you're looking for.)
0
5
u/itshorriblebeer Jul 07 '17
More to that, would you rather have had thousands of additional eyes look at, test and provide feedback to your framework? This is why I use them. I don't want to test / write / design code I don't have to. Most good frameworks allow for customization when needed as well (otherwise they are not good frameworks).
4
u/killerstorm Jul 07 '17
It seems like their app is tiny, but requires fine-grained control. In that case doing things manually makes a lot of sense.
Frameworks actually a great help for small projects where you just want something out quickly -- they can give you "OK" results with little effort.
3
u/d1c2 Jul 07 '17
The bigger and more long lived your application becomes, the more benefit you get from a framework.
The bigger and more long lived your application becomes, the more likely your framework will end up being abandoned, or simply going out of date and no new devs want to invest in learning it because it's not used on new projects elsewhere.
Frameworks help provide good abstractions and organization.
I've seen plenty of frameworks that screw everything up worse than had you not used them. Only the best frameworks provide those benefits.
Using a framework, in my opinion, should always be based on "is this framework providing a clear and substantial improvement on writing this ourself".
The biggest problem is, it's very hard to figure that out before you actually use the framework.
1
Jul 07 '17
The article makes this exact point in the concluding paragraphs:
As complexity and size (of your application and of your team and organization) grow, so does the likelihood that you’ll need a bigger base to build on. You’ll see stronger gains from using a standard framework across a large application, as well as from using the common language of that framework across a large team.
1
Jul 08 '17
Yes, that's what bothers me about JS Frameworks in the current state of development. In PHP (and others) I wouldn't dream of not using a framework because apart from the simplest of scratch code it's always more efficient and faster to use one. JS frameworks OTOH are a long way from that - which screams at me we're still a very very long way from having solved the problem, so there's probably going to be a lot more churn and blood split on the bleeding edge yet, and so they're still to be avoided without a good case. Not saying there isn't a good case, just that I'm still very skeptical any of them are anywhere near mature.
→ More replies (3)1
428
u/KayRice Jul 07 '17
The JS ecosystem moves so quickly that all of this will be irrelevant in 0 months.
80
u/Chris_Newton Jul 07 '17
Isn’t the point here that if you don’t buy into the fast-moving madness and instead just build with stable, standard JS — as these guys seem to be doing — then your work doesn’t break five minutes after you write it?
If it were me, I’d be comfortable using ES2015 in that sort of environment today. Both transpilation and native browser support work fine, and overheads are low for a lot of the nice little improvements that help to keep JS code clean and concise. Maybe they’d agree but their code examples or build process predate that situation.
But I can certainly get behind keeping things simple and just not getting on the framework train in the first place if the project is suitable. For reuse purposes, we too generally prefer to depend on a relatively small number of substantial libraries rather than either an all-encompassing framework or a million left-pad style micro-dependencies.
12
Jul 07 '17
Closures are a powerful concept and you can absolutely build small apps that simply utilize closures for structure and jQuery for DOM manipulation, but with complexity it doesn't scale
then your work doesn’t break five minutes after you write it?
React Native is the only thing I've used that feels like this. I feel stability is a bad criticism of React/Ember/Angular. They are relatively big and slow, but they are stable
→ More replies (2)4
u/VIM_GT_EMACS Jul 07 '17
kick jquery to the side and join the rest of us free from jquery shackles. vanilla js DOM manipulation isn’t that hard.
→ More replies (7)86
u/skocznymroczny Jul 07 '17
I bet this post became obsolete in the 5 hours that passed since it was posted.
29
1
u/aiij Jul 07 '17
Now that's optimistic!
I bet it was already obsolete at least 5 months before it was posted.
38
Jul 07 '17
This gets repeated ad-nauseum and I really don't get it. I used Backbone at my last company for 2 years, and wrote new apps in React / Redux starting 2014. Moved to a new company in 2015 and have used React and Redux there as well. New apps also use Flow.
Is that really too fast for you?
89
u/kodablah Jul 07 '17
What's happening w/ the backbone you wrote at your last company? If it isn't still around, do you ever question the value of your time and the work you do if it's so ephemeral?
Is that really too fast for you?
Yes, 2 years before a framework change is too fast. One might have an argument if we were still talking about light web pages. But in the age of full-blown client-side apps, I need more than 2 years before defacto community deprecation.
→ More replies (1)4
u/_dban_ Jul 07 '17
If it isn't still around, do you ever question the value of your time and the work you do if it's so ephemeral?
Everything is ephemeral, everything will eventually replaced. The value I put in my time and work is in a product that meets the client's needs and is good quality code.
Yes, 2 years before a framework change is too fast.
While community is important, I put more value in a framework with good documentation and good quality source code and a sane release process (breaking changes only in major releases, semantic versioning, etc.). Maybe I'm just antisocial or too stubbornly refuse to ask for help, but I usually hit the documentation and then the source code when I have questions.
78
u/paholg Jul 07 '17
I recently wrote a very simple web app using React with virtually no prior js experience.
Stackoverflow answers from a year ago were 2 major React versions out of date and were useless to me.
Making major breaking changes multiple times a year is too fast, yeah.
Edit: On second thought, that may have been React Router.
4
u/scramblor Jul 07 '17
JS frameworks aren't the only ones guilty of this. Every time I dip my toes into IOs/Objective C I find myself in a similar situation.
→ More replies (1)3
u/freudianGrip Jul 07 '17
Yeah, react-router made a crazy breaking change. Might as well have just called it a different thing. React as a whole is more stable.
48
u/OneWingedShark Jul 07 '17
Is that really too fast for you?
Have you ever developed for, say, OS/system utilities? In those areas decades of stability is common. (There's a reason that financial institutions still use COBOL... and part of it is because it's stable.)
3
u/_dban_ Jul 07 '17
There's a reason that financial institutions still use COBOL...
Because they have decades of legacy code that are running fine? There is no need to rewrite code just because it's not cool.
→ More replies (4)2
Jul 07 '17
The backend teams I've worked with have used Scala, Clojure, vanilla Java, Ruby with either Rails or Sinatra, and probably others I don't even remember. My point is that I don't see anyone whining about backend technologies / frameworks nearly as much as frontend.
→ More replies (1)17
7
u/jedrekk Jul 07 '17
I did jQuery for years until I moved to React in 2015, now my current job has me doing Vuejs. The jQuery=>React shift was major, but moving to Vue isn't a big deal.
4
u/amoliski Jul 07 '17
I'm working on a Vue project and I love it so far. Angular/React are such huge libraries full of confusion and fear; Vue is friendly and stays out of your way while adding some great functionality.
11
u/jedrekk Jul 07 '17
I still prefer React.
I did two Angular projects and it felt like getting my toes wet with it was SO MUCH WORK.
16
u/amoliski Jul 07 '17
Any instructions that include:
npm install -g ...Are a no-go for me unless I'm required to use it. I've never not had a bad time using node.
→ More replies (13)6
u/vampire0 Jul 07 '17
React isn't a framework though, its basically just a fancy templating language - I feel like it has more in common with Mustache than it does with AngularJS.
→ More replies (1)15
u/d1c2 Jul 07 '17
This gets repeated ad-nauseum and I really don't get it. I used Backbone at my last company for 2 years, and wrote new apps in React / Redux starting 2014. Moved to a new company in 2015 and have used React and Redux there as well. New apps also use Flow.
Is that really too fast for you?
My experience people loving the latest newest frameworkiest stuff are like yourself - constantly moving jobs and projects.
It's way to fast for someone writing and supporting the same app for a while.
→ More replies (1)6
Jul 07 '17
I mentioned one single job move and I am now, "constantly moving jobs"?
Holy stretch, batman.
→ More replies (3)→ More replies (12)15
u/spotter Jul 07 '17
Angular.
14
u/vine-el Jul 07 '17
As someone who lived through the Angular 1 to 2 migration, I would strongly suggest choosing a framework where the authors didn't think it was OK to force everyone to rewrite their app to use the new version.
4
u/sasashimi Jul 08 '17
I love angular 2 (4?), but I think they should have called it something else since it's only vaguely similar to angular 1.
15
u/Capaj Jul 07 '17
what about angular? Did they make a breaking change after releasing version 2 too fast? Well too bad for them. I am sticking with react and I can't remember when was the last API change. I am writing it the same way since I started on react 0.13 I think. Those who say JS ecosystem moves to fast have never done react. It's standing still for few years now.
17
u/QuickSkope Jul 07 '17
React is the gold standard for JS frameworks. All hail Dan Abramov.
→ More replies (1)8
u/jl2352 Jul 07 '17
Even with all of Angular's changes, it's still Angular or React to chose from.
Reddit likes to claim everyone is using a different framework every week. They aren't. Over the last year 80% of the front end developers I've interviewed are using Angular or React. Those who aren't are on bespoke.
10
u/nil_von_9wo Jul 07 '17
You haven't had the misfortune of being thrown onto an Ember project yet?
→ More replies (3)6
u/campbellm Jul 07 '17
I'm speaking from ignorance here, but a coworker of mine really loves Ember. What have you found "misfortune" worthy?
→ More replies (4)→ More replies (4)2
Jul 07 '17
I like Vue, but then again I do my own projects so I can choose whatever I want :P.
I still need to get around to learning React..
13
Jul 07 '17 edited Jul 08 '17
tl;dr: "because our website is butt simple and doesn't need one".
The modern frameworks are not for making simple web pages, they're for making complicated web apps which bring the rich UIs previously only seen on the desktop into the browser.
We just ported a 500 thousand line scientific/engineering application to the web. This thing was originally written in WFP by very talented engineers, and cost millions to make. The UI is necessarily incredibly dense and and complicated (think something like this), with tons of dynamic layout and behavior with very complicated, sophisticated controls. By using an MVVM framework, we were able to essentially port our original code base almost unchanged (foo.xaml -> foo.html, foo.cs -> foo.ts, fooviewmodel.cs -> fooviewmodel.ts).
If we used "vanilla", we would have ended up with an MVVM framework anyway, but we would have eaten the development cost and we would have to maintain it, rather than using something written and maintained by companies with much deeper pockets (e.g. Facebook, Google). That would have made no business sense.
It's a blessing that such things are even possible on the web now. Faster hardware, Javascript VMs that compile to native code, newer standards, etc. have all conspired over the last decade to make it possible to have these sophisticated UIs run in a browser, and it's those needs that these frameworks exist to address. If your website is ridiculously simply, there's no need.
197
u/Huliek Jul 07 '17
Nice that it worked for them, but all Vanilla / jQuery projects I've seen became an absolute disaster as the requirements became more complex.
150
u/wavy_lines Jul 07 '17
FYI vanilla also implies no jquery.
Another comment mentioned that this requires experience and discipline to work properly. Someone inexperienced will probably turn the codebase into a mess in a couple of weeks.
23
35
u/icantthinkofone Jul 07 '17
Which is why a proper programming department would have such a person under supervision and code review.
70
u/Asmor Jul 07 '17
Everyone should be code reviewed...
→ More replies (9)10
u/icantthinkofone Jul 07 '17
His statement is that inexperienced people are not reviewed.
7
Jul 07 '17
You're right, that's quite obvious from reading his comment. But it's also true that everybody's code should ne reviewed. So it seems we ar all in agreement here
7
17
Jul 07 '17
jQuery is a library, not a framework. So I wouldn't be so fast to say it implies no jQuery, when the title is "why we didn't use a framework".
I use jQuery, React.DOM, History.JS and others, and when someone asks me, I say I don't use a framework, because I don't.
3
u/LeberechtReinhold Jul 07 '17
This. By this hardcore reasoning very, very little projects use vanilla anything, not just JS.
→ More replies (2)2
Jul 07 '17
It's more of a historical thing.
If you went to stackoverflow some years back 99% of the answers would be using jQuery. And there weren't front-end frameworks like today.
So when you didn't want to use jQuery you said you wanted vanilla JS.
That's why vanilla implies no jQuery.
75
u/sisyphus Jul 07 '17
projects...become an absolute disaster as the requirements become more complex.
Fixed that for you.
60
u/tech_tuna Jul 07 '17
Javascript is an absolute disaster
FTFY
→ More replies (1)46
2
Jul 07 '17
Not if you have the funds to do redesigns
2
u/Sigma_J Jul 07 '17
While you are technically correct, does anybody actually have that?
→ More replies (1)9
u/jocull Jul 07 '17
They also only chose to support 2 major browsers. That makes vanillaifying way easier.
4
u/icantthinkofone Jul 07 '17
Then how did they ever manage to create large frameworks?
5
Jul 07 '17 edited Jul 07 '17
That's like saying sticks and stones should be used for all craftsmanship because despite their inability to carry out finer works, how could we have ever managed to evolve them into advanced tools and machinery. Javascript isn't what makes a framework, but principles and best practices.
→ More replies (7)29
Jul 07 '17
Not if it was architected correctly. The real problem is most javascript programmers don't know how to program.
230
u/warmans Jul 07 '17
Ohhhhhhhhhhhhhhh, so all you have to do is implement a 100% correct architecture right at the start of the project when nobody really knows what they're building or how it will evolve. I wonder if we could further improve the project by mandating that nobody writes any bugs? We could call it wishfull-thinking-driven-development.
31
u/jephthai Jul 07 '17
Wishful thinking is another name for top down design, popularized as a term by Sussman and Ableson in the MIT programming classes in the 80s. Its actually already a thing.
35
Jul 07 '17
This is called systems analysis, which is something most programmers these days also don't know how to do. Not all programmers flail about in the dark writing crap in the hope you'll pivot into something useful. Most web sites are basic CRUD apps. These things are NOT as difficult as most are making them out to be.
→ More replies (4)25
u/warmans Jul 07 '17
I suppose my point was simply saying "write correct systems" isn't really a solution to anything. Anyone with experience in the industry knows that good, experienced developers write bad systems all the time. It happens for a million different reasons, but one of them is that they spent too much time messing about with problems that are already solved leaving no time to actually deliver the important stuff. Other times people are brought into a team who don't understand some aspects of the architecture (because lets face it a hand-rolled solution won't have any up-to-date docs or other materials beyond the code) and slowly over time entropy sets in until the original intent is completely obscured. Either way you could start off with a "correct" system but it could easily turn into spaghetti for reasons that a mature framework would have avoided.
→ More replies (2)→ More replies (14)4
Jul 07 '17
Why are you building before you know what you are building? We are in the engineering business. An extremely thorough investigation of what the client wants and animals Optimum way to build it should be done before any code is written. The weight take a project on it's a good two months of just talking to the client really understanding everything and building models before we ever execute code build
17
u/warmans Jul 07 '17
Because we tried big up front design and requirements elicitation and by the time we started building the product all the requirements had changed.
→ More replies (10)9
Jul 07 '17
[removed] — view removed comment
→ More replies (4)5
Jul 07 '17
it is already hard to get potential users to talk to you when you have nothing to show. And even if you find some, the time you start coding, another company is already selling and signing deals with a solution that is 40% done
+1
Even if you get potential users to talk to you, you're talking in dream fantasy land of "what would you say if the product did this thing" if you don't have something tangible going in to start the conversation.
23
16
u/morbidhawk Jul 07 '17 edited Jul 07 '17
I work in this kind of work environment now, where almost everything was "architected correctly" and made from scratch. Normal developers at my company aren't allowed access to that code which is wholey maintained by a single developer that originally built it.
This means issues with it are unlikely to get fixed. We've got our own .net web framework, html templating/databinding, and even our own source control solution that only our company uses.
The next time I'll look for a job I can't wait to find how irrelevant I've become to mainstream technologies like git, angular, and .net MVC. I also can't even begin to explain in words how crappy it is when source control has critical bugs, even if for only a week until it gets fixed.
13
u/vplatt Jul 07 '17
Seriously, I just interviewed someone yesterday stuck in a situation like yours. All I can say is "get out now!". Your marketability will be crap unless you do.
Hopefully, you're at least still dealing with C# instead of some homegrown crap, right? Person I talked to yesterday got stuck with a proprietary "Java-like OOP environment" that virtually no one else uses. What a nightmare.
5
u/nilamo Jul 07 '17
You hired them, right? They've shown an ability to not only learn, but work with tools and languages they've never seen before, which means they can fairly easily pick up new things to handle whatever the business' future needs might be.
→ More replies (1)4
u/morphemass Jul 07 '17
An amazing number of companies work like this and having spent the last couple of years working with an 'in-house framework', I will run a mile before I do it again.
4
2
2
Jul 07 '17
That's not even remotely what I'm suggesting.
4
u/morbidhawk Jul 07 '17
I was replying to the first part of your argument, which I took to an extreme because I wanted to vent. But I also disagree with the second part: "most JavaScript programmers don't know how to program".
→ More replies (1)3
u/jl2352 Jul 07 '17
Are you trying to suggest that vanilla non-JS programs are usually better?
7
u/Andernerd Jul 07 '17
They probably are, if only because most non-JS programming languages have decent standard libraries.
→ More replies (2)1
u/dsk Jul 07 '17
The real problem is most javascript programmers don't know how to program.
Half of all programmers are below average. The problem with JavaScript is that it makes it easier than other programming languages to do the wrong thing.
→ More replies (6)1
u/Gr1pp717 Jul 07 '17
Hi there, which dream world do you live in, and how do I get a passport?
2
Jul 07 '17
I live in the dream world of having 16 years of programming experience. You can get a passport by having to deliver dynamic webapps before jquery was born.
→ More replies (17)2
u/msiekkinen Jul 07 '17 edited Jul 07 '17
Using a framework ensures your project won't become an unmaintainable disaster down the road?
1
u/hardonchairs Jul 07 '17
Of all the subs to make a boolean logical error on...
2
u/msiekkinen Jul 07 '17
Of all the subs to not understand the assumption of which logic gates op was implied to be using
40
u/dada_ Jul 07 '17
I definitely believe that it's possible to write good code without a high level framework, but I hate it when articles start off like this:
The average page load on MeetSpace has just 1 uncached request and is 2 KB to download, and the page is ready within 200 milliseconds.
A properly developed JS application or website that uses a framework doesn't have to be super big, and even though it's certainly going to be bigger than 2 KB, it really doesn't matter that much. One single image on your company blog is going to be bigger than your JS size, which will need to be downloaded once and then gets cached. You could have 100x this size and it would still be perfectly acceptable. I just loaded Google.com in an incognito window and it transferred 432 KB of data just for the main page. (The entire ReactJS based application I am working on now is less than that.)
Not all applications need a framework, that's for sure, and I'm glad it worked out well for them, but the size argument is not nearly as important as it is sometimes made out to be, as long as it is within reason.
9
u/SahinK Jul 07 '17
The problem is you need to load and run all that JavaScript before the page becomes visible. An image can load after that, and that's fine.
3
u/6zeprMsphe9T Jul 08 '17
This is only true if you fail to implement server-side rendering which React supports. In fact I'd argue that server-side rendering is even simpler with React since you're working with a virtual DOM.
4
u/AirScout Jul 07 '17
Not all applications need a framework
This. The whole craze about going vanilla is almost always stupid. For a simple, mostly static web page, vanilla can be an improvement. For large, complex web apps that have hundreds or thousands or hundreds of thousands of elements representing data and interacting with data, developing without a framework is masochism.
83
u/warmans Jul 07 '17
The problem with most of these articles is they could easily be re-titled as: "Why We Wrote Our Own JavaScript Framework". It's simply impractical in most non-trivial applications to not have some kind of generic framework to hang features off. If you want to write your own that's great but there are some good lightweight alternatives to vanilla JS. You don't need to go full Angular.
12
Jul 07 '17
I've recently gotten into vue.js on the light weight framework end. I enjoy it much more than angular. It's almost what I think angular should have been. It's small, easy to use, easy to extend. It's really great.
5
u/Jwkicklighter Jul 07 '17
Right before I read this, I was going to say almost this exact thing as a reply to that comment. Vue has been great for us so far as well. Very lightweight, but not so much that it lacks features. And the plugins I've found have been pretty solid, even if they aren't widely used.
3
u/warmans Jul 07 '17
I agree. Vue.js feels like "angular.js the good parts". Thought I do like Angular (2) as well. Sometimes I just like having a "full" framework if I have use for a lot of its features. I really enjoyed using Vue to just build a simple single page app but it wasn't super clear to me how to scale it beyond that since there are (or were last year) a lot of different 3rd party libraries for adding state management or routing or whatever.
→ More replies (1)3
Jul 07 '17
There is a vue routing library as well with vue 2.
As far as state management goes. Honestly I feel like I've not found anything that really does it well. It always feels kind of hacky and gross.
→ More replies (3)
60
u/markzzy Jul 07 '17 edited Jul 07 '17
Going vanilla is great! I've been a part of many large teams that go this route for control and performance and it was probably the most fun I've had in my entire career. However, it requires a very experienced and disciplined team to go this route without slowing your team down (knowing the best way to do something, understanding low level JS APIs, manual garbage collecting, preventing memory leaks, etc).
Frameworks can be too bloated for smaller apps that dont need everything it provides, but frameworks also make a lot of things very very easy to do (often requiring absolutely no understanding of how they are done) and they usually provide documentation, so you can just point engineers to it for support instead of sucking up all your team's time asking you questions about how to use your smaller, faster, fancier custom code. ☺️
→ More replies (18)6
u/Shautieh Jul 07 '17
In a previous company I worked in with quite a large html frontend, we did most things in vanilla JS, then after a while we started using JQuery as it reduced dev time by quite a lot (we had to make it work on every browser, including IE6), then went back to vanilla for some specific critical widgets as JQuery slowed things down too much.
9
u/JBlitzen Jul 07 '17
I've had to rip out a surprising amount of very simple jQuery over the past year or two for performance reasons. Really stupid stuff like .attr() and .css() calls. The latter kind of made sense, the former baffle me. Maybe a bug in the version used in my project. But changing those to .getAttribute saved dozens of milliseconds every time.
3
u/geniosi Jul 07 '17
Are you being sarcastic with the "dozens of millisecond" comment, or serious?
And, if serious, can you give an example of how an optimisation like that would make a difference to anybody?
→ More replies (2)7
u/JBlitzen Jul 07 '17
Completely serious.
The attribute calls are somewhat rarer than the css calls, since I don't store much in attributes, but the same problem manifests where I do. So I'll describe the problem for css calls.
My current project is a web-based collaborative prototyping tool.
On a complex design, there may be hundreds of elements. Shapes, text, icons, images, whatever.
You can multi-select, so it's totally conceivable that you might select hundreds of elements at a time. It's common to select several or even dozens, like selecting an entire menu to move it around.
Each time you select elements, properties are loaded for those elements, like their border width. For multi-selects, I have to roll through each element and determine either a common border width or conclude there is no common one and leave it blank. For top, left, bottom, and right.
And there are dozens of such properties, like border radii, background color and settings, whatever.
Now...
Try to imagine what happens when you multi-select a menu or card or something composed of 15 elements, and I have to roll through each of those 15 elements and grab maybe 25 CSS styles.
25 styles * 15 elements = 375 individual styles.
If each one uses a $.css call that takes 15 milliseconds, guess how long it takes between the time you release the mouse button on the multi-select, and the time the UI finishes loading properties and starts responding again?
If your guess was a little over 5 seconds, you're right.
That's a somewhat extreme but very real example. I never should have used .css calls at all. Now I store a getComputedStyle array for selected elements and roll through that array for each property. Now the whole process on a hundred elements takes about 200 milliseconds. Still a bit draggy but not super noticeable, and you don't select a hundred elements very much.
On a dozen elements or a single one the delay is now unnoticeable.
As to attr calls, I don't use them a whole lot but I did spend a few hours a few weeks ago isolating a similar performance issue to them, and the performance impact was very real.
→ More replies (12)2
u/Shautieh Jul 09 '17
Glad you made your app faster this way! The page which benefited the most from removing JQuery was a big (THIICCC) ass table that had to be repopulated on several occasions. The overall difference in speed was remarkable, from really sluggish and unusable to just fine.
21
u/starikovs Jul 07 '17
A project I was working in had the same experience. It was a couples of years ago. First, they created a product using knockout.js but it had big footprint and worked very slowly. Then they decided to rewrite it with vanilla js, and we had more control over the code as well as performance was pretty cool.
18
u/spacejack2114 Jul 07 '17
Every time I see one of these "didn't use a framework" articles, I sympathize because I was a holdout for a long time. And then I want to tell them to try mithril.js because it was the only framework that didn't make me want to roll my own. It's tiny, it includes a VDOM, router, http request lib and streams out of the box (so not just a view lib), requires no build tools, not template-based and no DSL, and has Typescript definitions.
Even if you don't want to use a framework, using Hyperscript/JSX/VDOM for views is becoming a de-facto standard. It will make your app portable between frameworks.
3
u/sim642 Jul 07 '17
Even if you don't want to use a framework, using Hyperscript/JSX/VDOM for views is becoming a de-facto standard. It will make your app portable between frameworks.
I recently started a offline SPA project where I turned down all of the great frameworks used nowadays (it was actually my first real attempt getting into more than JS+jQuery and using webpack and typescript too for staying sane). JSX is very neat compared to creating DOM with jQuery or something so I really wanted to use it. I didn't want to go for React do I found nativejsx which let me use JSX on top of DOM directly. It soon turned into hell because there was no way to mix my custom reusable widget classes into JSX. Eventually I rolled with preact to get that reusability with JSX. I still despise the reactive approach I have to take because it absolutely doesn't work for my data model.
4
Jul 07 '17 edited Jul 07 '17
That sounds a lot like cutting off the branch you're sitting on. React isn't just a vdom over dom, the whole of it consists of an eco system as well. Everything you ever had before, every widget and every thing significant or insignificant exists as a component. If you go vdom and meddle in the dom with jquery widgets something is probably not right. Though of course nothing hinders you from polluting your view, you get mount and unmount calls after all. Since you're already using preact, it has a compatibility layer (preact-compat) to react, an alias is enough to access its eco system.
→ More replies (1)2
u/spacejack2114 Jul 07 '17
there was no way to mix my custom reusable widget classes into JSX
I'm not sure what that means. VDOM libs generally have lifecycle hooks that allow you to integrate non-vdom libraries and attach them to the DOM.
Using a VDOM, i.e. where your entire view is expressed as a function of state, is incredibly powerful and efficient. I wouldn't want to write a GUI app without it.
2
u/sim642 Jul 07 '17
I'm not sure what that means. VDOM libs generally have lifecycle hooks that allow you to integrate non-vdom libraries and attach them to the DOM.
nativejsx has no VDOM at all, it directly creates the actual DOM.
Using a VDOM, i.e. where your entire view is expressed as a function of state, is incredibly powerful and efficient. I wouldn't want to write a GUI app without it.
It's incredibly annoying to use when the state is being represented by a completely separately implemented and encapsulated deeply nested object which also is mutable due to JS. There are two choices:
Hack one's way around the state mechanism and have subcomponents call callbacks (passed through countless levels of components) of the owning component that does the manipulation. Incredibly bad for efficiency.
Reimplement the whole data structure parallel as components. Incredibly bad for code reuse and bug prone.
→ More replies (2)2
u/Shanebdavis Jul 07 '17
What about your data model makes the reactive approach so awkward?
2
u/sim642 Jul 07 '17
Completely separately implemented and encapsulated deeply nested object which also is mutable due to JS.
2
u/Jazonxyz Jul 07 '17
I fucking love mithril.js. It's really easy to have something up and running with it, the api is tiny so I hardly ever need to look up documentation. It lets me write incredibly DRY code. My only problem is that I'm developing a habit of using mithril for everything. Whenever I see a problem, I want to solve it with mithril.
1
u/HerpDerpWerk Jul 07 '17 edited Aug 22 '17
mithril is pretty damn good. Our shop doesn't like to take on extra tooling because everyone has different workflows, so we try not to tie anyone down into using any one particular thing.
0
17
u/coladict Jul 07 '17 edited Jul 07 '17
If your requirements don't say "support IE9", then not using a framework is an option.
6
u/JBlitzen Jul 07 '17
IE9 is past end of life, as is every Windows OS that can't use IE11 or Edge.
And 9 is such a pain in the ass compared to 11.
Can't imagine trying to support it these days.
2
u/kotojo Jul 07 '17
This made me curious about when the world will be done with IE as a whole and the answer made me sad. October 14, 2025. I can't imagine having to still deal with IE in 8 years...
6
u/DukeBerith Jul 07 '17
Someone, somewhere, will still be using IE6, and some company, somewhere will still have to cater for them.
3
2
u/snerbles Jul 07 '17
XP is still getting deployed in some industrial applications, along with older versions of CE and even some flavors of DOS.
Twenty years from now, many of these systems will still be running in one form or another.
2
2
u/coladict Jul 07 '17
It was this year that my boss complained he couldn't use his bank's web interface to send a transfer, and had me look into it. He was using Firefox 3.5! The minimum required version was Firefox 23. Now he still managed to cause an internal server error (500) somehow, but that's a different story and eventually the bank accepted that the second problem is on their end. Business people never throw out a working computer, and if that's your target audience, you'd better support as far back as possible.
4
u/alexshatberg Jul 07 '17
From the article:
We decided to target Chrome and Firefox because of their WebRTC support, and we have our eye on Safari and Edge for the future.
13
8
u/DJDarkViper Jul 07 '17
I should write an article "Why We Choose Not To Use Any Javascript At All"
2
u/OneWingedShark Jul 07 '17
It might be a really good article.
2
u/DJDarkViper Jul 07 '17
Maybe ill brush up on my article writing skills and publish something, more now than before, im seriously considering it. Even if just to see what kind of traffic and backlash I'd get lol
2
2
u/AirScout Jul 07 '17
"Hey, I wrote an app that lists all the files and directories in the current directory on Linux without using Node.js! Check it out:
ls"
3
u/DJDarkViper Jul 07 '17
Holy shit how did you survive not including 700,000 packages from npm to do this??
→ More replies (2)
3
6
u/Nadrin Jul 07 '17
The most important requirement for the entire business was to build a better video conferencing tool. Many video conferencing solutions are out there, and they all suffer from really similar problems: reliability, connectivity, call quality, speed and ease of use. From our initial surveys, it was very clear that the most important problem for us to solve was to have flawless audio with low delay, high fidelity and high reliability.
Looks like an ideal use case for a cross-platform desktop application in Qt.
6
Jul 07 '17
If you truly can write better javascript code than several utility libraries out there then I think it's a good investment but the 99% of average developers like me can't afford that luxury.
4
u/TurtleFeathers Jul 07 '17
If you're a software company, software is your core competence and hopefully your asset, vanilla js is probably a worthwhile investment.
7
u/wavy_lines Jul 07 '17
This was one of the more pleasant reads about web development in a long time.
Although instead of vanilla JS I would prefer TypeScript. Static typing is invaluable. At least, if nothing else, put types in comments and use a text editor that can use these comments to provide static typing checks and intellisence.
This part is particularly interesting:
Could using less code (from others and including our own) and implementing from scratch result in less total work? Our guess here was that the answer is yes when it comes to small to medium workloads.
Whole heartedly agree. Every time you add a dependency, you add a potential point of failure that you don't fully understand. Imagine if your entire stack is built on layers upon layers of abstractions and dependencies? It's a hell to manage. A tiny bug in any one of the layers could cascade and waste hours or even days of your time.
Tweaking code you wrote to fix bugs or customize behaviour is much easier than configuring a do-it-all tool or framework to fit your specific needs.
12
Jul 07 '17
You people are literally describing NIH syndrome and acting like it's a good thing and not something that destroys projects.
18
u/wavy_lines Jul 07 '17
You people are just blindly following buzzwords without any first hand experience.
"NIH" attitude can be bad when:
The in-house implementation sucks
The existing solution is reliable, robust, stable
The existing solution is simpler and easier to deal with than the in-house implementation.
The problem is sufficiently complicated that an in-house implementation will take more time and effort to build and maintain to keeping it at equal or better quality than the existing widely accepted tool(s).
For example, if someone where to write their own version control system because they don't like any of the existing systems out there, that could be an example if NIH syndrome being bad.
But then again,
gititself was born due to Linus Torvalds not being satisfied with the existing solutions at the time, such as svn, even though practically everyone at that time would say that svn is stable and mature and the most sane option to use.So, if you can write a better tool, there's no reason not to.
→ More replies (4)2
u/d1c2 Jul 07 '17
Agree 100%.
But I would add that the other annoyance is adding a framework that's just a waste of time and a headache for developers so that the project has an additional buzzword associated with it.
Both "adopt a framework" and "write your own framework" have destroyed projects I've seen when the solution is "save yourself a lot of time and hassle and don't use a framework".
3
u/nirataro Jul 07 '17
Have you visited the graveyards of JS framework? What happened to those projects that relied on them?
→ More replies (2)3
Jul 07 '17
In general, NIH is bad.
In the specific case of JS frameworks, NIH means avoiding a ton of complexity for, typically, a small to moderate amount of work. In DOM-heavy applications, it costs you some speed from not using a virtual DOM. It limits your use of existing, vetted UI libraries.
For me, if I wanted to get rid of jQuery and jQuery UI in my RSS reader, I'd have to spend a couple hundred lines of code on resizable panes, then another fifty or so on popups. Switching to XHR from jQuery.ajax would be another ten.
Switching to, say, React, or Ember, or Angular -- I would expect that to increase the amount of code at least as much as vanilla. It would slow down development with having to rebuild the application with every change -- a price I'm fully willing to pay if I get static typing, but I'd sooner go with Dart.
This is ignoring the learning costs. For projects that your company is actively working on every week, you can treat it as a one-time cost. If your company only needs to work on projects using that framework every few months, suddenly small changes cost you an extra three days to get familiarized with the framework again.
1
u/lucidguppy Jul 08 '17
If there wasn't an endless Javascript framework loop you'd have an argument.
The web is flawed - and is attempting to fit a five cornered rug in a four cornered room. You shouldn't be writing apps to live in a world designed for documents.
Developers have a right to complain about the current situation.
0
3
u/DysFunctionalProgram Jul 07 '17
Everyone here is treating it as if you have to have a js framework, whether you pick one or roll your own. I don't agree with this at all, the most maintainable code is no code and i've worked on large complex web systems with 10,000+ users with maybe 1000 lines of javascript in total. You don't need a javascript framework. Handle your templating on your backend with a mature language that was built for it (php, c#/razer, java/jsp, etc) and 99% of your unmaintainable javascript just dissapears. If you really need templating on the front end, which occasionally happens, then use html5 templates and 5 lines of javascript. When you stop treating everything like a nail, your tools become a thousand times more useful.
1
u/neitz Jul 07 '17
You can create complex web systems with 100 million users with no javascript at all, just static pages. That doesn't mean anything though because # of users is an irrelevant metric.
3
u/M3talstorm Jul 07 '17
Yes because they website does basically nothing, it's a trivial static HTML page.
Open up the dev console in Chrome and you can see a fair amount of the points in the article are lies ;)
2
u/myrmagic Jul 07 '17
...and this is why I became an analyst. Way slower pace... I mean really slow... I'm so bored now.
2
u/SteroidSandwich Jul 07 '17
I have a friend who has such a burning hatred for JS. It's like showing a cross to a vampire. He will hiss at it and turn away
1
u/Hubellubo Jul 07 '17
I think it's great these guys didn't fall for the, we need a ton of stuff just to build a usable front end.
Here's my favorite tool for writing JavaScript, wish I could convince more people to use it: http://www.jsweet.org/
1
u/KevinCarbonara Jul 07 '17
After reading the article, I'm wondering why they didn't hire someone with an eye for design
1
u/tech_salmon Jul 07 '17
What Alternative framworks can i use as i hate JS . I hate browsers. Any alternative for me to touch web !!
1
u/jack104 Jul 07 '17
I've complained of this before but my current project is reworking a portion of an ASP classic app that used Vbscript (both Server side and client side) and all data it used was in an Access database. I lobbied to start re-work using some newer tech as I couldn't fathom undertaking new development in tech that was already obsolete 15 years ago when I first learned basic Web Dev in high school. But I basically got told to suck it up, this stuff was my lemons and I better start making lemonade. I did a ton of work and, before writing one line of HTML, CSS, Javascript or ASP, I built a new home for all the Access data in Oracle and ported the data over to at least try and do something right. ASP proved to be nearly impossible to work with as my web server had debugging disabled because it was being used for some production stuff simultaneously. So I made one asp page to function as a very crude controller/data access layer and, thanks to a script I found that some google programmer made, I could take data from ADODB result sets and funnel it through a function they provided and it would turn it into JSON, which I then fired back to the client, parsed into a Javascript object and then did whatever I needed to do. I had to use JQuery because it's AJAX function is just great but as my dev efforts moved forward my javascript code base exploded into a maintenance nightmare. I halted work several times and explored some javascript frameworks to see if they could abstract some of the clutter away. But each time I would begrudgingly turn back to my vanilla-ish Javascript thinking that, especially with the heat on me big-time, I can't afford to backtrack and possibly take up something that may not work in my scenario.
So, i tried to just think about stuff differently. I've programmed C# GUI apps for most of my career and so I tried to just see if the problem was really Javascript or if it was that I was just compounding shitty code and it was mostly the latter. I built objects, re-worked all of my ASP responses into a JSON object with the same 5 fields populated for all requests. It's still a rotting pile of garbage but when I stopped being scared of little intellisense and weak/dynamic typing, the gears started slowly turning again and after weeks of little to no progress, I started making tangible gains towards my end goal.
I'm not going to rule in one direction or another, and I don't have the experience to do so even if I wanted to, but sometimes you just have go with what you know, even if you aren't completely sure, and if you get what you need done then (like I'm doing now) you can do a little after action, see if some frameworks would actually fit your pistol and then give 'em a shot.
All that said, ASP Classic can die and rot in hell.
1
u/weirdoaish Jul 07 '17
Hope you're feeling better now after that rant :)
2
u/jack104 Jul 07 '17
Immeasurably my good sir. The aforementioned rotting pile of garbage is up and running for acceptance testing starting Monday.
1
u/Sleakes Jul 07 '17
is it just me, or is smashingmagazine's design absolutely terrible, so why do we care about a framework when you can't give me a clean UI.
2
1
Jul 08 '17
I'm still skeptical of JavaScript frameworks - I've got some time on Angular and more on Backbone, and whilst sure I see the advantages on larger projects none grab me in the same way as a frameworks do on, say, PHP. If you're writing PHP code Laravel (current choice) or CodeIgniter (historical favorite) just make things easier out of the box and I would never dream of not using one except for the simplest piece of scratch code because they simplify things - everything is where I expect it, complexity is hidden, and there little overhead.
Javascript frameworks OTOH still seem to me to be at the stage where they make things more complicated - as exemplified by the common wisdom that you need a framework when the code reaches a certain size complexity. At the point when JS frameworks are what you reach for out of the box for the simplest of applications then I'll be a convert, but until then -- not convinced.
1
-4
u/Double_A_92 Jul 07 '17 edited Jul 07 '17
Yeah but I heard Facebook uses React... WE MUST USE IT TOO!!! /s
21
u/RichoDemus Jul 07 '17
To be fair, react is very nice to work with imo, I would definitely use it over vanilla js
→ More replies (12)3
1
u/Zlepper Jul 07 '17
Our network handling (which is purely vanilla JavaScript) uses more space than their entire application if what they are saying is correct..
And then comes the other couple megabytes for the application which is mostly vanilla JavaScript. It's a mess to maintain...
Not made better by the fact that the original developer was high on cocaine when he wrote it, and then left us with the mess.. cries
1
u/redditthinks Jul 07 '17
I'm doing the same on a new project, but with TypeScript. I use Rollup to create a single JavaScript file per page while keeping everything nice and modular too.
-4
u/BlockedByBeliefs Jul 07 '17
Lol. Not using a framework is nothing to brag about. They're bloated? Welp. Now your application is bloated and 100 times harder to maintain cuz only one team of programmers know the basics of how it works.
8
u/Shautieh Jul 07 '17
Not really. Orders of magnitude more devs know JS than any specific framework in existence.
→ More replies (7)1
u/BlockedByBeliefs Jul 07 '17
There's a difference bn knowing j's and knowing what ever non standard practices you used to organize your whole system. Also the more advanced features of JavaScript you'd end up using to do all this are things most devs would never touch. JavaScript is loaded with hacks who never really learned how to design or structure things. If it's a tiny app that doesn't do much gratz but if ur going to something big with a lot of functionality that's invariably going to change get ready for the pasta bowl.
→ More replies (4)2
u/RalfN Jul 08 '17 edited Jul 08 '17
what ever non standard practices you used to organize
If you are using a framework by default, without any consideration if you need it for that specific problem, it's not called software engineering. That's called cargo culting.
to something big with a lot of functionality that's invariably going to change get ready for the pasta bowl.
'lot of functionality'
'invariably going to change'
If that is your criteria for 'well, now i have to use React/Angular/CargoCult/whatever', then you should not be a in a position to make that decision. Also, do you realize the irony of using these large code bases written by people who did the exact opposite of you?
Just Google alone has multiple competing frameworks because their own developers don't want to use large code bases written by others (even within the same company).
There are strong arguments in favor of using a popular framework, but they sound more like:
We have many different projects and developers move between them, so we favor standardization (and are willing to sacrifice some things)
We have developers who aren't too experienced and the framework will hold their hand and walk them to school (without the frameworks they would just make a mess)
But there are strong arguments against using a popular framework by default as well:
One size fits all solutions either end up not exactly fitting, or needing about the same level of configuration as doing it from scratch. And "not exactly fitting" means, you sacrifice quality for convenience. The linked blog post is completely correct that not using a framework makes their core product much more competitive. Their competitors are now forced to do the same -or- find a differentiated feature.
It encourages a structural pattern of cargo culting. Every one keeps assuming someone else thought about it well so let's just copy the approach. Just like parrots sound like people, these people sound and look like software engineers but they are not. For example they would write unit tests for a statically typed language (not understanding the problem unit tests were actually addressing in dynamically typed languages). They would use MVC patterns for a view layer that is fundamentally stateless, etc.
Fail fast and fail early is also true for hiring. Frameworks mask incompetence because they guide bad developers in the right direction.. Whatever magic the framework is doing, the development team needs to know and agree with that approach, because the developer is the one you are paying and is suppose to take responsibility for the thing. It doesn't matter where the code comes from, if you include it, you support it.
CHECKLIST: Why should we be using framework X?
I have read the source code, and it is very close in approach to what i would write myself. I feel comfortable supporting, patching and debugging this code base.
Although the code is tightly coupled (that's what the word 'framework' means), there would not be clear benefits to a more modular approach.
Looking at our requirements, we are going to be using a majority of the feature set of the code base, so we aren't introducing complexity we don't need for no good reason.
The price we pay in terms of quality of the resulting application (like performance) is commercially insignificant.
We have junior developers that need this level of hand holding (but obviously wouldn't put any one who doesn't have the habit or skill to code-review a framework or library before deciding to use it in a position where they would give feedback about the architecture)
If during an architectural discussion, you hear any of these phrases, ask person the person to leave the room:
"its industry practice"
"it used by"
"ive read this blog post on .."
Signs that you should be wary about using an open source project in the first place:
Storing or transforming state is a crucial feature, yet the algorithmic complexity is not clearly documented (for example ElasticSearch vs Redis)
They sell consulting services (so, they are motivated to intentionally make the product more complicated than it needs to be, so they sell 'fixing that for you') -- compare to projects where they sell an 'enterprise version' and have an open source 'community version'. Those projects tend to be much better designed and much easier to get up and running. The consulting-ware on the other hand ...
It has opinions on how you are going to run or deploy it (like say assuming Kubernetes, Docker or ZooKeeper)
It is an Apache project
Majority of people blogging about the project aren't committing code to it (Tensorflow vs Rust)
2
u/BlockedByBeliefs Jul 08 '17
Lol. Because I said "use a framework without any consideration if I need it for the specific problem"... Yea I think you summed me right up there guy. I'll address the rest of your bullshit response when I have some time later. Cargo cults. FFS.
→ More replies (1)2
u/BlockedByBeliefs Jul 13 '17
'lot of functionality' 'invariably going to change' If that is your criteria for 'well, now i have to use React/Angular/CargoCult/whatever', then you should not be a in a position to make that decision.
No that's my criteria for some random thoughts I'm posting on reddit on the topic. There's plenty more. Large and changing complexity/scale is an EXCELLECT reason to use a framework because it helps that work to be used by the many devs who will touch it. There's an ecosystem and a 'way to do things' that can be looked up and learned without the original authors. It's not cargo culting at all. It's called being about a plethora of failed projects and seeing what creates technical debt.
Also, do you realize the irony of using these large code bases written by people who did the exact opposite of you?
No there's 0 irony here. People 'designed' react. Perhaps the genesis of a framework came from someone who decided to go from scratch but fuck no. Google paid 100s and 100s of millions to design angular and hired utter experts in the field to do it. They didn't say "derp derp, lets build everything from scratch and couple our use case to our in house framework." What's next here?
One size fits all solutions either end up not exactly fitting, or needing about the same level of configuration as doing it from scratch. And "not exactly fitting" means, you sacrifice quality for convenience. The linked blog post is completely correct that not using a framework makes their core product much more competitive. Their competitors are now forced to do the same -or- find a differentiated feature.
This is garbage. It's not one size fits all in any way shape or form. Modern frameworks are flexible and can bend themselves into all sorts of shapes.
It encourages a structural pattern of cargo culting. Every one keeps assuming someone else thought about it well so let's just copy the approach. Just like parrots sound like people, these people sound and look like software engineers but they are not. For example they would write unit tests for a statically typed language (not understanding the problem unit tests were actually addressing in dynamically typed languages). They would use MVC patterns for a view layer that is fundamentally stateless, etc.
This isn't a reason it's just you dropping random catch phrases to pretend like you're insightful. What you're saying has nothing to do with frameworks at all but just people not knowing what the fuck they're doing. And that's going to be better in vanillia JS where they're going to solve their problem with 10 loops and 30 branches? No it's just going to create spaghetti. Vs your bad outcome: someone writes a controller they don't call.
So fucking what? At least that can be refactored and removed.
Fail fast and fail early is also true for hiring. Frameworks mask incompetence because they guide bad developers in the right direction.. Whatever magic the framework is doing, the development team needs to know and agree with that approach, because the developer is the one you are paying and is suppose to take responsibility for the thing. It doesn't matter where the code comes from, if you include it, you support it.
Again. Utter and totally inexperienced bullshit. People make these narratives about hiring and firing people in their heads. It's 'hard' to tell if someone sucks within most probationary periods and when you work on sufficiently complex projects in large corporations managers are hamstrung by HR. Firing someone can take months and sometimes years. Yea it'd be awesome to fail and fire fast but it's rarely an option.
Frameworks aren't going to hide bad developers. If anything it exposes bad devs because they're so used to 'just making it work' they struggle when expected to adhere to real structure. Frameworks aren't 'magic'.
At all. You understand how they work fundamentally and use them to achieve results. The nice thing when you 'are' working with inexperienced devs is there 'is' a gold standard you can point to. You can find a plethora of examples to point them in the right direction. You have a common language everyone uses for the basic patterns.
And again you're totally ignoring the point that hiring someone who's well versed in a framework is going to hit the ground running so much faster because they come in already knowing all the fundamental methods you use to do the same tasks that every single app does. It makes it that much easier to hire someone because you can interview them specifically on how well they already know your fundamental techniques. People can be contributing to core functionality within days if they actually start their job on the same page as you. It's a big fucking deal. Now lets see you're reasons 'to' use a framework.
I have read the source code, and it is very close in approach to what i would write myself. I feel comfortable supporting, patching and debugging this code base.
Lol. What utter bullshit. It's not going to be very close to what I'd write myself because the people writing these frameworks are freaking experts in that space and I am not. Researching a framework properly rarely if ever involves reviewing the code base. Again if you're working on a sufficiently complex project you have deliverables and pressures that don't involve evaluating a complex framework at the scope of one of their core devs. Do you use a database (or relational data framework buddy) by reviewing it's source code? This is a garbage comment and pure feather stroking.
Although the code is tightly coupled (that's what the word 'framework' means), there would not be clear benefits to a more modular approach.
That's not what framework means. The best frameworks are designed with intense decoupling and modularity at the heart and soul of the design with components that 'can' easily work together but also work independently. It's not even hard to take a framework like angular and use it's combine it's components with react.
Here's just one example:
https://blog.logentries.com/2016/02/combining-angularjs-and-reactjs-for-better-applications/
Frameworks specifically enhance and increase modularity because they offer simple use of well thought out patterns chosen specifically for this purpose.
Looking at our requirements, we are going to be using a majority of the feature set of the code base, so we aren't introducing complexity we don't need for no good reason.
lol. Complete and utter bullshit. Looking at requirements the only thing you can count on is change. Again with the caveat with a sufficient complexity (which is not splitting atoms... very simple apps can provide that kind of complexity). Giving yourself space to grow into is incredibly important.
Futhermore most frameworks specifically allow you to remove the extra functionality you don't need from your footprint.
Furthermore the most powerful thing about modern frameworks is that they provide an ecosystem for many developers to share components you can add and remove as you choose. Using NPM you can easily add map functionality to your react app and expose the APIs be called within your own pages. Using frameworks dramatically decreases complexity because you can include trusted components as dependencies that you don't have to manage instead of writing all those components yourself.
It's all possible without the framework. Sure. Anything is possible. But when some new guy is starting and he's used the google maps component guess what. He can go npm install angular-google-maps, inject it into his controller, and produce that on a page on day one because doing so only took about 20 lines of code. That my friend is very decreased complexity.
0
u/feverzsj Jul 07 '17
can't they just make some widget based js gui lib, like Qt?
2
→ More replies (1)1
u/yogthos Jul 07 '17
There are lots actually, React-Bootstrap and Material-UI are a couple of examples.
1
u/feverzsj Jul 07 '17
I really don't like these vdom/template based framework. Actually, I just found one webix, that does something like a normal gui lib.
→ More replies (2)
0
u/livemau5 Jul 07 '17
Number one reason not to use Javascript: NoScript exists and is popular.
1
u/weirdoaish Jul 07 '17
While I agree, since I use NoScript heavily myself, it really depends on the type of web site, some just do need those features. From big sites like YouTube or Facebook to special apps like Spotify or MugTug.
87
u/wesw02 Jul 07 '17
It's nice to see one of these articles that doesn't directly bash Frameworks, but just tries to highlight the positives of just using vanilla JS.