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
There are a lot of "buts" in approaches to web development. Recently I've read an article
why not to use Twitter bootstrap. One of the reasons were that it doesn’t follow best practices. Well I don't want to discuss about TB. What I wanna know is how is it with Modernizr - it looks like that has a lot of advantages, but what about dissadvantages? Is that also redeemed by using bad programming practises on web (like these mentioned in twitter bootstrap)?
By good practices I mean ideas which are connected with Html5 and CSS => this is not opinion based question - I'm basicly asking if Modernizr is in contrary with these ideas.
Modernizr itself tries to follow best practices as best as possible, however there are a few things that it does that aren't necessarily "best practice"
it basically requires being loading in the <head>. Since one of the main uses of Modernizr is the css classes that are added, you actually want it to block the rendering of the page until after it has ran. If you load it in the bottom of the page (which is the "best practice" for javascript, generally) and rely on the classes it provides, you would see a flicker between the non-support and support versions of your styles as it runs.
It can be heavy. There are ongoing discussions on the github issue tracker about how we can improve the execution time of the library, as well as new preposed updates to the lib that would group tests to increase speed
Not only that, but it can be used poorly. One of the most common issues is that people deploy their public website with the debug build of Modernizr - the one that includes ALL of the tests. This means running very large amount of javascript that never impacts your site.
Other than that, modernizr tries very hard to help define best practices, let alone just follow them. If you ever find there is any issue what so ever, I would really encourage you to open up an issue on the github repo to help us move the internet forward.
Related
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 have worked in Angular js and find it to be developer friendly and ease of use is awesome. I found out it performs extremely good with SPA(Single page application) architecture and if controller scope variables are not misused.
I however don't know why most of eCommerce companies complaining angular being not performing equivalent to reactjs. I think in lot of use cases might not event found the visible performance difference, with development effort being less.
Angular followed MVC ideology, while React is developed with MVVM design. I don't consider myself a very good programmer in either of them, anyways I have started learning reactjs, so I want to know should I go for react js for my own project or not, one clear advantage is isomorphic rendering.
I tried to make this a comment but ran out of space :)
As with anything, it is as fast as the developer can make it :) A good AngularJS developer can make an app that is faster than a bad developer creating a React app.
Having said that, React will be faster out of the box with a LARGE amount of elements on screen. AngularJS will require some knowledge to make it fast with lots of on screen elements. But I fully expect for most people they won't ever see any performance drop with most apps. E.g. if you want to make a fairly complex application with a couple of hundred dynamic objects on screen you shouldn't see many performance problems.
If you do choose AngularJS [my preferred framework] I would suggest following the latest component guidelines as it will help you build a performant application.
As an indicator I am working on an asset tracking AngularJS app. We can track around 2000 elements on screen a map at once with lots of additional information and this works pretty fast. It took a lot of work to get there though. It also works great on mobile too :)
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.
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 6 years ago.
Improve this question
If you're not creating a single page website or generating components on a page that get live updates is there any reason to use a JavaScript framework like angular, react etc?
No, there is not.
But there are things like modules, cross-browser DOM manipulation utilities, routing, 2 way data binding etc. which don't come out-of-the-box with JavaScript but are provided by these frameworks which really helps quicken the development process.
You probably shouldn’t use a JavaScript Framework. Instead, you should write modular, vanilla JavaScript. You also probably shouldn’t be considering a JavaScript MVC framework, especially if it’s going to be architected in the same way as a server rendered application (going to use site/application interchangeably). With a high performing site, you’ll likely squeak just as much perf out of a server rendered app as you would a “single page” app. Between sending less down the line to your users (reducing bandwidth and time to load), keeping their cache size small (making it more likely they’ll have something in cache next time), and reducing the memory footprint of your JavaScript (increasing perceived and on-page performance), you’re likely better off rendering on server.
If you absolutely must use a JavaScript framework (development skills across the team aren’t high enough to write vanilla JavaScript and there’s not time/money/interest in training the team and improving their skills, there is a real, not perceived, business need to support very old and outdated browsers, etc…) for server rendered applications, you should probably use jQuery. Yes, there’s Zepto and any number of other things you can use in place, but you should probably use jQuery.
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 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.