Ask HN: Will JavaScript take over front-end? | Hacker News Reader

Ask HN: Will JavaScript take over front-end?

12 pointswhizzkid9 comments

I am seeing unbelievable amount of blog posts, releases, upgrades about Javascript frameworks and libraries during the last 12 months. I personally only used AngularJS 1.x for one of our projects, but did not have time to try React, or AngularJS 2.x.

My conclusion for Angular is that it takes 40% more development time to finish a project with AngularJS than without using it. We gained some speed for sure, but I think we could do better in the same amount of time with back-end optimisations.

- How was your experience with React or any other?

- Should I invest more time to keep me updated with one of them?

- I still think, front-end should just present the information, not the whole application logic. Am I missing anything? (I just discovered polymer-project and loving it so far!)

View on HN

> Will JavaScript take over front-end?

Has it not? A more appropriate question would be "When will it step down?"

> it takes 40% more development time to finish a project with AngularJS than without using it.

And by "without using it", does it mean you write in vanilla JS? I believe you jumped into conclusions way too early. Working with any technology will take long. It's not the actual writing of code that will take long, it's the learning (if you're a total noob), setting up (if you don't have scaffolding tools), and debugging (if you don't have tools). The actual work is just a fraction of what you're actually doing.

> How was your experience with React or any other

If you mean React alone, then it's like Angular with directives... alone. You'll have to debate on your router, your data flow library, your server-communication layer, your build tooling, your process. It's all the same thing under the guise of a different syntax.

> Should I invest more time to keep me updated with one of them?

Get to know all the libraries, but never try to use them all. Choose one and get things done.

> I still think, front-end should just present the information, not the whole application logic.

It's like saying JS should have stayed on the browser, but wait! There's Node.js (server), Espruino (hardware), FirefoxOS (OS), PhoneGap (mobile), NW.js (desktop). If everyone was thinking the way you do, these would have never been invented.

Thanks for your feedback, and I partly agree with you.

> It's like saying JS should have stayed on the browser

What I meant was, we don't need to re-implement the application logic in browser. Take an example of translation strings. You store them in your back-office and download the key-values to your browser and store them again so that you can parse it with Angular.

I am not against JavaScript, in fact I love that we can use it on server level, build mobile applications and etc. Maybe I could be more accurate on the title.

> I still think, front-end should just present the information, not the whole application logic.

I think you are absolutely right! Progressive enhancement is a foreign concept to some developers. They've forgotten that hyperlinks are the engine of application state.

I just disabled Javascript in my browser. We'll see how things go.

Loading an application and hydrating with data seems like the ideal architecture. Especially when your single application can run on the web, mobile, or a desktop. A choice between thin and thick clients seems a little mainframe versus PC. The web started as a page-based text-focused entity, but I don’t understand why it needs to stay there or why thin clients are the ideal pattern. Certainly first load & SEO can present challenges, but both these problems are going away with React/Angular2 server side rendering and Google’s progress with indexing web apps.

Maybe I’m missing something, but SPAs seem like the future (perhaps compile to JS or whatever, but still thick clients). The backend should be concerned with clean APIs to data and not with rendering the view. If people want to turn off JavaScript for a text only web, well some people still use flip phones and everything depends upon what you are building and for who and how quickly you can move in either paradigm. I’d suggest studying either the Angular or React ecosystem, but don’t expect SPAs to go away.

It's cliche but I think or hope JS will become the bytecode of the web and compiling to JS from your favourite paradigm be it OO, Functional or just JS with compile time type.

The resistance to this is most code is made for $ and the people with $ tend to prefer fungibility. JS devs are easier and cheaper to replace than Purescript ones. From the lens of developers as a list of buzzwords you can to grep this makes sense.

Frameworks get trendy but new languages have a hard time even though the learning curve may be no different.

I just hope somehow better languages than JS will win.

- In my experience, React is much better and faster and easier to use than Angular, but there are things better than React out there (Cycle, for example).

- I don't know.

- It depends on what is your application logic, but I think you are right for the majority of cases. However, presenting the data in a good way is probably more than 50% of any application (if it wasn't, everybody would be writing just CLI apps), that's why Javascript matters.

I totally agree that presenting the data is really important, but you don't really need a fullstack front-end framework with services, routing, and translation APIs to achieve that right?

No, that's why I said I think you're right. Perhaps routing is needed sometimes, but that is a simple thing, despite the pompous names these Javascript people tend to use. "Services" is just another pompous name for "doing HTTP requests".

Since used React 3 years ago (and specially Reagent/ClojureScript) can't ever look back, the only possible better way is Elm mainly because of compile time checks (but right now ClojureScript is too much superior)

This is just a personal story ! I don't want to offend anyones believes :)

Reply on news.ycombinator.com