Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A day without JavaScript

sonniesedge.co.uk

Post reply on HN
Print view View original

251–260 of 412 posts

Re: A day without JavaScript

#251

Post by marssaxman »

VMG wrote: post #38

> For me it’s a matter of elegance and simplicity over unnecessary complexity. Simplicity is having one place where the DOM is created and managed, and optimizing for the 99% use case. Complexity is splitting up DOM rendering over two networked systems for servicing a 1% use case. Browsers are JS runtimes now. Get over it.

> Browsers are JS runtimes now. Get over it.

Sorry, I won't. I don't trust you and I won't simply run your code by default. It's not like I actually need whatever your web site wants to provide; there are plenty of other things to do on the internet.

Re: A day without JavaScript

#252

Post by marssaxman »

computerex wrote: post #165
gpderetta wrote: post #110

Earlier quoted context omitted.

As the number of people that won't put up with the JS crap anymore and start using JS blockers increase, we will see such websites. Same thing that is happening with ads and ad blockers.

Ad blockers are now going in the other direction with non-intrusive ads being shown.

So far as I know there has been exactly one such ad blocker released, and it was promptly abandoned in favor of the kind of adblockers people actually want to use.

All ads are intrusive to some degree.

Re: A day without JavaScript

#253

Post by joshstrange »

thinkxl wrote: post #148

It's funny how devs feel threatened by a non-JS trend. Even when their favorite frameworks are providing tools to accomplish minimal functionality when JavaScript is off. Server side rendering has been a big priority in React, Vue, Redux, ReactRouter, etc.

I'm not threatened but no-js but I also am not going to maintain 2 code bases or thoroughly complicate things for such a small percentage of people. Yes if you have a news/blog site you should probably support noscript but for web apps I'm sorry, it's just not worth the time and effort.

Re: A day without JavaScript

#254

Post by linkmotif »

scaryclam wrote: post #175
tcfunk wrote: post #150

Earlier quoted context omitted.

I find JS requirements perfectly acceptable for maps, twitter, youtube, and netflix. Particularly maps.

- Twitter, is quite literally, a text based feed. There's no reason for this not to work without JS - Netflix would depend on what you're doing. Much of it can work just fine as text, images and forms - Youtube has a lot of text and the videos could be played without JS if they wanted to bother (HTML5 ftw!) - Maps can also work OK without JS (just without the additional stuff, which is fine for progressive enhancemen…

So easy to write this in a comment but none of this is true. Twitter is not a text based feed. If it was, people would still expect it to be iteractive w/o full page reloads. Same goes for all your examples. DHTML happened, and for a reason. It's not going to unhappen.

Re: A day without JavaScript

#255

Post by ploxiln »

spiderfarmer wrote: post #8

One of my clients loads a 4.5 Mb bower.js (including Angular with a lot of components and jQuery), they also include an extra jQuery script, a full jQuery UI and several other scripts on each pageload . Nothing is minimized. The bower file alone has 300k in comments. The CSS file is also nearly 1 Mb. It's just a simple website with some forms. They have 2 developers working on the site, a scrum master, a project mana…

I don't think more powerful tools are the solution here. The problems and solution are obvious. The root problem is that many "product" teams will take any 10x improvement from tooling and adapt by being 10x more inefficient. Because they can.

Hardware (laptops, phones), and browsers js and rendering engines, are all 10x faster than they were 10 years ago, giving 100x to 1000x overall speedup. Think about that, it is truly incredible. But web pages are also 100x larger and less efficient than 10 years ago. This is absolutely not justified by productivity increases. This is just how the world / humans seem to work.

Re: A day without JavaScript

#256

Post by megous »

forgottenpass wrote: post #206
megous wrote: post #108

Earlier quoted context omitted.

Programming is mostly creating functions and interfaces to decompose problems into reusable parts where reuse makes sense. Nothing wrong with creating a simple function for making XMLHttpRequests or for fetch API. Most of the time there's no need for the level of generality of jQuery interfaces. Just by making a function you're not creating a library. Sometimes I find DOM API verbose too. Nevertheless the fix does no…

Just by making a function you're not creating a library. Have you seen what passes for a library on npm?

Good point. :D

Re: A day without JavaScript

#257

Post by marssaxman »

JepZ wrote: post #10

Well, while I like what you can build with JS, I often don't like what people build. For example, npm makes it so easy to import megabytes as a dependency to your project while you might only need a few kilobytes. And some devs simply do not seem to care about that. On the other hand, JS allows us to build great user interfaces which better to use than our old school point and click adventures we use to have. And if…

I actually liked the old point and click adventures better, because you always knew exactly what to expect. There was a fixed suite of tools provided by the browser and that was that. Now... well... every dumbass designer with a bright idea is free to inflict some bit of novelty on you. Fads sweep through the design community and suddenly old sites which worked fine have to be "updated" to work differently, and you have to learn them all over again, for no benefit.

Re: A day without JavaScript

#258

Post by sametmax »

adtac wrote: post #237
emodendroket wrote: post #230

Earlier quoted context omitted.

Well, define "huge." It's like 28KB that your user may already have cached if you use a CDN. https://mathiasbynens.be/demo/jquery-size

I meant huge in terms of functionality. It supports so many things that you can't possibly need everything.

Event + Ajax + DOM is most of jQuery. And is most what your webapp is. Now I'm more of a fan of Vue.JS + axios myself. But if I have to go minimal, 40ko of jQuery is nothing and save so much trouble. All the "you don't need jquery" thing is done by people doing prototypes that are not tested on most browser or assess in term or ressource vs reward, which is a lot of the projects in the JS community.

Re: A day without JavaScript

#259

Post by pier25 »

jaclaz wrote: post #120

If I may, it seems to me like there are several possible points of discussion: 1) Javascript is bad (vs. Javascript is good and variations thereof) 2) The use a lot of websites make of Javascript is overcomplex, gratuitious, uncalled for, intrusive, etc. 3) Sites should provide some (even minimal) functionality to people browsing them without Javascript #1 is largely a matter of personal opinions #2 is a known, unden…

1) It's irrelevant since it's the only language we have on the browser.

2) I think this is actually a cultural problem. Are users steering away from overcomplex/bloated/intrusive websites? If not, why not?

3) That's an argument similar to should a site support IE8? IMO it really boils down to the cost vs the benefit of supporting user without JS. And that of course will depend on your target users.

Re: A day without JavaScript

#260

Post by sametmax »

megous wrote: post #108
sametmax wrote: post #75

Earlier quoted context omitted.

Polyfill. So new lib. And even then. You need to encode params manually. And of course no middleware, so for special decoding or repeating headers, you end up writting a wrapper.

Programming is mostly creating functions and interfaces to decompose problems into reusable parts where reuse makes sense. Nothing wrong with creating a simple function for making XMLHttpRequests or for fetch API. Most of the time there's no need for the level of generality of jQuery interfaces. Just by making a function you're not creating a library. Sometimes I find DOM API verbose too. Nevertheless the fix does no…

> it may be enough to extend the HTMLElement prototype a bit

You lost me here. Anybody extending standard objects cannot be taken seriously.

Post reply on HN