JavaScript Fatigue • Hacker News Board

Re: JavaScript Fatigue

#31

Post by chubot » Mon, Dec 28, 2015, 3:57 AM UTC

darylteo wrote: post #17

Today I started a rebuild of my website as a technical exercise. 1 working day in, and I haven't written a single line of actual html. Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend. Every other build tool has its own ecosystem of tools that shim around an existi…

If you're not a front end developer, then why is it a technical exercise to learn all this stuff? Personally, I don't want to learn things that will be obsolete in a few years.

I also rebuilt my website as a technical exercise, but I'm doing it in raw HTML, CSS, and JS. Literally with vim and shell scripts to build it.

I know it can meet the requirements of a personal website, and many other kinds of sites. It probably takes a little longer, but I know it's going to work in 5 years, and I will know how to maintain it.

And I will have more foundational knowledge. Things have changed a lot with HTML and CSS. I learned how to use HTML5 onHashChange. And I did my own "CSS reset" without using any libraries. I wrote my own table sorter with raw DOM manipulation.

I think you need this knowledge to help you use the framework correctly anyway.

Re: JavaScript Fatigue

#32

Post by chubot » Mon, Dec 28, 2015, 4:02 AM UTC

CloudYeller wrote: post #11

It's scary that if you don't jump on some kind of framework bandwagon, you'll be half as productive as framework devotees within 4-5 years. When I joined my current team in 2015, they were still using Python Paste and jQuery for everything, while I was well-versed in Angular + a modern Python server framework. Armed with my modern libraries, I could do more in 1 day than an average teammate could in a week. In other…

Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? (I'm not a front end developer -- though I do write significant amounts of raw HTML, CSS, and JavaScript).

Is it really higher productivity, or is it just keeping up with the latest fashion?

I feel like the vast majority of websites don't need more than a little JavaScript -- exceptions being Google Maps, Google Docs and spreadsheets, etc.

AirBNB is listed here -- honest question: do they really need a lot of JS? I mean mainly it's showing a lot of pictures and providing good navigation and search. Am I missing something? It's basically like eBay in 2000 except prettier, and that was done without a lot of JS.

https://github.com/facebook/react/wiki/Sites-Using-React

Asana might be a good candidate for a real "app" that needs the complexity.

Why is Wired on there? I think news sites are the worst offenders in terms of using unneeded JavaScript.

Re: JavaScript Fatigue

#33

Post by enraged_camel » Mon, Dec 28, 2015, 4:34 AM UTC

chubot wrote: post #31

darylteo wrote: post #17

Today I started a rebuild of my website as a technical exercise. 1 working day in, and I haven't written a single line of actual html. Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend. Every other build tool has its own ecosystem of tools that shim around an existi…

If you're not a front end developer, then why is it a technical exercise to learn all this stuff? Personally, I don't want to learn things that will be obsolete in a few years. I also rebuilt my website as a technical exercise, but I'm doing it in raw HTML, CSS, and JS. Literally with vim and shell scripts to build it. I know it can meet the requirements of a personal website, and many other kinds of sites. It probab…

>>If you're not a front end developer, then why is it a technical exercise to learn all this stuff?

There are many reasons. For one thing, a lot of developers are "full-stack" and don't have the luxury of focusing on just the front-end or the back-end. For another, learning new tools, frameworks and methodologies will make you a better overall developer.

>>Personally, I don't want to learn things that will be obsolete in a few years.

Better not work in web development then. It's probably the fastest moving subfield in software and there's no guarantee that what you're learning today won't be obsolete in a few years. So your best bet is to learn as much as you can, rather than putting all your eggs in one basket that you think will last a long time.

Re: JavaScript Fatigue

#34

Post by enraged_camel » Mon, Dec 28, 2015, 4:48 AM UTC

chubot wrote: post #32

CloudYeller wrote: post #11

It's scary that if you don't jump on some kind of framework bandwagon, you'll be half as productive as framework devotees within 4-5 years. When I joined my current team in 2015, they were still using Python Paste and jQuery for everything, while I was well-versed in Angular + a modern Python server framework. Armed with my modern libraries, I could do more in 1 day than an average teammate could in a week. In other…

Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? (I'm not a front end developer -- though I do write significant amounts of raw HTML, CSS, and JavaScript). Is it really higher productivity, or is it just keeping up with the latest fashion? I feel like the vast majority of websites don't need more than a little JavaScript -- exceptions being Google Maps, Google Docs…

>>Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? [...] Is it really higher productivity, or is it just keeping up with the latest fashion?

Answer to the first question: nothing. Everything you develop using React/Angular/etc. can be written using vanilla HTML/CSS/JS.

The difference is that, as your pages become more and more interactive, it becomes harder and harder to deal with the complexity. I recently developed a web form that has a little over 1,000 lines of JQuery. After a while, it became really difficult to keep track of various event handlers, when they would fire and how to make sure they didn't interfere with each other. If I were using a framework like React, it would have been much easier. Here's a diagram that outlines this concept: http://imgur.com/dSQTLDE

>>I feel like the vast majority of websites don't need more than a little JavaScript

Websites don't. Web apps do. The distinction becomes bigger and more important every day.

Re: JavaScript Fatigue

#35

Post by chubot » Mon, Dec 28, 2015, 6:26 AM UTC

enraged_camel wrote: post #34

chubot wrote: post #32

Earlier quoted context omitted.

Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? (I'm not a front end developer -- though I do write significant amounts of raw HTML, CSS, and JavaScript). Is it really higher productivity, or is it just keeping up with the latest fashion? I feel like the vast majority of websites don't need more than a little JavaScript -- exceptions being Google Maps, Google Docs…

>>Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? [...] Is it really higher productivity, or is it just keeping up with the latest fashion? Answer to the first question: nothing. Everything you develop using React/Angular/etc. can be written using vanilla HTML/CSS/JS. The difference is that, as your pages become more and more interactive, it becomes harder and har…

I just have a hard time understanding where all these web apps are coming from, and what the real requirement is. It seems to me that the ratio of problems that require web apps to web sites is more like 1:1000 than 1:10. In other words, I wonder why it seems everyone is using React or Angular, rather than just a few people.

I mentioned Google maps, docs, and spreadsheets as bona fide apps. They require a completely different approach. They are extraordinarily stateful on the client.

What other sites need that? As mentioned, I don't think AirBNB does. How much state does it need on a page? It's basically like a shopping cart, like eBay. You search for properties, and then you book one. (Maybe it is different for listers, I haven't listed).

I get that you need more advanced stuff like React and Angular to manage a lot of state on the client. jQuery gets messy in that case. But I am wondering why apps all of the sudden need this much state. If you break up your app into different pages, then you don't need so much state on each page. The state is in the URI.

In other words, I see a lot of it as self-inflicted pain... the customer didn't actually want all this stuff. They just want to order a meal online or something. I looked through that whole "Built with React" github page, and I am still trying to understand where the requirements for lots of state are.

I don't buy the motivation of keeping everything on one page to save network latency... if you actually profile a lot of web pages nowadays, the rendering time is greater than network time! I'm seeing full seconds reported by Chrome dev tools just to render!!! It doesn't appear that anyone cares about latency, given how slow most web sites and apps are.

Re: JavaScript Fatigue

#36

Post by chubot » Mon, Dec 28, 2015, 6:36 AM UTC

enraged_camel wrote: post #33

chubot wrote: post #31

Earlier quoted context omitted.

If you're not a front end developer, then why is it a technical exercise to learn all this stuff? Personally, I don't want to learn things that will be obsolete in a few years. I also rebuilt my website as a technical exercise, but I'm doing it in raw HTML, CSS, and JS. Literally with vim and shell scripts to build it. I know it can meet the requirements of a personal website, and many other kinds of sites. It probab…

>>If you're not a front end developer, then why is it a technical exercise to learn all this stuff? There are many reasons. For one thing, a lot of developers are "full-stack" and don't have the luxury of focusing on just the front-end or the back-end. For another, learning new tools, frameworks and methodologies will make you a better overall developer. >>Personally, I don't want to learn things that will be obsolet…

Yeah, professional web dev is not for me, though it seems I'm not the only one lamenting the state of affairs. It seems that it's not just the frameworks that are thrown away in 3 years, but sometimes the products built with them too!

I think learning new "frameworks and methodologies" only makes you a better developer to the degree that they are well thought-out. It seems like a lot of JavaScript stuff is basically still in a state of flux, where people are experimenting and figuring things out.

I spent a lot of time learning Python, C++, C, R, bash, OCaml, and HTML/CSS/JavaScript. All those things have lasting value, and I expect to be using them in 5 years, and probably most of them in 20 years.

I would say jQuery has lasting value, since it has an elegant data-driven / document-driven model. I look a new things to understand if they have lasting value. React does seem principled to me, and I was interested in playing with it, although these threads have what dampened the enthusiasm.

I am using HTML/CSS/JS to display statistics and visualizations, and it works perfectly for that. In any case, I do think there is a problem where a lot of front end devs don't actually understand the abstractions the browser presents. It's basically the same problem as Python or Ruby programmers not understanding what syscalls are and writing horrifically slow code.

Re: JavaScript Fatigue

#37

Post by enraged_camel » Mon, Dec 28, 2015, 6:39 AM UTC

chubot wrote: post #35

enraged_camel wrote: post #34

Earlier quoted context omitted.

>>Honest question: what kinds of things are you doing with React/Angular that you can't do with jQuery? [...] Is it really higher productivity, or is it just keeping up with the latest fashion? Answer to the first question: nothing. Everything you develop using React/Angular/etc. can be written using vanilla HTML/CSS/JS. The difference is that, as your pages become more and more interactive, it becomes harder and har…

I just have a hard time understanding where all these web apps are coming from, and what the real requirement is. It seems to me that the ratio of problems that require web apps to web sites is more like 1:1000 than 1:10. In other words, I wonder why it seems everyone is using React or Angular, rather than just a few people. I mentioned Google maps, docs, and spreadsheets as bona fide apps. They require a completely…

It's not about latency, but about overall performance. Rendering on the server is slower than rendering on the client, because the server may have to deal with a thousand requests per minute whereas the client doesn't. So you push the logic to the client and let the browser deal with it until talking to the server is actually necessary (e.g. when the time comes to submit the data). Therefore client-side frameworks become a kind of distributed processing of application logic.

Furthermore, you shouldn't take latency for granted. Many users are on choppy mobile connections. Waiting for the server after every action results in a really bad user experience in those scenarios.

Re: JavaScript Fatigue

#38

Post by chubot » Mon, Dec 28, 2015, 7:38 AM UTC

enraged_camel wrote: post #37

chubot wrote: post #35

Earlier quoted context omitted.

I just have a hard time understanding where all these web apps are coming from, and what the real requirement is. It seems to me that the ratio of problems that require web apps to web sites is more like 1:1000 than 1:10. In other words, I wonder why it seems everyone is using React or Angular, rather than just a few people. I mentioned Google maps, docs, and spreadsheets as bona fide apps. They require a completely…

It's not about latency, but about overall performance. Rendering on the server is slower than rendering on the client, because the server may have to deal with a thousand requests per minute whereas the client doesn't. So you push the logic to the client and let the browser deal with it until talking to the server is actually necessary (e.g. when the time comes to submit the data). Therefore client-side frameworks be…

I'm not really buying it... Rendering on the server seems like a solved problem to me. Web apps scale.

Sure, you can save servers by offloading work on the client. But I think your server cost is absolutely dwarfed by developer salaries. I guess it depends on whether you have more front end people or back end people. Good front end people seem to be just as expensive and rare as good backend/C++/Unix/distributed systems people these days.

On mobile, most web apps are a disaster. They are certainly a lot worse than light HTML. Never mind waiting for the server on every action -- try getting the app to load in the first place! The Android and Chrome team have numbers on the astronomical rate of user-aborted or otherwise failed page loads on mobile. On mobile, users see the white screen for 5-10 seconds (probably waiting for your 10-50 round trips for your JS, CSS, heavy image assets, and especially third party JS) and then give up.

Re: JavaScript Fatigue

#39

Post by vldr » Mon, Dec 28, 2015, 8:30 AM UTC

Every language / framework has its tooling options but javascript has a lot and no standard/preferred ways. Like with standards, it seems that tooling problems are solved by creating new / more tools.

I have a strong Python background and I'm overwhelmed by the tools available for just building / managing javascript and making it usable. With python (for example) you don't need additional tools for managing/defining/importing modules, building/compressing/minifying code or adding additional language features.

The solution for me was to switch from Angular (where I had to make all choices myself, which I wasn't capable to do) to Ember(-cli) that is making the choices for me. And the lack of such a tight integrated supported set of tools is what is and will keep me from moving to other frameworks in the forseable future.

Re: JavaScript Fatigue

#40

Post by frik » Mon, Dec 28, 2015, 8:52 AM UTC

chubot wrote: post #38

enraged_camel wrote: post #37

Earlier quoted context omitted.

It's not about latency, but about overall performance. Rendering on the server is slower than rendering on the client, because the server may have to deal with a thousand requests per minute whereas the client doesn't. So you push the logic to the client and let the browser deal with it until talking to the server is actually necessary (e.g. when the time comes to submit the data). Therefore client-side frameworks be…

I'm not really buying it... Rendering on the server seems like a solved problem to me. Web apps scale. Sure, you can save servers by offloading work on the client. But I think your server cost is absolutely dwarfed by developer salaries. I guess it depends on whether you have more front end people or back end people. Good front end people seem to be just as expensive and rare as good backend/C++/Unix/distributed syst…

You are so right!

I hand tuned web apps (vanilla JS5, no libs/frameworks) and opimized them for mobile, and they are very fast.

But most don't care and use bloated JS libraries/frameworks and the end user has to wait several seconds until the 1MB JS file loads over a cell connection or even crash the mobile browser because the site owner thought it is okay to integrate 30 advertisement and analytics third party JS files.