Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on a project with a friend.
He is by far a better programmer than I am, as I have been programming for a little over a year.
I noticed he often builds components, and functionality from scratch. I'd consider him almost a "hipster" in terms of building functionality from scratch.
Is there any downside to my approach of utilizing npm libraries, etc for use? Ie. Date Pickers, Map Components, etc?
One reason I might conjure up is that perhaps there's a performance hit. Will load time be affected significantly? I'm not building a large application, in fact I'd consider it small, BUT! I'm wondering if I'm "cheating", OR this will lead to bloat.
As a quick preview, my basic functionality would currently look to include:
Emoji Picker
Date Picker
Google Maps API Maps Component & Places
Form Validation Library
Superagent
Moment.js
First of all you're not cheating.
It's quite common for developers to use third party packages.
But it can be good experience learning to build your own components.
Don't forget you can always swap them out as your experience, knowledge grows
Pros.
They can save you development time.
They can do things that you may find difficult to implement.
They can be better written and tested.
Cons.
They can be badly written, unreliable, unsupported.
If you don't know how they work they can be problematic if there's a bug or if you need to extend the functionality.
You could end up including a lot of script that is unused.
You might be able to write something better and more maintainable.
Bundling, minifying, uglifying your JavaScript and tree shaking with tools like rollup can help keep your download sizes down.
If you use packages, use reliable ones, look at reviews and ratings, check out the activity and issues log.
As with all concerns performance related - test.
Use fiddler or chrome to see how big your downloads are, measure your download times.
Where possible test under realistic device/network/load conditions.
It's a good test of knowledge on your part, since you are new, to attempt to write all of those things yourselves. It's how a good portion of the users of stackoverflow learned: take on a project that sounds doable, but has an unknown section for you at the time. It's how I personally learned just about everything I know.
That being said, I don't think it's cheating. There's a common phrase in English: "Don't reinvent the wheel." The reason that those libraries exist is because someone took a lot of time to make them, and then realized that other people could probably benefit from it as well. With the example of Moment, working with Date/Time in any language is a huge pain, and the reason Moment is so popular is because no one wants to go through all of what Moment's creator(s) went through already. Why waste time reinventing a perfectly good, well tested, and reliable wheel?
Now if ever you go "man, this wheel is nice, but wouldn't it be better if they were made out of something more durable so that they can go over more bumps?" then in this case you are improving the wheel -- and similarly there are many projects that started off as a fork from an already existing one looking to add what the author felt was missing functionality.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am new to front end development. Let's say hypothetically my clients have modern hardware, 2.20 GHz CPU, 4GB ram. A flashy website that uses a lot of event handlers, and animations like "slide for div containers to move in and out on users click" and "jquery "on" click for mustache templates created on the fly with ajax (for elements being added after initial DOM load).
I know it depends if my programming skills are really terrible which could be causing the user end to perform really poorly, but lets say I program as close to efficient as possible, and use very well written plug-ins.
Question - Do clients with that hardware handle a highly customized design well? Are browser development tools the best out there in terms of troubleshooting and analyzing performance, or is there a highly popular widely used tool that does the job for a lot of developers?
My question focuses on two key points.
Client Side Performance based on sleek and flashy websites using
plugins mentioned below on modern hardware.
What do developers use to help them check hardware utilization,
profile and troubleshoot issues.
browser development tools is sufficient?
A popular tool widley used by developers that I haven't discovered?
Additional Notes
I am also using my application server to host these files since I am using MVC so its not completely static html files. Plugins include:
Jquery
BootstrapJS
Bootstrap Max Length
Jquery UI(Effects Corewith Slidejs, its 14Kb in size)
Jquery Uniform
MustacheJS
Jquery Uniform took the biggest hit on page load times I called it on about 100 elements when the page loaded. So I changed it by calling it on elements that needed it when the client clicks on a div to slide open on specific selectors.
What influenced my question?
Toying around and reading about Angularjs. Since everything is client side, I read mixed feelings on it slowing the client down and possibly speeding it up. Since I am already knee deep in Jquery I was curious how well it performs with the more modern hardware using a lot of flashy components and DOM manipulation that I mentioned above. This is my first front end design, so I know more seasoned Front End Developers know how well browsers handle these knew frameworks being used.
Why it's important
The temptation to add all the glitter and flashiness to a webpage to make it look more attractive to the client, could actually work against me is a concern.
In my experience you can have hundred of thousands of DOM elements, thousands of objects with arrays inside and nothing happens. In the web are many awful sites made up like Frankenstein's monsters with literally dozens of libraries and have not performance problems in computers from 15 years ago.
While you don't mess with 3d rendering and that experimental things you won't have problems in mainstream PCs. I don't know what your flashy cool features are. Also if you are very bad programming and make almost never-ending loops or something like that could be a problem, but that's anywhere.
Another problem is the download time, and is the most important thing to care about, if you have tons of code it will take longer to download. Usually in server applications you prefer performance before lightness but in the front end is better to download small files. Internet always will be slower than the CPU and RAM.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am ColdFusion developer working in ColdFusion since last 2 years. Recently before few weeks i have started learning cfclient API of ColdFusion Splendor as I am always interested in Mobile application development. But today after reading comments on the blog
http://blogs.coldfusion.com/post.cfm/coldfusion-mobile-features-are-not-just-about-cfclient-but-it-is-necessary#comment-08603915-B031-CC32-1C2DE6521C233F65
I am in big dilemma, Is it worth of spending time for learning cfclient. Some of conclusions that I found after reading the comments on the blog are.
Adobe never have a good track record on generating JS. They generate very ugly looking js.
cfform and cfgrid were introduced with some client side functionality.But now a days no one loves to use it because they have not been updated since long and we can get more flexibility using custom js library.The same may happen to cfclient.
It's a crappy decision from Adobe to focus on mobile application development instead of making the server side language more robust and fixing old bugs.
cfclient inspires the developers not to learn JavaScript.
Adobe is trying to solve a problem that does not exist.
I think you've answered your own question here, to be honest: don't waste your time.
Basically <cfclient> is, by Adobe's own admission, just a hook into the language to tell how the compiler should treat the code: translating it into JavaScript instead of compiling it to bytecode like with normal CFML. And it's a really crap way of achieving that.
The other reason is that they couldn't work out how to implement the hooks into ColdFusion Builder to make all its mobile-dev workflow work.
Another problem is that the Adobe guys are just... not any good at writing anything other than Java. This has been borne out by every single foray into anything other than Java that they write (this includes CFML, incidentally: they can't even write that).
So do you really want journeymen developers who aren't comfortable in the language writing wizards to write your JS for you? No.
Do yourself a favour, and just learn to do it properly. <cfclient> is just an example of Adobe having not learned their lessons over the years after all the <cfform>, AJAX-enabled layout widgets like <cfpod>, and Flash forms. They have never had the skillset to do this work properly, so don't put yourself at their mercy.
Oh, and I'm also voting to close the question as it's not one that can be answered objectively.
This is my take on it
Even if it were good approach today, it is not future proof. New browsers will come, new javascript features will come. I fear that this won't move ahead.
I could not agree more
And some of the existing bugs really need to be addressed.
<cfclient> asserts that client side development should be in cfml. IMHO, Coffeescript covers some of those concerns.
There is a demand for Mobile friendly websites. If I had to pick ONE thing to move ColdFusion forward in this arena it would be: Can we get the JSON functions to work right
There are many ways that Adobe could have moved forward on the mobile application front. If they promoted various community based solutions that would be useful. I know Bootstrap + FW/1 + ColdFusion. But I don't know PhoneGap/Cordova + ColdFusion. I would be good to see those work together.
True, But if you're using CFClient, you're not wanting to write JS anyway, so what do you care what it looks like on the client.
I believe Adobe has promised that we would be able to update the core underpinnings of CFClient (probably PhoneGap/Cordova) and other JS libraries.
Agreed.
I don't know about inspires.
I disagree here. I'd love for a way to quickly deploy to mobile.
PS> I'm sure since this question isn't code related, it will get downvoted / deleted; Might be a better topic for the CF-Talk mailing list or some ColdFusion forum somewhere.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We have a slightly over optimistic boss, so I would like to hear it from other people.
Someone who has about 3 years of good PHP, HTML, and CSS knowledge. However this person has never really worked with any other type of object oriented language like c++, java, python or c#. He is just now discovering things like LESS, media queries/responsive design, minification & bundling, and has no real JavaScript knowledge, and very little of jQuery.
Now how long would you guys estimate it would take (just a ballpark estimate, knowing he is motivated and smart) to be able to make/manage a site in asp.net MVC that has the complexity of a site lets say a mix of Mashable and Twitter and that makes heavy use of cache management, Ajax web services, responsive design, authentication, linq, anonymous functions, delegates, async/tpl, database access, jQuery, and object oriented JavaScript ?
The how long question is more: how long do you estimate till he's is able to make or manage a site like above, but the site must also be of high quality, and able to take on millions of monthly users.
Thanks all !
Please only serious feedback. Even if you guys could break down the learning curves for the different technologies that would be great. I'd like my boss to get a serious and non biased idea of how long these types of things can take to learn.
a LONG time. Object oriented is a little bit of a different beast than simple scripting. Of course everyone learns at different rates, but i'd say it'd be something on the magnitude of several years.
Changing platforms is a real tough job. Most people try to find exact same techniques they know in PHP to do it in ASP.NET MVC, which is never possible. And all these people do not start as fresh, they skip things as considered as they know it. This leads to half knowledge and then just searching on google on how to do similar thing on different technology.
We did migrate from Java to ASP.NET MVC and we could do it in reasonable period of 1 year. First 3 months were put in learning code samples from MSDN. Next set of 3 months were spent on writing code for our app straight with the knowledge we had. But it does end up in writing code very inefficently that needs refractoring. After that we did refractor code for 6 months!!
ASP.NET MVC is centered more towards Entity Framework and Linq, and that is the tough part, if you can master Entity Framework the way it is supposed to be done, than rest is very easy. Digesting navigation properties and writing queries using navigation property instead of JOINS is the hardest part.
ASP.NET MVC with EF means, NO SQL, NO JOINS. I always loved ORMLs so I learned quickly, but it is little confusing, you must focus more on Entity Framework.
Rest of ASP.NET MVC is pretty much similar to that of any php MVC framework.
C# would be a bit easier to learn. C++ would be the slightly better choice if you need maximum performance. I would not recommend java, but that is my personal taste.
Changing a language is mostly changing the syntax, which might be learned in quite a short timeframe. BUT CHANGING THE PARADIGM forces you to think in new patterns, which is a lot harder to do.
Nevertheless we are talking about AT LEAST 2 years, if he is learning fast. After that, he might start working on the actual site, which will take also at least more than 6 months. If the design is already made by someone, who knows what he ios doing. Otherwise the time may range from additional 6 month (because he needs to start from scratch at some point) and eternity.
I would not want to be the guy, maintaining the site, if he learns the language by working on the site. And you would not want to be the one to use it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
We are a student team maintaining a mobile app written mainly in javascript (also jquery) and PHP.
We recognized that we have to improve the structure of our code and have to implement structures and workflows within the Team.
Status of the code:
By now the code is still very tangled, not loosely coupled.
Classnames with identical names in different folders.
Wide usage of == instead of ===.
Wide usage of global variables.
We reinvented the wheel for parts of the code. (where frameworks already existed for certain purposes)
Status Methods/Tools:
We are now implementing SCRUM
We use Redmine Backlogs which works good for us.
We implemented a usable branching model for git. (http://nvie.com/posts/a-successful-git-branching-model/)
We started to use jsdoc to do an inline documentation of the code.
We stumbled across SonarQube (a code quality checking tool) and think this might be helpful.
We are still new to TDD and skeptic about it.
We do not have expertise in designpatterns but would like to apply them.
Only few in our team of round about 6 people know the basic concepts of MVC, MVV, MVP.
We want to start with refactoring our code (to unobtrusive js?) around the first week of september.
Which steps would you suggest so that we don't stumble too much and that the process is kept transparent and motivation is high?
Would you start by fixing little issues like the == / === thing? (things SonarQube comes up with)
Would you start with implementing a TDD framework but without having a testable MVC/MVV ?
Would you start with separating js from html and css?
Would you start with bugfixing of old, not yet resolved tickets to have absolutely clean branches?
Thank you very much for any suggestions/ideas/best practices
Marc
Well .. step nr.1: read this book. You have time enough for that till September.
Watch following lectures:
It Was Like That When I Got Here
Recognising smelly code
Unit testing
These materials should give you some sense of the subject.
As for real first steps, separating the HTML from JavaScript is a nice place to begin. If you know how to do event delegation in javascript - good. If not, look into it.
Then you can move on to fixing the part of page that spews out the HTML. Separate the SQL, add some abstraction, some OOP principles.
If you end up aiming at something MVC-shaped, then this list of links might help a bit.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I recently discovered Typescript. Coming from an OOP C# background, I find Javascript very difficult to work with and am naturally thrilled about Typescript.
I'm currently using Backbone.Marionette.js in my application to manage future complexity (future because it's still the early stage and not yet that complex).
Now I understand there is still room for Backbone.js to play an important role in my application even if I'm using Typescript, but the more I learn Typescript (and begin to love it), the more I start thinking that its objective in managing complexity in enterprise application overlaps too much with what Marionette tries to accomplish. I understand they do it in two completely different ways but coming from C# I of course prefer the OOP approach instead of yet another JS plugin.
Are my considerations to phase out Marionette out of my application justified or is there less overlap than I think? Keep in mind, I'm new to all 3 Backbone, TypeScript, and Marionette and this is the first application I've used them in, which makes it difficult for me to assess this question.
"TypeScript vs Marionette" is the wrong perspective. That would be like "C# vs WinForms", and asking "Should I stop using WinForms when I switch from C# to VB.NET?" This question doesn't make any sense because it is trying to compare a language to a framework.
There are some things that TypeScript will prevent you from doing with Marionette or any other JavaScript framework that takes advantage of JavaScript being dynamic. But that doesn't mean TypeScript replaces Marionette or any other framework. It only limits the usefulness of the framework due to restrictions that TypeScript places on you.
My answer would be based on the following considerations.
Firstly, what parts of Marionette are you using? If it is just the module loading then you don't need it. If you are using a lot of the templating and eventing it may be useful still. If you aren't sure yet what parts you might use, don't use it until you have a compelling reason to use it.
Secondly, how much can you write before you need to make decision? For example, if you start coding today, how long can you defer the decision. The longer you wait, the more information you'll have to help you make the right choice. If you write plain TypeScript, you can wait until you actually need to bring in a framework or toolkit and then choose the one that solves your real problem.
So really, my answer is start without it and wait until you have a problem to solve before choosing how you solve it.