Fuck javascript

Unless the software you want on the web is a UI in itself, like Google Docs, you don't actually need javashit. Minimize its use totally.

The ``web app'' can still by dynamic--just serve everything from the server as nice compact html files. The user changes the state of something, serve a new html page.

``B-b-bbbut muh AJAX calls can make it more like a real program!'' Forget it. The only reason you need to make AJAX calls when the user changes state and then modify the original page based on the response, is because loading a new page with all your javashit will take forever. This is the solution to a problem that's caused by itself: javashit. If you would just remove all <script> tags and serve plain HTML and CSS, loading a new page would take just as long or less than the AJAX query. Besides, a new page for a new state in your application is much more intuitive.

It's time to end the cargo cult mentality of making websites that rely on javashit. When it comes to websites, you're sacrificing the most important resource (network resources) for the sake of some eye candy and phony UX bells and whistles, which users don't really care about.

Craigslist and Amazon are one of the few websites who know what they're doing. They both work very well without javascript. It automatically works perfectly well on mobile devices with very little customization only for mobile, because it's regular html that has worked forever. The big problem about browser and device compatibility in the javashit world is nullified by simply not using javashit.

Using javashit to make a ``web app'' introduces massive complexity. The worst part is that it's totally unnecessary, nothing but an exercise in vanity.

node/Handlebars.js/Bootstrap/jQuery/jQuery UI/mootools/YUI/... = the 2015 equivalent of Flash websites

Your website should always "degrade" gracefully. All websites that are inoperable without Javascript are broken by design. Noscript is the tool I use to help me distinguish this.

You're right, but good luck getting the general public to stop building UIs out of js/css/html.

One of its "great advantages" is that it's very easy to release an application to non-computer-intelligent people by building it to run in a web browser. Thus javascript takes a large portion of the blame for flooding the internet with technologically illiterate idiots.

My only hope now is that enough people will become interested in meshnets so I can leave this shithole known as the internet behind.

>>2
At least Flash was (i.e. before Adobe took over, when it was still Macromedia) not as resource-consuming.

Craigslist and Amazon are one of the few websites who know what they're doing

This one is another example.

>>4

You're right, but good luck getting the general public to stop building UIs out of js/css/html.

Show them how much faster and simpler sites will become without JS. Boycott sites that require JS. You could spin it as an accessibility issue, and get a few SJW-like types to lead that movement.

>>5
SJW are only interested in political correctness and social conduct, not quality of engineering or accessibility in the true sense of the word.

would you retards shut the fuck up about SJWs, please

>>7
it's ok for Cudder to do it.

More like JSWs: Javascript Warriors.

>>9
Could be a name of a hacker group. Specializing in xss and zero day browser vulnerabilities.

splitting an application into parts has multiple advantages in the enterprise. A frontend written in JavaScript can maintain its own state, reducing the backend to an HTTP API. /prog/ doesn't need a javascript powered UI, but trying to write a reasonably complex accounting app with server-side rendered HTML gets old fast. Generating HTML on the backend is tiresome, and doesn't allow you to do things such as instant validation / table sorting & filtering.

Furtermore, the frontend is seen as less vulnerable. A sensibly designed backend needs to be closely watched for exploits but as long as all authentication is done in secure httpOnly cookies we can "move fast" with the frontend team.

you'd probably be one of those guys who's proud to be in the backend team.

>>11

Generating HTML on the backend is tiresome, and doesn't allow you to do things such as instant validation / table sorting & filtering.

You still have to the same validation on the backend => code duplication => JavaShit sucks. We need real Java on the front-end, so it get a chance to reuse backend code. Moreover, Java is fast (compared to JewScript)

>>11
You know the back end can't trust the front end right? The client can be malicious.

>>12

Moreover, Java is fast (compared to JewScript)

Some benchmarks comparing Java vs V8 appear to say otherwise.

The JVM can be fast, but it's unlikely Java ever will be unless it stops enabling and encouraging crap like AbstractFactoryControllerFactoryFactorySingletonFactory and having fucking accessor functions for everything.

Kill everyone who uses Eclipse or Netbeans and things would probably improve.

>>15
Accessors/mutators are just a consequence of a bad language design choice. C# and Python got it right with properties, but Java still hasn't added such feature, probably to avoid deprecating tons of AbstractEnterpriseJavaBeans code.

Don't forget to also kill anyone who uses an empty constructor to then set properties of what should be an immutable object.

>>12,13
Of course we know that the backend cannot trust the front. But the validation on either side has different purposes. On the frontend we are validating a form and we need to put markers everywhere and assist the user. On the backend we are validating data and just need to be able to reject with a 400 (it's not me, it's you...).

If you really want you can make "descriptions" of the type of data you'll receive and you can write generalized validators. I found that to be overkill in most applications but am interested in the idea nonetheless.