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.
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'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 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
I always read something like HTML5 games etc. But I don't believe that a game is entirely programmed in HTML5 because it is just a markup language. Normally, it is controlled though JavaScript, right?
I want to program a very very simple browser game, that I can play with my friends. But I want to code the logic in Scala.
So I came up with this structure.
The client is able to see HTML in his browser. HTML5 will be manipulated though JavaScript which opens a connection to my webserver (AJAX?). Now I can program all my logic in Scala and let JavaScript execute it (for example move pawn from position a to position b).
This would be possible, right?
As a webserver I would choose Lift.
But I have never done any rendering with JS/HTML5. Would you recommend to look in some frameworks such as LimeJs or CraftyJs?
"HTML5" is commonly used as an all-encompassing reference to a set of specifications for client-side scripting language APIs, in addition to the core markup language that gave rise to the "ML" part in the name. So "implement this-or-that in HTML5" generally means something like do it in client-side Javascript, manipulating a DOM tree as specificied by HTML5 in order to present a user interface.
It is somewhat inconsistent/illogical naming, but standardizing on inconsistent illogical terminology is what this industry is best at. :-)
http://en.wikipedia.org/wiki/HTML5
HTML5 is a markup language for structuring and presenting content for the World Wide Web, and is a core technology of the Internet originally proposed by Opera Software.[2] It is the fifth revision of the HTML standard ... a mixture of features introduced by various specifications, ... software products such as web browsers, ... common practice, and the many syntax errors in existing web documents. It is also an attempt to define a single markup language that can be written in either HTML or XHTML syntax
HTML5 on its own cannot be used for animation and interactivity - it must be supplemented with CSS3 or Javascript
Sticking with your example developers typically define an API to access your data via your web server.
Javascript would be responsible for manipulating your view (html dom), so it would actually contain a big chunck of your game logic
webserver would contain your data model (maybe it would have logic for a robot player and its next move)
client is the browser
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
I've always been told it's good practice (ala 'unobtrusive javascript') separate JavaScript from HTML markup. However, I've been seeing the opposite trend with a number of new and popular frameworks such as Bootstrap, Angular.js, and Ember.js. Can someone tell me why this isn't considered bad practice?
Unobtrusive Javascript is a good practice for many places on the web. The frameworks you mentioned are often used for creating full-blown Javascript applications. In many of these apps, the experience without Javascript is often a blank page. In that environment, the value of separating your markup from Javascript is relatively low.
I'm asking the same question myself and have come to the following conclusion:
HTML is markup language for presenting documents. The semantics that everyone is referring all around is actually related to representing rich documents. This includes images and links that allow more richer experience.
The same principles can be applied to Word documents, where instead of marking a specific text as red, you can mark it as emphasis and then style the emphasis as red, which will be semantically correct way to express the intend.
The problem arises because HTML actually includes elements that allow user interaction - forms . The initial design was to allow non professionals to create simple interactive UIs. When I checked different desktop GUI frameworks there is no such thing as separation between actual view and view logic, because when you build GUI you don't need that separation.
For me the importance is how much of what you writing is content based or GUI based. Because the HTML serves two purposes it's difficult to know what to serve from the server.
Basically sites like Wikipedia, and even Stackoverflow are content oriented. This means that if they want to be accessible to broader range of clients, like bots and older browsers they should be able to stream pure html.
I'm thinking of two possible strategies when you want to provide content and some richer UI experience, like the textare where I'm writing this comment. The one is to server the html and then initialize the GUI. This is also referred as unobtrusive javascript and semantical HTML. This is what most content oriented sites do. This is mostly to be able to benefit from browsers and bots that will allow their content to be more accessible.
The other strategy will be to identify the type of client and serve different content, which can only be achieved reliably only on the client side, because in both cases html will be served. This is still close to the first stategy, because of the way HTML is used/abused as both content and GUI representation.
If you are writing an application that don't provide content but actual service/process then architecture like AngularJS and similar is suited better.
In my experience most business have to provide both. Let's say you have an app that uses HTML/Javascript to allow users to create drawings. This app doesn't need to follow any unobtrusive guidelines, but it won't be able to run on old browsers too. But if you provide a social sharing of the drawings between users, allowing comments and other content then it's better to write this part of the site in a way that bots and other clients can access the content easily.