Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

171–180 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#171

Earlier quoted context omitted.

"...but let's have a productive conversation." Okay, I'll bite. With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Where does the churn end if it's not pointless? Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly im…

> If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight. You just described Windows 10's UWP.

Yeah, I think it must drive some people at Microsoft crazy that they have a better technical solution and no one uses it

Re: The Deep Roots of JavaScript Fatigue

#172

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else. I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web…

Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples.

Please do. I am interested in seeing more detail in your post.

Re: The Deep Roots of JavaScript Fatigue

#173

The only horse to bet on at the moment is jQuery. I know, I know. I'm old and I don't do exciting things. I work mainly on a niche product in a boring field. But you know what? My site works with IE8+. I can deploy code without much thought as to what is going to break. My deploy script takes 15 seconds. I don't have to rewrite anything every 3-6 months. I can update something that hasn't been touched in 2 years and…

jquery spaghetti code can be quite readable if you're smart about layout... group things into sections, arrange everything sequentially where possible, etc etc I've had to do a fair amount of complex UI and, frankly, I don't see why people stress so much about it. I rarely end up with more than a screen's worth of event handling code (which is a small amount of pasta, really), and things flow around fairly intuitivel…

It sucks; I'm 31, but the only people I can relate to here are the old men. Nope, 31, you're an old man now.

Re: The Deep Roots of JavaScript Fatigue

#174
post #168

Earlier quoted context omitted.

I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things, but setting that aside: The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind. It al…

> I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things Would everyone is discussing the high quality of the Emperor's new clothes, is it productive to point out that he is, in fact, naked as a jaybird? At some point we have to face up to the simple truth tha…

Wanna back up that beautiful rhetoric with some actual objective reasoning as to why; HTMl, Javascript, the DOM are "bad" and some ideas on the way forward?

Re: The Deep Roots of JavaScript Fatigue

#175

Every time I think of Javascript language concept, I think about Lisp, and every time I think of "javascript fatigue" I think of Lisp Curse. I think that the core feature of JS and Lisp is the fact that there's no concept of "compile time". Declaring classes, methods, even entire language concepts like promises happens entirely in runtime, and the language is soft to touch that every programmer with a healthy dose of…

> Lisp is the fact that there's no concept of "compile time".

The first Lisp compiler was finished in 1960.

Naturally Lisp has the idea of 'compile-time'.

> Declaring classes, methods, even entire language concepts like promises happens entirely in runtime

Let's see. I have a file with these contents:

    (defclass foo () (a b c))

    (defmethod bar ((a foo) (b foo))
      (+ (slot-value a 'a)
         (slot-value b 'b)))
Now let's use a Lisp compiler (!), here SBCL:

    $ sbcl
    This is SBCL , an implementation of ANSI Common Lisp.
    More information about SBCL is available at .

    SBCL is free software, provided as is, with absolutely no warranty.
    It is mostly in the public domain; some portions are provided under
    BSD-style licenses.  See the CREDITS and COPYING files in the
    distribution for more information.
compiling the file:

    * (compile-file "compile-test.lisp")

    ; compiling file "compile-test.lisp" (written 16 MAR 2016 07:34:51 PM):
    ; compiling (DEFCLASS FOO ...)
    ; compiling (DEFMETHOD BAR ...)

    ; compile-test.fasl written
    ; compilation finished in 0:00:00.020
    #P"compile-test.fasl"
    NIL
    NIL
Wow, the sbcl Lisp compiler just compiled the file and generated the code for a class and a method using that class.

Let's see if sbcl knows about the class:

    * (find-class 'foo)

    debugger invoked on a SIMPLE-ERROR:
      There is no class named COMMON-LISP-USER::FOO.

    Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

    restarts (invokable by number or by possibly-abbreviated name):
      0: [ABORT] Exit debugger, returning to top level.

    (SB-PCL::FIND-CLASS-FROM-CELL FOO NIL T)
    0] 0
Oh, it doesn't know about the class. We are no longer in 'compile time'. The class was only known during 'compile time', a concept you said Lisp does not have. sbcl seems to have it. Funky.

But we can load the generated machine code:

    * (load "compile-test")
    STYLE-WARNING: Implicitly creating new generic function COMMON-LISP-USER::BAR.

    T
    * (find-class 'foo)

    #
    * 
Now it knows about the class.

> Would anyone expect anything else from language with such capabilities?

Lisp has a lot of code bases which are large and maintained for 2 or more decades. Common Lisp has especially been designed to support compilation in various forms and to support the development of complex/large systems. One gets a lot of support from compilers like sbcl for doing so.

Re: The Deep Roots of JavaScript Fatigue

#176
post #65

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept. Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem…

to me, ember is the only source of peace in js framework wars. I do not use it yet.(cause i am js noob). but if i require a full blown js framework, ember will be my choice.

You can learn it quickly from this free tutorial: http://yoember.com

Re: The Deep Roots of JavaScript Fatigue

#177

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else. I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web…

I would upvote this comment 10 times if possible.

Re: The Deep Roots of JavaScript Fatigue

#178
post #130
post #109

"No other language does anything remotely resembling that kind of thing". Have you ever worked on a Java EE project?

I did JSF for 4 years, along with the rest of the Java EE stack. Glassfish web server. There was never churn like this . I was pretty enthusiastic about front end dev for years. I'm pretty burnt on it now though.

I didn't mean the churn (Java EE could do with more churn) I meant in terms of setting up a project and the number of dependencies.

Re: The Deep Roots of JavaScript Fatigue

#179
post #174
post #168

Earlier quoted context omitted.

> I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things Would everyone is discussing the high quality of the Emperor's new clothes, is it productive to point out that he is, in fact, naked as a jaybird? At some point we have to face up to the simple truth tha…

Wanna back up that beautiful rhetoric with some actual objective reasoning as to why; HTMl, Javascript, the DOM are "bad" and some ideas on the way forward?

It is "objectively" "bad" because if you bring javascript up in certain social circles involving programmers everyone huffs and puffs. I've heard people time after time who've never stepped foot out of a Java IDE complain about how hard it was for them to write something "simple" and "basic" in javascript. Not to claim that there is any real veracity in the wisdom of the crowd, but there are hundreds of thousands of programmers writing working, functional, useful apps in javascript every damn day. People can say that fact is DESPITE the language features but these people ignore that if you want to actually reach customers you have to use the most popular runtime of all time - the browser.

Being unable to have a conversation about the ecosystem because the language isn't to your liking or preferences speaks to me of a closed-off mindset, which as everyone knows is a great trait for programmers to have /s.

Re: The Deep Roots of JavaScript Fatigue

#180

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

"...but let's have a productive conversation." Okay, I'll bite. With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Where does the churn end if it's not pointless? Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly im…

That would actually be a very awful future. I like a linked web full of text. Flashy this and flashy that and app for this and app for that is all blah. Most things don't actually need to be apps.
Post reply on HN