Live data from Hacker News

Ask HN: Is all programming constantly changing or just front-end JavaScript?

news.ycombinator.com

51–60 of 139 posts

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#51

From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude. I ended up being a product designer (my main, academic education), a frontend, and a backend with varying levels of expertise in my lifetime, so I have some direct experience. My current advice as of April 2019 is to keep calm, if you can stay away from JS, do it, if y…

What's the matter with Webpack? It carries quite a lot of advantages, like tree-shaking, code splitting, and lazy loading. These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.

Configuring it is a giant time suck. Particularly if you want to do hot reloading and all that kind of stuff.

I'm a big fan of Parcel for 90% of the things I do. It just works.

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#52

From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude. I ended up being a product designer (my main, academic education), a frontend, and a backend with varying levels of expertise in my lifetime, so I have some direct experience. My current advice as of April 2019 is to keep calm, if you can stay away from JS, do it, if y…

What's the matter with Webpack? It carries quite a lot of advantages, like tree-shaking, code splitting, and lazy loading. These are real, tangible performance benefits, so I'm going to need some kind of compelling evidence as to why avoid Webpack.

Webpack is virtually indispensable, it has a poor reputation because the docs weren't great in v1.x and because it takes some effort to understand and configure correctly. When it's configured it's rock solid and it rarely needs touching again.

I have this theory that people dislike it because that complexity comes front loaded - the most fun part of any new project development is right at the start and if you're spending time setting up webpack then the developer perceives that as frustrating time wasted rather than an investment in the project that pays off long term. A big part of create-react-app's success is because it means the developer can get started right away and not have to worry about that.

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#53
I had primary been a C# dev, then switched to JavaScript/TypeScript for a few years. Lots of change in those years: JQuery, Angular 1, Angular 2, TypeScript, etc. Then I recently switched worked on a C# project. Other than a few Dot Net Core changes, it was basically the same, and easy to switch back to C# land. Not I am back in JS land. This time using Angular elements. When I left, I was getting used to declaring local variable with let instead of var. Now local variables are not let, they are mostly declared with const, which reinforces the notion that nothing is ever really "constant" in JavaScript world :)

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#54
I think a big contribution to the rate of change of JS is that there is not yet a division between frameworks that do display stuff and frameworks that do utility/heavy lifting - this is partially due to the fact (IMO) that a lot of systems isolate heavy/complicated logic (especially business specific stuff) to a backend which JS queries to source data to operate over.

All of the current frameworks are intimately tied into display logic and that display logic is constantly in flux with shifting trends, device/accessibility support and shifting coupled technologies (css-flex, css-grid...). This lack of an isolation is causing people to jump frameworks to capture support for newer design trends and the like but... I think it's getting better. I'm not a front-end dev but react is the first offering I've seen that seems to really strongly reinforce a decoupling point between display and logic.

Really though, look at the realm of application development, in that realm users are accepting of crazy out-of-date UIs so the sterotypical "Oh this was definitely built with Java" (with substitutions for MFC and Qt) is sort of accepted. So, I may be off base.

All I know for certain is that there was a period in the 00s when I was really hopeful that all website design would be handled seamlessly by my designer coming in and throwing some style-sheets on everything and no changes to markup would be required - that time has passed and the responsive web is baking in a really strong assumption of native-application-like functionality, this isn't bad or good - it just is.

So, in summary, I'm still hoping that the majority of front-end work can shove a crowbar between the declaration of logic and the rendering, but I feel like the rate of UI change and shifting display thingies will forever outpace attempts to provide a unified toolset that actually captures the majority of intended uses.

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#55

I had primary been a C# dev, then switched to JavaScript/TypeScript for a few years. Lots of change in those years: JQuery, Angular 1, Angular 2, TypeScript, etc. Then I recently switched worked on a C# project. Other than a few Dot Net Core changes, it was basically the same, and easy to switch back to C# land. Not I am back in JS land. This time using Angular elements. When I left, I was getting used to declaring l…

Aha! And Angular is already one of those tech pieces that's "on the way out".

I've had similar experiences working primarily on the backend where paradigms may slowly shift but the tools for their declarations are _thankfully_ pretty stable.

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#57
post #13

As somebody that's in JS all day but rarely touches backend, hearing about go, rust, kubernetes, docker, etc make it feel like backend is similarly fast-changing. The difference seems to be in the narrative about the older tech. The "rails is still fine" crowd is loud, which is great. There is no equivalent for older JS tech. Though I would be willing to believe that's because things like jQuery are full of dated pat…

The beauty of React and other frameworks is that it separates the concerns of state and UI. I don't see it as a tool for making a fancy button or widget, I see it as a tool for guaranteeing that what the user sees is always what's actually going on in the logic. Too many times I've written something like a "clear" button or a "reset" button in jQuery, added an extra field, forgotten to include it in that clear/reset…

I see what you're saying, but in your example that would just be input type="reset".

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#58
post #31

I have impression that other way round, changes in js are one of the slowest amongst programming languages. We have lots of js in our project, and it's mostly the same js as when I first learned it in early 2000s. No ES6, because it's completely unsupported in Android Browser and IE. Why bother with transpiling for just shorter syntax for functions? We had Sprockets and I'm not sure if there's adequate transpiling of…

I understand where you're coming from, but you're basically talking about interpreter support here - not the language.

This would be like me taking the old Borland 4.0 C++ compiler and then telling you that C++ is SO slow to change. It hasn't moved since 1994!

Which is wrong. The language spec has clearly updated. ECMAScript is not defined by browser support, even if you should be taking browser support into consideration before choosing tooling.

Just because you're not choosing to use new language features doesn't mean they don't exist.

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#59
I think javascript is changing more rapidly because:

1. It's on the back-end and front-end.

2. Lots of corporate sponsorship of Node.

3. Adoption of other languages' functionalities (namely async/await from C#, sets from Python, symbols from Ruby (could be wrong here), hash rocket from Ruby/Scala).

4. Teams building their JS libraries to serve the unique needs of the team (Uber's fusion.js, React and Redux for Facebook, Google's AngularJs/Angular/Material Design).

5. Browsers converging on JS spec which allows for arguably more cross platform development.

6. Node is a "good enough" solution for managing IO when it was introduced (hesitating to say perfect because Ryan Dahl has mentioned that he would have done a lot of things differently and has introduced deno as means to correct what he thought were the warts of Node).

Re: Ask HN: Is all programming constantly changing or just front-end JavaScript?

#60

From what I could see, the amount of churn in the Javascript world is unsurpassed by anything in software or product, almost to an order of magnitude. I ended up being a product designer (my main, academic education), a frontend, and a backend with varying levels of expertise in my lifetime, so I have some direct experience. My current advice as of April 2019 is to keep calm, if you can stay away from JS, do it, if y…

I like your advice to avoid Webpack and prefer TypeScript, but I think the advice to lean away from JS in general is poorly-founded. JS is a powerful, portable language with lots of opportunities to add value. It’s a good language to have in your toolkit along with others, and you can make a good living by learning to write good JS programs.

That is true. I meant it as in: ‘If you can avoid writing something in JavaScript, do so’. Obviously, there are contexts where it is the only game in town — I have big hopes for WebAssembly for that reason.
Post reply on HN