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

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

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 139 posts

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

#111

Post by neurostimulant »

untog wrote: post #51
Jorge1o1 wrote: post #27

Earlier quoted context omitted.

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.

This is why I just use create-react-app and never bother to configure webpack manually. Create-react-app is getting better these days and I haven't found any reason to eject yet.

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

#112

Post by zackmorris »

prewett wrote: post #67

I think much of JS's churn has been the problem that the UI primitives (HTML) are unsuitable to what people want to do. When you can't even vertically center something without reading a bunch of web pages that tell you something like six different techniques, you can imagine that people are going to make a library to do make it easy to do. But since the foundation is crap, and good API design is actually hard, the re…

I agree with pretty much all of what you said. One thing I might change though, is that I'd prefer a copy-on-write (COW) metaphor for WebWorker and SharedArrayBuffer, similar to how Clojure state works. So you'd pass an array by value, but there would be no performance penalty unless values are mutated. I'd also like to eliminate shared state between threads and switch to channels like how Go or Erlang work. These should also be COW.

I feel that HTML/CSS is an evolutionary dead end. People think in terms of tables when they do desktop publishing. So forcing them to translate to CSS and back is a task for compilers, not humans. Most people working in web development today are too young to remember that this was all a solved problem in the 80s with WYSIWYG. We let the asynchronous nature of the internet determine the architecture of our markup, which was a mistake in hindsight.

I'd vote to rearchitect the web to be synchronous and run under a single-threaded runtime that makes no distinction between front and back end. Then let the runtime handle representational state transfer, a bit like Rsync but for the DOM. This would work like virtual memory (so the developer wouldn't have to worry as much about where state resides) and executation would block until a remote procedure call (RPC) is lazily evaluated deterministically without timeout or having to remain always connected.

Then with that prerequisite implemented, we could revisit fluid layout in a formal way, derived from first principles. This might mean transpiling things like SCSS variables to non-turing complete grammars (context-free grammars) like CSS. I'm a little foggy on the terminology for this so someone please correct me if I have it wrong.

In other words, we should be able to derive the position of our elements from other positions. So we should have a markup language like:

    elementX.center.x = body.center.x
    elementX.width = body.width/2
    myX = elementX.right
    elementY.left = myX + 1
But this would only be processed in one-shot mode. I think a markup like this could be created on top of HTML/CSS but it could be difficult due to quirks.

Without basic metaphors like these, web development can never move from being a craft to a field. It will forever be reduced to hand waving and having to drink the kool-aid. Which is fine for now, but will add increasingly more friction as the web development market gets more saturated.

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

#113

Post by Tiktaalik »

I'm 10+ years as a game developer working largely in UI and I'm just learning JS now to make use of a new framework built by Coherent Labs. Previously the main tool set was Scaleform, which makes use of Flash scripting. I don't feel game dev has changed that much. Only very, very recently has it started to change at all.

In game dev land it's just C++ or C# if you're a unity shop, and things haven't changed too much. For a long, long time things weren't different at all, but with the new C++11, and C++14 things are getting a bit different. Right now I'm working in a fairly modern codebase, and it's been a learning experience for many of my coworkers to get up to speed on some of the new features introduced with C++14.

Probably the biggest change is occurring with the way that games are developed, with Object Oriented development practices kinda going away and games being developed in a more Data Oriented way using Entity Component Systems (ECS). Unity for example currently has an ECS system in preview release.

It's been pretty interesting to start learning more of the JS ecosystem. Even though I've only been working at it for a few months I've already had the tea table upended on me by our partners deciding to redo some stuff in typescript, so there's another new thing for me to learn.

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

#114

Post by catpolice »

I think the churn rate is higher with front-end stuff, but I don't think it's really due to any special property of the technology. Honestly, I suspect that the rate of change in a given ecosystem is roughly correlated with the number of programmers actively working in it.

The number of front end web developers has been skyrocketing since the late 90s - a lot of people who've been in the industry for a while don't realize how many more of them there are compared to 5, 10 or 15 years ago. There's been growth elsewhere too, but just in the past few years the number of new bootcamp front-end developers I've seen seems to sort of swamp most other sectors.

I suspect that since much of the innovation in that space has been driven by open source efforts, the amount of change is in part driven by the number of eyes on problems and the number of people interested in trying new things. There are a jillion new JS projects on github every month, and some of them catch on, so there are always new options.

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

#115

Post by mattbreeden »

ricardobeat wrote: post #103
mattbreeden wrote: post #75

Earlier quoted context omitted.

It does just work. Until you want to use something that the core devs don't use. Like having the most popular front end framework be unusable for at least 6 months: https://github.com/parcel-bundler/parcel/issues/645 Often you'll need to hope some third party made a plugin or make one yourself, which isn't really any different than using webpack, but the webpack ecosystem is much larger. I struggled through parcel fo…

Looks like that particular issue was closed in July 2018? Also, anybody who considered that feature important enough could have fixed it. It's not rocket science. Certainly 10x easier than when that magical something in the webpack build chain breaks.

