I created new site http://sampathdesign.com/ could you tell me your thoughts

I disagree on that, but that's because I work on websites not crapplets. It actively encourages people to NOT learn the underlying language, and in MOST cases it falls into those three categories of mine. It CREATES inept developers by it's very nature.

Though yes, that doesn't help.

Aka something that probably shouldn't be done with HTML/CSS/JS in the first place... even if useless inaccessible web crapplets are making the web a less friendly place for users like myself.

https://developer.mozilla.org/en-US/docs/Web/API/Element/querySelector
https://developer.mozilla.org/en-US/docs/Web/API/Element/querySelectorAll

Works IE8/newer.

Though really most of the time people use stuff like getting elements by selector, they would be better off walking the DOM in terms of execution speed and code efficiency, but such concepts are often lost on people who can't be bothered to write semantic markup or make the page work properly WITHOUT scripting first!

In Soviet Russia, the DOM walks you...

Just the way jQuery works, it's core "daisy chain object results" thinking, makes me whip up the knife-hand ready to deliver a pimp slap. It is so grossly and painfully inefficient that I've NEVER seen it fail to piss all over any website someone is DUMB ENOUGH to use it on.

 

I still think jQuery's
$('#id'), $'('.class') or $('input[type=text]') is neater than the querySelector-lines - but that might be just me.

As for the drag-and-drop not being something that you'd want on a webpage, I don't agree. Drag and drop is a big help in creating and rearranging a time-sheet, for instance - you have your workers, you can add, delete and copy them, and you can assign them to different shifts - this is completely possible to do without drag-and-drop, but it involves less pretty interfaces, and multiple reloads of the page to store changes - it hampers effectiveness, in my opinion. And trust me, this was an example taken from a real-life implementation of a system for controlling time-sheets for multiple bars at a workplace, controlled by 3-5 different persons - there were multiple iterations of what they thought worked best, and they ended up on this solution, as it was the most efficient way of doing it. And trust me, it's way better than doing it manually in an Excel-spreadsheet

 

I find that needlessly and pointlessly cryptic, and in the case of the first two it's less efficient as 1) it's not actually returning a DOMNodeList so you are STUCK relying on jQuery methods, 2) it's slower than getElementById or getElementsByClassName for those usage cases as it's using their full parser to find said elements, and 3) it uses more memory since the result from $ in jQuery is many times larger than a DOMNodeList.

Did we mention it's painfully and agonizingly cryptic as well? Maybe that's the fact I'm with Professor Wirth on this stuff, but it's one of the things about jQuery that pisses me off; I don't get how that's "simpler" or "easier" unless you're one of these TLDR twitter generation numbnuts who goes "what do you mean I have to type?!?"

But to be fair, I'm one of the nutters who isn't entirely convinced this is a joke:
https://www.gnu.org/fun/jokes/unix-hoax.html

It's something that belongs in an application -- it's not something I would EVER put online in the first place due to security reasons, accessibility issues, and not all employees are going to even have access to the web. Despite the wild claims to the contrary that seem to be taking over society; I'm sure over half my neighbors would tell you where to stick it; see what happened here when they tried to move ALL public assistance to online application only for which the poor and elderly (you know, the target audience of such things) either lacked access or couldn't figure it out in the office.

Which again sounds like a job for a LAN application, NOT a website. Sure the lines are blurred (node-webkit for example), but that's not necessarily a good thing... and in such an environment you have control over the browser and even the machine in use, something you do NOT have on a website. What you are describing is NOT a website, EVEN if it was done using the same technologies! .. and seriously that sounds more like a job for C#, Java or Delphi!

Of course the minute you are handed a summons for being sued over accessibility, you'll back away from things like that REALLY fast. Seen it happen far, FAR too many places. See a former employer who had to go back to punch-cards for clocking in as the new fancy touch-screen interface didn't work right for half the employees... of the fancy new touchscreen soda machines that don't work and confuse the hell out of people, many of whom end up having to ask the staff at places like Five Guys for help. Annoyingly one of my former employers is responsible for the design of BOTH; that would be the employer I went in and ripped the boss a new hole when I quit in a "what the **** did you even hire me for?!?" moment.

 

Well... as I'm based in Norway, and accessibility regulations apply to public websites (run by government), not private websites, and even if they did, this is an in-house app, which is meant to be accessed from anywhere, since there are no office-hours, and no way of getting everyone using the system to use the two computer in the office - however, the publicly accessible university wifi makes it easy to sit with your laptop whereever and do what needs to be done.

I don't see what security has to do with this - any webpage with personal info will be under scrutiny for possible ways to get into the system - it has next to nothing to do with how the forms functionality is being handled by javascript - you need to be logged in to access this anyway. And since the whole system is running on parameterized queries using PDO, and (as far as I know, at least), not splashing error-messages with table-info into the browser if there is an error, nor doing stuff without the correct credentials being provided, I doubt there's easy ways to hack it - of course it's possible, session hi-jacking for instance, or weak passwords, but that is at least known issues, and being handled (hopefully) adequately.

Unless all employees here have access to the web, they'll have serious problems - since most of the employees here are students, and EVERYTHING pertaining to coursework, lesson plans etc. is online. Besides, Norway has an online-coverage where about 95% of the population between 15 and up, and the percentage for smart-phones is about 81% (latest count). Hence, it's not really a problem. About 78% of the homes have access to broadband with more than 5Mb/s downstream, and about 92% have access to 1MB/s downstream or better.

As for the LAN vs web, it's online because it's supposed to be possible to reach from wherever - the employees set up when they can work, and the managers assign them to shifts, shuffles them around and more. And no, I have no control over what machines or browsers are in use - it might be IE, it might be Chrome, Firefox or Opera, or even Safari (although why anyone would use that crap is beyond me) - on Linux, Windows or OSX. Doubtful anyone surfs without javascript on, or the ability to turn it on for using this page if needed. Not everyone is very tech-savvy, but everyone I've taught to use the interface has been up and running in under half an hour - it's quite simple, the interface, and it provides an easy to alter showing of all employees, their times of work and so on. The complete number of people using the system is between 200 and 350, depending on time of year and more.