> Looks like that particular issue was closed in July 2018?

Yes, after being open for 6 months.

> Also, anybody who considered that feature important enough could have fixed it. It's not rocket science.

First off, maybe- but I was responding to the comment of 'it just works', so that's not relevant. My entire commentary was on 'it just works'. It doesn't really 'just work' if users have to implement their own plugins and fix their own bugs on super popular JS integrations.

Second off, a user did fix it, and it took the devs a month to respond to the PR- so you're still at the mercy of the core devs.

> Certainly 10x easier than when that magical something in the webpack build chain breaks.

And this I'd just have to disagree with you on. Webpack has way more eyes and as a result I have had one issue (bug) with it which had already been fixed. I had many issues using Parcel beyond the one I linked of the most popular front-end framework not working.

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

#116

Post by davimack »

Basically nothing down in database-land has changed, from what I can tell. Added features, but everything in those languages is designed to be backwards compatible (unless you're talking PL-sql, which has had some major shifts, to bring it in line with the rest of the world). And that's having done database stuff since Paradox for DOS and Access 2.0 (I think - might have been 3, but ... ancient days, anyway).

For the rest of my stack, it's mostly Visual Studio, and it's shifted a bunch over those 25 years: VB5 -> VB6 -> VB.NET until .NET 2.0 -> C#

Whatever changes there have been in HTML & JS, I've gone through, plus some of the DHTML weirdnesses that came along the way.

I'm going to say that, other than databases, there's about the same amount of needed change. And even with databases, those do change, in that you might want to get a bit more of a life and use something other than MSSQL for a change, which amounts to such a shift as the others have been.

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

#117

Post by ungzd »

schwartzworld wrote: post #102
ungzd wrote: 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…

Obviously if you are deliberately avoiding new language features, you're still going to be writing the same JS as you were in the early 2000s. I could write Python 2.7 and it would be pretty much the same thing. However, a lot of ES6+ features offer more than just syntactic sugar. For example, arrow functions remove a lot of weirdness regarding 'this'.

There's two javascripts: one that really works in browsers, and it's still ES5. And other javascript, that works on abstract virtual machine implemented inside Babel. And only the first one is "real" javascript.

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

#119

Post by nostrademons »

All programming is constantly changing, but web front-end is probably among the subfields changing fastest. It seems to have slowed down significantly since about 2014 or so.

I've been programming professionally since 2000, and I'll say the biggest change is actually that the market structure has changed. Back then, programming specialties were primarily divided by platform: you were a "mainframe programmer" (probably working with COBOL, RPG, DB2, etc.), a "UNIX programmer" (C, C++, awk, sed, perl, shell), a "Windows programmer" (Win32, MFC, later .NET), a "Java programmer", a "Mac programmer" (Pascal, C, later Objective-C, with the Mac Toolbox and later Carbon/Cocoa frameworks), an "avionics programmer" (Ada, C, with a good knowledge of physics), a "scientific programmer" (Fortran, Matlab, later Python/NumPy/SciPy), etc. The idea of a "web programmer" was just getting started, and the technologies (Coldfusion, ASP, JSP, PHP, Flash) were very immature, and largely outgrowths of the platform you used to run the webserver on.

Sometime around 2009 every software system became a distributed system, with multiple clients and a wide range of backend services running on different boxes, and so specialties bifurcated by your role within that ecosystem. So now you have web front-end engineers, mobile engineers for Android & iOS, back-end engineers, data scientists, data engineers, deep-learning experts, infrastructure engineers, SRE/DevOps, security people, scalability/performance experts, etc. You're even starting to get blockchain engineers, though they don't fit into the current distributed systems model.

Some of these fields change less quickly than others; frontend (particularly web), deep-learning, and blockchain have been changing rapidly, while things like infrastructure, backend, SRE, and scalability change a little less rapidly. All of them are changing, though. It's the legacy platforms like the mainframe engineers and avionics engineers that haven't really changed much - but the flip side is that the current hypergrowth in the software industry has largely passed them by.

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

#120

Post by zbentley »

rhlsthrm wrote: post #92
rco8786 wrote: post #33

It's all changing, but it seems that front-end JS is changing the fastest . That's (IMO) due to a handful of reasons. But three standout in particular... 1) The state of Javascript's standard library is getting better but still pretty bad. So people continually reinvent new ones. 2) Every company with a frontend (see: Every Company) has to work with Javascript (esoteric compile-to-js aside) on the front-end, so the s…

Agree with the first two points, but do you really think "new developers" are the ones who are creating the "ideas/platforms/frameworks/etc/etc"?

I do. Maybe not the tools that become popular, but new developers often consider publishing their first side project or personal tool to be a valuable milestone.

I think a lot of green developers' JS tools don't make it to the mainstream, but they certainly do make it more difficult to filter hype from substance. That's not a valid reason to discourage contributions: more people hacking on more stuff and making more discoveries, even at the cost of fragmentation, is far more valuable than putting a chilling effect on contributions (and there are other ways to mitigate fragmentation).

Post reply on HN