[HN Gopher] Modern Javascript: Everything you missed over the la...
___________________________________________________________________
Modern Javascript: Everything you missed over the last 10 years
(2020)
Author : EntICOnc
Score : 576 points
Date : 2021-05-15 15:15 UTC (7 hours ago)
(HTM) web link (turriate.com)
(TXT) w3m dump (turriate.com)
| flowerlad wrote:
| 10 years ago JavaScript was an ugly language, with its clunky
| prototypal inheritance and so on. Modern JavaScript is a
| beautiful language, however, especially when enhanced with static
| typing as in TypeScript. So much so, that Stanford has replaced
| Java with JavaScript for its introductory programming course [1].
|
| [1]
| https://web.stanford.edu/class/cs106j/handouts/01-GeneralInf...
| BenjiWiebe wrote:
| I feel that being nicer than Java is a pretty low bar.
| qsort wrote:
| Which version? I feel like Java >=11 is absolutely fine, but
| if you're talking about earlier versions you have a point.
| lanstin wrote:
| Someone brought up "while we do this move to EKS maybe it
| would be a good time to port from Java 8" and the whole
| room (virtual) groaned.
| xhkkffbf wrote:
| A number of schools like Dartmouth did this more than 15 years
| ago.
| criddell wrote:
| Picking a language to teach programming and concepts in
| computer science presents an interesting conundrum. Do you pick
| a commercially relevant language (which most students want) or
| go with one that might be better for academic purposes? I
| probably lean mostly towards the former because time spent
| learning something like Eiffel feels somewhat wasted.
| dehrmann wrote:
| To me, the dilemma is between a language that's easy to learn
| and one that is useful once you learn the language. Most
| languages have too many warts and footguns to be easy to
| learn, but learning a toy language isn't good, either,
| because it's not useful.
| klibertp wrote:
| No! Eiffel should be the default OOP language for any kind of
| course. Being forced to think about pre- and postcoditions
| and invariants _by the language_ is a really good thing for
| beginner programmers. While the syntax is somewhat verbose
| (mainly because of using keywords instead of most
| punctuation) Not teaching about Design by Contract is yet
| another billion dollar mistake in computer science. There are
| DbC libraries or frameworks for just about any language, but
| only very few programmers know about its existence, which
| leads to criminal underutilisation of the technique in the
| industry.
|
| I can't be sure, but I think there's a lot of thought, at
| least, behind selecting a particular language for an
| introductory course on programming. I don't know which
| language I would choose, but I'd like something that would
| broaden the horizons of student as much as possible. It could
| be Mozart/Oz or something similar.
| qsort wrote:
| On the other hand, there are concepts (closures, objects,
| pointers) that come more naturally with some languages, and
| you absolutely need to learn the concepts even if you don't
| end up using the language.
|
| Don't pick one, pick a healthy mix.
| lanstin wrote:
| No one should have a computer science degree and not know
| multiple languages and multiple programming paradigms.
| Prolog, lisp or scheme, C, JavaScript, Haskell. The long term
| task of the professional software developer is to learn new
| stuff. Helps if your awareness of the cool things you could
| learn is already broad. I cannot explain how wrong it is to
| graduate with Java only and think that is sufficient. To be
| honest, I would also want people to understand the halting
| problem and Godel's incompleteness theorem's proof, as
| understanding the equivalence of apparent different systems
| that can handle the integers is very fundamental. And these
| days some knowledge of distributed theory is also good, the
| Lamport time clocks paper and so on. Unless the student is
| ambitious and doesn't really like programming and just wants
| to program for a few years and then get into management or
| something like that (product? bizdev? I'd that a thing?) they
| will go thru many iterations of interesting new technologies.
| The brain that enjoys learning mind-bending shit will have a
| broader conceptual base and a better chance to see how lisp
| macro type things can help with k8s configs.
|
| Or while lazy argument evaluation might not be in your
| language, having it in your tool box for message processing
| design or you know evaluation of user preference rule sets
| against an event might be helpful.
| geuis wrote:
| Javascript is still based on prototypal inheritance. The newer
| class syntax is just a wrapper.
| dragonwriter wrote:
| > Javascript is still based on prototypal inheritance.
|
| Protoypal inheritance and class-based inheritance where
| classes are themselves first-class objects aren't really all
| that different, anyhow.
| axguscbklp wrote:
| I think that it was beautiful 10 years ago, too, if you mainly
| used a subset of it, relying heavily on closures and avoiding
| constructors and "this" as much as possible. I think that
| prototypal inheritance is elegant but in any case, there was
| never much reason to use any inheritance syntax to begin with
| other than perhaps in rare cases where one wanted to really
| maximize performance. As for static typing, while it has its
| uses, the idea that it makes things more beautiful is
| subjective.
|
| Arrow functions really are a great bit of syntactic sugar. I
| know that they are more than that, but since I avoid "this"
| anyway, for me they may as well just be syntactic sugar. As for
| the "class" keyword, I find it to be utterly pointless but of
| course, tastes vary.
| ksml wrote:
| Actually, the class you linked was an experimental class, and
| we ended up going with Python instead. (source: I was the head
| TA for that class)
| galangalalgol wrote:
| Why a dynamically typed language to learn with?
| ksml wrote:
| I think there were two main reasons: choosing a popular
| language (JS and python happen to be among the most
| popular, accessible languages) and pedagogical simplicity
| (it's nice to avoid burdening beginners with extra syntax
| when they're already struggling to learn other things).
| Some unscientific evaluation showed that students picked up
| static types just fine in our second programming class
| (which is in C++)
|
| Personally, I think we should be teaching static types and
| I pushed for Typescript, but it didn't happen.
| cogman10 wrote:
| Always an option to push for something like mypy. That'd
| at least give students exposure to types (even if they
| don't have to write them)
| jefftk wrote:
| _> I think we should be teaching static types and I
| pushed for Typescript_
|
| Another option would be to introduce Python types:
| def square(x: int) -> int: return x*x
|
| http://mypy-lang.org/examples.html
| bruce343434 wrote:
| I started programming in Lua which is dynamically typed.
| It allowed me to experience why a type system would be
| nice. I'm sure if I had started with a typed language, I
| would have written it off as antiquated and unnecessary.
| kaba0 wrote:
| I am sure I'm absolutely nowhere near your knowledge and
| expertise, but please bear with me sharing my opinion :)
|
| I think Java fits better as an introductory language --
| it is similarly popular as JS and python, and while I'm
| sure static typing can be picked up easily, I think
| fighting the compiler for a likely-correct program in the
| end is a better alternative than understanding why the
| program failed with this given input and not with another
| -- so my not-backed-up-by-teaching opinion is that
| dynamic languages are not necessarily a great fit. It
| also features the basic OOP concepts, and modern java can
| showcase plenty of FP ones as well.
|
| On the other hand, going lower level is similarly
| detrimental, I've taken a class where C was used, and
| that way you get cryptic runtime errors as well, while
| memory management is not that hard to pick up later on.
| ASalazarMX wrote:
| > I think Java fits better as an introductory language
|
| Oh no, for a beginner just setting up the environment is
| a huge hurdle. Sun's Java downloads page is utterly
| confusing, and the IDEs are monstrous and complex too.
| Past that, they have to learn about the JVM and compiling
| to JARs before they can even run their first program.
| Leave all that housekeeping to us seasoned, soul-crushed
| developers ;)
|
| If we're starting to teach compiled, boilerplate-ridden
| laguages to beginners, why not jump straight to C++ or
| Rust?
| bccdee wrote:
| I think wrapping all your code in OOP boilerplate is
| probably too much for an intro course. One of the nice
| things about Python is that hello world is `print("Hello
| world")`. No `public static void main(String[] args)`, no
| nothing. And then on top of that, you can _add_ your
| functions and classes and whatnot, but it 's easier to
| wrap your head around a zero-fluff entry point.
| bradlys wrote:
| Intro classes don't need to overburden the student. The
| biggest hurdle for students is thinking like a computer.
| You start introducing all these extra things to just get
| going and it becomes even more difficult.
|
| Explaining to students what public static void main means
| is pretty annoying and seeing cryptic syntax littered
| everywhere does not help students when they're first
| learning.
|
| Dynamic languages make much more sense to beginners
| because the idea of what a variable represents is more
| abstract to them than tangible to you. To them, they
| don't see the value of types because they're not going to
| be building large programs where that is going to matter.
| They know what their functions return and take in,
| because they probably only have one or two. Performance
| and compiling is also not as much of a concern, etc...
| flowerlad wrote:
| > _Explaining to students what public static void main
| means is pretty annoying and seeing cryptic syntax
| littered everywhere does not help students when they're
| first learning._
|
| C# has solved that with "top level statements" [1]. If
| Java added that then problem solved, right? It's a simple
| addition.
|
| [1] https://docs.microsoft.com/en-us/dotnet/csharp/whats-
| new/csh...
| kaba0 wrote:
| I agree with you on the overburden part, but not on the
| dynamic lang part. My very minimal experience is that the
| hardest thing to get right as a beginner (or even as an
| experienced developer) is to be able to follow the flow
| of your code (Maybe introductory courses should employ
| the debugger?), and the exact state it has at a given
| point, eg. at an exception. Restricting the valid states
| imo helps understanding. As well as not having to debug
| at all at first, but the compiler notifying what is wrong
| immediately.
| hurflmurfl wrote:
| I think that you're right in that it's hard to compose
| all those parts of your program together without
| accidentally mistaking a `Query` for a `string`, or god
| knows what. I'm helping a friend learn web development,
| and most of the issues they get stuck for long time at
| are solved by making sure that functions you are calling
| are returning what you think they are.
|
| On the other hand, I feel that most of the lessons I've
| learnt that have really stuck are the ones where I first
| do a thing wrong, and then find how to do it right. In a
| similar fashion, letting the student create a steaming
| pile of ... and then giving them a solution to their
| troubles in a later course feels like a good idea.
|
| I personally have come a full circle: starting with
| things like Pascal and C++, then going to C# and finding
| type inference interesting, then getting a HUGE boost to
| my knowledge and skills when I found Python and JS. A few
| years later, my personal preference is having static type
| checking, and Typescript does that pretty well, in my
| opinion. However, every time I remember how much I
| managed to learn and understand about programming when I
| switched to Python, I think that if I had to teach
| someone, I'd pick something expressive, intuitive and who
| cares about types when you really want to maximize
| exposure.
| ylyn wrote:
| > I think fighting the compiler for a likely-correct
| program in the end is a better alternative than
| understanding why the program failed with this given
| input and not with another
|
| In my experience (having TAed a CS1 course) I think it is
| better for introductory students to be able to figure out
| what they are doing wrong, rather than having a compiler
| point it out to them.
|
| In the first class, we want to focus on computational
| thinking and being able to then express their ideas into
| programs. So we intentionally use very little of the
| language (JS in my case), because the language is not the
| point of the course.
|
| OOP and all these models of abstraction and code
| organisation come later, once they have a good grasp of
| the fundamentals.
|
| This particular course I taught is only taken by CS
| freshmen, so that other commenter's remark (that we
| should teach a popular language) doesn't apply here.
| kaba0 wrote:
| > I think it is better for introductory students to be
| able to figure out what they are doing wrong, rather than
| having a compiler point it out to them.
|
| That's implying they will find it out, instead of having
| a finished project that can randomly crash with a
| slightly different input.
|
| Also, the compiler is basically just a shorter eval loop.
|
| But I agree with you that OOP should only come later
| (though using objects is inevitable in most languages)
| dclowd9901 wrote:
| Having gone the other way (starting with JS and moving
| into languages like Objective C), I actually disagree.
| Having a solid foundation in software writing helped me
| when I started to learn about the somewhat obtuse
| abstract concepts that tend to be coupled with learning
| strict typing.
|
| Then, when learning Flow and Typescript, where I'm
| expected to have a meta understanding of typing itself, I
| was ready to go.
| bachmeier wrote:
| > it's nice to avoid burdening beginners with extra
| syntax when they're already struggling to learn other
| things
|
| As someone that teaches college students to program (not
| in a CS department) that statement is correct but doesn't
| provide the full picture. It's good to get rid of the
| extra syntax if and only if you don't need it - and that
| means you're intentionally limiting what you're teaching
| them.
| extra88 wrote:
| > you're intentionally limiting what you're teaching them
|
| Yes, that's the point. It's an introductory class,
| choices have to be made about what to teach when.
| bachmeier wrote:
| Well, of course, but the point is that avoiding syntax is
| not a great criterion for defining the fundamentals of
| programming. A couple orders of magnitude more important
| is to decide what concepts are useful for beginning
| programmers to know.
| flowerlad wrote:
| Python is much more limited as an introductory language than
| JavaScript. JavaScript is very versatile. Need to write
| server-side logic? Use JavaScript and Node. Need to write a
| native iOS app? Use JavaScript and React Native. Need to
| write a command-line utility? Use JavaScript and Node again.
| Need to make your web page interactive? Use JavaScript in the
| browser. Python is versatile as well, but not to the extent
| of JavaScript. JavaScript, when type-checked using TypeScript
| also scales better to larger projects and development teams.
| The one area where Python shines is in machine learning,
| where Python is a de-facto standard. But here too, Python is
| facing stiff competition from Julia.
| nojito wrote:
| None of these are requirements for a intro class
|
| Python excels as a teaching language.
| flowerlad wrote:
| The introductory course is not taken by just CS students.
| In most colleges, introductory programming courses are
| open to all majors. For many students this will be the
| only programming course they will ever take. Why wouldn't
| you teach a language that is not only well designed, but
| also versatile, instead of just being a good "teaching
| language"?
| maleldil wrote:
| > not only well designed
|
| JS, and its multitude of foot-guns, is not something I
| would call 'well designed'.
| sigzero wrote:
| You are describing Python.
| thrdbndndn wrote:
| Can confirm. As someone who never formally learn
| programming, the moment I learned Python I never touched
| C# or Javascript again at will.
|
| The syntax of Python is just way, way more
| straightforward. I do agree it may be a disadvantage for
| serious software engineering, but as a hobby? I will pick
| Python over others all day every day.
| maleldil wrote:
| It's an introductory course. The goal isn't to train
| students to be able to do all those things. I'd wager most
| professional programmers aren't able to do more than a
| couple of them well. There's more to front-end/back-
| end/CLI/mobile than just the language.
|
| > But here too, Python is facing stiff competition from
| Julia
|
| You severely overestimate the significance of Julia in this
| field. It's a great language, and I wish it were more
| popular, but Python still dwarfs it.
| [deleted]
| 6gvONxR4sf7o wrote:
| You seem to have limited visibility into python's
| versatility. It's much much more than you describe, and I'm
| saying that as someone who hates python with a passion (and
| has been gainfully employed writing python for most of my
| career).
| neonological wrote:
| Why did you guys switch to python instead of javascript?
| XCSme wrote:
| Some other important features and browser APIs released in the
| last ~10 years: Web Workers, WebGL, OffscreenCanvas, Typed
| Arrays, Web Audio, Web Notifications, WebRTC, Websockets.
| dleslie wrote:
| Does anyone have a handy reference for those, that they would
| recommend?
| meheleventyone wrote:
| https://developer.mozilla.org/en-US/
|
| MDN is amazing, coming from games and working on a web
| project the level of documentation is incredible.
| irrational wrote:
| It should be considering who is backing it.
|
| https://www.infoq.com/news/2017/10/microsoft-google-
| mozilla-...
| meheleventyone wrote:
| Even big companies such as those supporting MDN have
| terrible developer documentation. MDN is something quite
| special even given who supports it.
| XCSme wrote:
| To be honest, MDN docs were really good even before it
| started getting support from other companies.
| csbartus wrote:
| I don't really know. For me, it's like PHP, or worse. Yes, this
| modern javascript, the old one is even worse.
|
| I'm trying to get rid of it and move to a functional language
| like Clojure (actively learning) or perhaps Rescript.
|
| Meantime I found Ramda.js and so far so good. No more javascript
| fatigue.
|
| Ramda, React, and Typescript looks like a good patch for the
| short term. On long term I definitely need something integrated.
|
| And something integrated with the running environment. Node,
| Webpack, Babel are a real pain.
|
| I think the future is bright. We've learnt the pain making all
| above work, and work together. Now something really new is
| coming.
|
| Statically typed, functional (the good parts), focussing on
| problem solving, and leaving the quirks behind.
| bronlund wrote:
| That whole Node thing was a huge mistake and people are starting
| realize it.
|
| Using JavaScript on the server is bad for so many reasons and the
| complexity Node introduces for doing the simplest of things, is
| just just mind-boggling.
|
| For the future, I'm betting om Elixir with Phoenix LiveView,
| pushing server-side rendered HTML through WebSockets.
| lukicdarkoo wrote:
| Professionally, I do embedded and robotics, but once a year I
| find an excuse to create a simple web application (to stay
| updated). Every time, I get impressed by power and simplicity of
| the web technologies in general. In JavaScript those are things
| mentioned in the article + WebComponents. For CSS those are
| flexboxes, grids, and animations. In my opinion, React made a
| revolution with hooks and contexts. I love the direction in which
| the web world has been going!
| biinui wrote:
| May you kindly point me where to start learning robotics, and
| recommendation for a starter robot arm? Maybe ~$300 if
| something worthwhile exists at that price range. Take care.
| fukmbas wrote:
| Web tech is shit
| antris wrote:
| >In my opinion, React made a revolution with hooks and contexts
|
| I agree with your overall point 100%, but to be honest nothing
| in React was / is innovative except for the virtual DOM
| diffing, but even that is becoming increasingly irrelevant as
| apps are moving towards more and more reactive architecture.
| React made a huge impact on web dev and deservingly so, but all
| of the other ideas have been implemented and used on the web
| before.
|
| Of course it's great that React is bringing some of these good
| ideas to mainstream, but they've been there way before they
| have been distributed along with a VDOM algo.
| warent wrote:
| > but all of the other ideas have been implemented and used
| on the web before.
|
| Is this true? I've worked in web dev for like 6 yrs now and
| React has provided a significant number of concepts and
| technologies I'd never seen before and still dont see
| elsewhere.
|
| For example, JSX. Yes, it originated in php but React was its
| first time being implemented in the frontend.
|
| Also the concept of hooks and functional components. The fact
| that you explicitly define side-effects in the render of a
| function, with memoization or execution dependent on
| arbitrary state, is a new invention as far as I'm concerned.
| antris wrote:
| Yes, yes and yes. All of these concepts are variations of
| what has been done before in a number of ways. Mostly by
| "FP academics" who "live in fantasy land", until everyone
| else starts using them too.
|
| Transpiling, hooks and components have all been done (and
| done better) before React came along, but often they were
| laughed out as esoteric toys that have nothing to with
| "real programming". It's just hard to teach these concepts
| until you actually use them, and it's hard to get people to
| use these concepts unless they are included in something
| else that you need.
|
| The same happened early with React, both JSX and VDOM were
| laughed at by many developers because "they looked stupid"
| to people who didn't understand them and were used to one
| way of doing things. MVC+jQuery+templates was the flavour
| of the day.
|
| Same thing with TypeScript, FRP and so on.
|
| Most likely, whatever concept is gaining momentum today,
| it's an exact or approximate copy, or in rare cases a novel
| remix of what has been researched 10-20 years ago, and used
| in production for 5 years before you heard about it on HN
|
| These people who like to apply category theory etc. in
| programming have heard this mocking of their work as stupid
| esoteric fantasy (and then seeing them become mainstream
| later) so often that they literally called one of their
| specs "Fantasy Land"
| https://github.com/fantasyland/fantasy-land
|
| There's still lot of work to be done. JavaScript doesn't
| even have proper immutable data structures natively, which
| would be a _REAL_ low hanging fruit.
| ketzo wrote:
| Well, isn't there something a little "revolutionary" about
| mainstream adoption of cutting-edge techniques?
|
| After all, like you suggest, things like functional
| programming and monads have existed for quite some time. The
| thing that makes React special is how rabidly people adopted
| it, and continue to adopt their major updates.
| antris wrote:
| >Well, isn't there something a little "revolutionary" about
| mainstream adoption of cutting-edge techniques?
|
| Taking the example of hooks, React has hooks because it was
| released with a bunch other stuff in addition to the VDOM,
| people started using those things as a (poor) framework,
| shot themselves in the foot repeatedly and finally hooks
| had to be introduced as a fix on top of that.
|
| Calling that band-aid "revolutionary" or cutting edge
| technology, kind of sounds wrong. They never would have
| been there if it weren't for the bloated original release.
| ptx wrote:
| > virtual DOM diffing ... is becoming increasingly irrelevant
| as apps are moving towards more and more reactive
| architecture
|
| Could you expand on this? What was it that necessitated DOM
| diffing before, and which architectural changes are making it
| irrelevant?
| user3939382 wrote:
| The Winchester House was continuously added onto by a huge
| construction crew for many years after the death of Mrs.
| Winchester's husband. She believed her psychic who told her she
| had to continuously add onto the house to repent for the people
| killed by her family's rifles during the civil war.
|
| The result is a sprawling, very crazy looking house that no one
| would have sat down and designed upfront. I think of JavaScript
| as the programming language equivalent of this house.
| nsonha wrote:
| Most programing languages old enough have that problem: C#,
| php, C++.
|
| And modern js does not look crazy, it's the es5 and bellow that
| was a bit wacky. Typescript is much cleaner than the 3
| languages I mentioned, my opinion.
| TchoBeer wrote:
| Python is pretty old and (imo) doesn't have that problem
| finiteseries wrote:
| That's probably why they said most, not all.
| dehrmann wrote:
| Oh, yes it does.
|
| Built-in method and class naming is wildly inconsistent. OO
| is bolted on, typing is bolted on. While not "the
| language," the GIL and what it means for parallelism
| (multiprocessing is a shit show) was a mistake.
| Rapzid wrote:
| > And modern js does not look crazy
|
| Heh, read the VueJS 3 code base.
|
| I haven't done much at the level of optimization I think is
| going on there, and this is Evan's third iteration so I'm
| guessing there is a lot of insights baked into it, but dang
| if it's not hard to wrap your head around. Even if you check
| it out and use VSCode to _try_ to figure it out.
|
| Individual sections of code make sense. But it's like a
| deconstructed hamburger and you've never seen a hamburger in
| your life.
| kaba0 wrote:
| That's on the library, not the language itself. I'm not
| particularly fond of JS, but I think it has become a very
| acceptable language over the years.
| rikroots wrote:
| To pick up on your tangent with a tangent, I think Tim Powers's
| take of the Winchester House mythology, in his book Earthquake
| Weather, is my favourite re-interpretation of the story.
|
| As to Javascript - I like the language because it a language
| that fits best with my way of thinking about code. I'm not sure
| if that's a good thing to admit.
| ertucetin wrote:
| ClojureScript, that's what you've missed...
| qwertox wrote:
| It's a great compilation, but I'd like to have each item to have
| a link to the related caniuse.com page.
|
| Sometimes I can use Array.forEach() and sometimes not, and I
| don't know why, even if I'm only using Chrome. So I just use
| lodash.
| sandrot wrote:
| Try using Array.from(arrayish).forEach() to convert the thing
| that looks like an array to an actual array. For instance, you
| can't use map() on a NodeList (document.querySelectorAll
| returns a NodeList), so you have to use Array.from(NodeList) to
| first convert it to an array.
| dragonwriter wrote:
| > Try using Array.from(arrayish).forEach() to convert the
| thing that looks like an array to an actual array.
|
| Spread syntax is my goto for that:
| [...arrayish].forEach(...)
|
| But, it being JavaScript, there's probably a subtle
| distinction in where Array.from(arrayish) works and where
| [...arrayish] works.
| rm_-rf_slash wrote:
| JavaScript has grown a lot in the last 10 years, the last ~5 in
| particular with ES5/ES6.
|
| There are still "fucking JavaScript" moments but those are few
| and far between compared to what they used to be. The "..."
| operator in particular has been hyper useful for neatly modifying
| complex objects without turning into spaghetti code.
|
| SPA+node/express is a pretty solid stack these days because of
| these improvements. I no longer find myself missing Rails for
| Ruby's syntactic sugar and knowing that operations on the server
| will work exactly the same on the client has been great for
| browser console debug sessions.
|
| The holy grail would be for HPC JavaScript libraries to allow the
| same ease of implementation to use something like NVIDIA RAPIDS
| (especially RAPIDS itself) as easily as we get with Python. Given
| how far js has come, I don't think that's an unrealistic
| proposition.
| lanstin wrote:
| Adding existing c libraries to python is trivial, and very C
| like experience for memory management etc. adding existing C
| libraries into node engine requires more skill and delicacy due
| to the C++ and the relatively more complicated v8 way of doing
| things.
| DrFell wrote:
| JavaScript is a great browser scripting language because it's the
| only browser scripting language. That's a whole realm of good
| times, and people can and should go nuts with it there.
|
| The problem started a decade or so ago with Node. Too many people
| only learn JavaScript, become psychologically dependent on it,
| and they all collectively took it too far outside of a browser.
|
| ECMAScript is a general purpose standard, but it was invented
| retroactively. Node is not ECMAScript in a server-side ECMAScript
| engine, it's JavaScript in a browser JavaScript engine. That's
| just too much of a force fit, and has wasted too much potential
| for me to say anything positive about it.
| hn_throwaway_99 wrote:
| Couldn't disagree more. I was a Java programmer for my entire
| career until about 2015 or so when I switched to Node, and
| shortly thereafter to TypeScript.
|
| I've commented this many times before, but having a system
| where _everything_ is on the same tech stack (i.e. front end in
| TypeScript with React, back end with TypeScript on Node) has
| resulted in gargantuan productivity gains, especially for a
| small team where it 's trivial for people to cross front end to
| back end seamlessly. For contrast, I know many teams with a
| backend in Python and a frontent in React/JS, and I've worked
| on some teams with that setup. In my opinion it's virtually all
| downside compared to a backend in TS, as Python and TS are
| quite similar from a web programming perspective (I'm not
| referring to Python's advantage in data science tooling), so
| all it basically is is a barrier to your front end folks being
| able to make small enhancements on the backend quickly.
|
| Furthermore, TypeScript is a great language and I find myself
| being so much more productive in it than I was in Java,
| especially when it comes to refactoring.
|
| JavaScript most definitely has its warts and head scratchers
| after being around for 25 years, but I feel like most of these
| oddities (truthy/falsey, typeof null === 'object', undefined
| vs. null, etc.) can be learned in an hour and written on a half
| page.
| dvt wrote:
| > Furthermore, TypeScript is a great language and I find
| myself being so much more productive in it than I was in
| Java, especially when it comes to refactoring.
|
| I don't really see how. TS doesn't seem to solve _any_
| annoying problems I previously had in Java. As a concrete
| example, it would be nice to have the concept of a DTO as a
| first-class language feature, but alas, I find myself
| constantly casting and re-casting, plucking, or writing
| endless wrappers to make sure properties trickle down (or
| up). Hell, sometimes I just give up and use `any`. I mean,
| this is a web-first language that has no concept of sending
| objects over the wire.. okay then.
|
| TypeScript's generics system is cute, but I think it's mostly
| academic. And did you look at the toolchain? To get TS
| working, you need babel or ts-node or webpack, and like 3
| different .json config files. Importing a package without TS
| support? You need to write some stubs yourself in types.d.ts.
| In fact, the best parts of TypeScript are actually JS
| (await/async, arrow notation, spread operator, etc.).
| hn_throwaway_99 wrote:
| This biggest "aha" benefit I get from TypeScript is that it
| is structurally typed, while Java is nominally typed. In my
| experience it has proven much easier to refactor in TS
| because I just need to ensure my objects have all the right
| properties. With Java if I have a Thing1, but a library is
| updated to add just a single new property so now there is a
| Thing2 type, well now then all the places I need a Thing2 I
| have to completely copy over from Thing1 - I can't just add
| the property and be on my merry way. This happened to me
| many times in my Java career - I still think I have PTSD
| having to do a Jersey 1.x upgrade to a Jersey 2.x version
| across a large codebase. It was a nightmare I've never had
| anything come close to with Typescript.
|
| > I mean, this is a web-first language that has no concept
| of sending objects over the wire.. okay then.
|
| I have no idea what you're talking about here. I use
| GraphQL with auto typegen of my TS types and I get typed
| data objects everywhere.
|
| > TypeScript's generics system is cute, but I think it's
| mostly academic.
|
| TBH this remark just makes me thing you really don't know
| much about TS. I use generics extensively, find them very
| helpful and are easy to use.
|
| I'll give you the point on initial TS setup being non-
| trivial. Hopefully advances in tooling (things like Deno,
| which I'm not actually a huge fan of, or other projects
| like Rome) will make this easier, but even then I found
| this to be a "one and done" cost.
| layer8 wrote:
| There is a reason for nominal typing though, because
| nominal types represent an interface contract that
| generally goes beyond just having the right type
| signature, but instead it is also about semantics. It's
| about the parts not covered by the type system, which the
| compiler therefore can't check. It depends on the kind of
| objects you are generally working with, but beyond pure
| data I find nominal typing preferable, because it makes
| it explicit that an implementation X conforming to
| interface contract Y is not just a matter of type
| signatures.
| eurasiantiger wrote:
| Note that the upgrade pain with Java was not due to
| typing; rather, it was due to using a library directly
| instead of creating a class to interface with it. In
| other words, inadequate abstraction.
| city41 wrote:
| The shock wave that TS sends through a JS stack is hard to
| ignore. It's really annoying. Every tool added TS support
| in a slightly different way and you always have to keep it
| in mind no matter what you're doing. Sadly it's just the
| reality we gotta face. I'm hoping Rome can live up to the
| hype and be helpful here.
| adamscybot wrote:
| I think esbuild is basically already doing most of what
| Rome promises
| dvt wrote:
| Oh man, so true, between TS mangling and whatever
| framework you're using (Vue/React/etc.), the stack trace
| ends up being literally worthless. It's kind of funny to
| think about: when something goes wrong, I don't even look
| at the trace (which is 100% what you'd do in any sane
| language), but rather I just go back and look at the
| "last thing I changed."
| city41 wrote:
| Ah that is true as well. When I said stack I meant like
| Babel, Storybook, Webpack, Jest, etc. But yeah JS stack
| traces aren't so fun these days.
| wonnage wrote:
| This is just you not being familiar with the language
| adamscybot wrote:
| People are talking the other points to death but on the
| toolchain front, you might enjoy
| https://github.com/evanw/esbuild, which is rapidly gaining
| in popularity. Just 1 thing for bundling, transpilation
| etc. And its terrifically fast since its written in Go
| (ironic I know).
| city41 wrote:
| At my last company I created a few tools that became key to
| my org, which was front end/JS oriented. Being able to write
| them in JS meant anyone could contribute fixes and features
| trivially, with zero ramp up time. That is a really nice
| benefit of Node. Imagine if Rails developers couldn't use
| Ruby for their tooling. Node really filled a nice gap here.
| [deleted]
| smoldesu wrote:
| Either way you try to argue this, it's hard to make the case
| that Java/Javascript is _better_ at any of those things than
| another language. Productivity be damned, your dinky jar file
| will get smoked on almost every quantifiable level if you pit
| it against against a C++ or Rust rewrite. What GP is saying
| is that the only reason people praise Javascript is because
| it 's a unique language, and I think it's a fair appraisal.
| Javascript is in a class of it's own, for better or worse,
| and since it has no real competitors, it's easy to dismiss
| detractors.
|
| Whenever I encounter Node, issues almost always follow.
| Whether it's NPM's delightfully useless error messages or a
| stream of neverending warnings filling up stdout, it quite
| literally never fails to cause a problem. Maybe Node should
| focus on saving it's reputation, because I for one run in the
| other direction of it. Hell, especially in the case of Node,
| I hope that Deno comes to replace most of it's core
| functionality. Putting up with half-assed software on a half-
| functional runtime only leaves me with a quarter of the
| patience I started with.
| creshal wrote:
| > For contrast, I know many teams with a backend in Python
| and a frontent in React/JS, and I've worked on some teams
| with that setup. In my opinion it's virtually all downside
| compared to a backend in TS
|
| Is there any Typescript backend framework as mature as
| Django?
|
| > Python and TS are quite similar from a web programming
| perspective (I'm not referring to Python's advantage in data
| science tooling), so all it basically is is a barrier to your
| front end folks being able to make small enhancements on the
| backend quickly.
|
| So on the on hand, the languages are "quite similar", yet it
| cannot possibly be expected that frontend people learn more
| than a single language? Something doesn't add up here.
| mxkvl wrote:
| idk why people mentioned Next.js which is more Front End
| framework than Back End, but no one mentioned Nest.js. It
| is not old as Django but I think Nest is nearest framework
| to RoR/Django in Node.js
| williamdclt wrote:
| Definitely. NextJS isn't a "backend framework", it's a
| server-side rendering framework that has some backend
| abilities to handle simple use-cases.
|
| NestJS is the most full-featured Node framework, but it's
| lightyears behind Django. Yet I'd still use it given the
| choice between both, because I prefer Typescript so much
| better than Python and having a single language through
| the stack is a game changer, enough that I'm willing to
| compromise on the frameworak.
| hn_throwaway_99 wrote:
| Our backend is Apollo GraphQL in TS, and it is has provided
| us numerous benefits:
|
| 1. The strong typing of GraphQL is a huge boon for
| correctness and security.
|
| 2. Easy to autogen TS types from GraphQL schema, so we can
| use the same types throughout our codebase, frontend and
| backend.
|
| 3. Apollo has lots of features that make it easy to scale
| projects.
| creshal wrote:
| And yet - Apollo advertises its easy Python
| interoperatibility right on the front page, as one of the
| features that makes scaling easier.1
|
| GraphQL arguably makes decoupling frontend and backend
| languages even easier than classic REST APIs, since the
| GraphQL schema can serve as single source of truth across
| language barriers.
|
| 1 https://www.apollographql.com/blog/graphql-python-api-
| comple...
| hn_throwaway_99 wrote:
| OK, let's unwrap that:
|
| > And yet - Apollo advertises its easy Python
| interoperatibility right on the front page
|
| Yes, absolutely, there is great support for GraphQL in
| many different languages.
|
| > , as one of the features that makes scaling easier.1
|
| To be clear, that is your own commentary and I didn't see
| anything in the Apollo site that said implementing in
| Python makes scaling easier. I.e you seem to be implying
| that somehow implementing in Python is better for
| scaling, but there is no background to support that.
|
| > GraphQL arguably makes decoupling frontend and backend
| languages even easier than classic REST APIs, since the
| GraphQL schema can serve as single source of truth across
| language barriers.
|
| Yes, I totally agree with that. If you are, say,
| providing an API to other developers GraphQL is a great
| choice for a number of reasons, one of which is that
| there is great language support across pretty much all
| languages.
|
| But if you are starting a project _within_ a company, and
| have the luxury of choosing technologies, having the same
| ecosystem on the front and back ends makes it much easier
| for people on either team to go across that "boundary"
| if necessary. This is not just me hypothesizing. For the
| majority of career, which really started right when web
| apps started taking off, there was a separate language on
| the backend (Java for the majority of my career, but also
| sizable stints where Ruby and Python were the backend
| languages). Yes, most backend folks understood JS and
| CSS, and most frontend folks could understand the backend
| languages, but it was still a huge barrier to people
| being able to contribute across teams such that it rarely
| happened. It's only in the past couple of years where
| I've been in a "TypeScript everywhere" org where I've
| seen the gigantic change in the team dynamic that this
| allows.
| spiderice wrote:
| You are interpreting GP's comment very uncharitably, to the
| point that it actually becomes a completely incorrect
| interpretation.
|
| GP is pointing out that it is advantageous to have a single
| language on both front end and backend. And somehow you
| arrived at "developers cannot be expected to learn more
| than one language."
|
| There ARE big advantages to having the exact same language
| (as opposed to similar languages) on both client and
| server, especially in an SPA where you want to render
| something initially on the server, but then update it using
| the same logic later on the client.
| creshal wrote:
| > GP is pointing out that it is advantageous to have a
| single language on both front end and backend. And
| somehow you arrived at "developers cannot be expected to
| learn more than one language."
|
| Because he considers it a "barrier" to have to switch
| between languages to do backend-only changes. Which is a
| completely different use case than the one you're
| describing.
|
| For an SPA where you're essentially doing frontend on
| both ends, yes, that's obviously easier when you're only
| doing it once.
|
| But that's not the general case, and I'd argue that
| transitioning between different mental contexts for
| components you're not regularly touching is always going
| to be a hurdle to developers, regardless of the language
| used. Blaming it on the language is an useless red
| herring.
| aranchelk wrote:
| Having to write the same logic twice in two languages,
| and then making sure both implementations behave the same
| way. I don't know if I'd use the word "barrier", it's
| certainly a significant pain in the ass.
|
| The classic example is of course validation, but plenty
| of other places it can come up.
| onei wrote:
| Perhaps I'm overthinking things and HTML does this
| naturally, but is there something for rendering that is
| what Swagger/OpenAPI is to APIs? Some way of specifying
| HTML that can be both rendered (and read back for inputs)
| by multiple implementations.
| Jarwain wrote:
| I feel like switching languages adds extra friction too.
| Switching contexts is still a hurdle, but using the same
| language can make the hurdle shorter.
| wonnage wrote:
| It's definitely a barrier to have to switch languages.
| You might be super familiar with Chrome's debugger UI
| (which is excellent, btw), and feel lost when suddenly
| getting dropped into IntelliJ's.
|
| Also, what if you just have frontend developers who
| straight up don't know Java or vice versa? I don't see
| how having a shared language could ever be a _bad_ thing.
| austincheney wrote:
| Learning is great. It expands horizons, potential, and
| current capabilities. Learning is not producing though.
| Learning is a cost center. If you want to increase
| productivity start by minimizing required learning. That
| exchange is called _usability_.
| gentleman11 wrote:
| Interesting phrasing, I like it. But you can also reduce
| the cost by making learning easier, whether with good
| interfaces or naming, or just good docs
| creshal wrote:
| > Learning is not producing though. Learning is a cost
| center.
|
| Spoken like a true MBA.
|
| > If you want to increase productivity start by
| minimizing required learning.
|
| Deciding your tech stack solely on avoiding having to
| train people for a few days sounds like a terrible way to
| organise projects. Is your employee churn so bad that you
| can't afford even this little familiarisation?
| austincheney wrote:
| There are two fundamental practical problems with your
| thinking.
|
| 1. Employers don't train on languages/frameworks. In most
| circumstances employees are expected to learn on their
| own or from a prior employer before applying for a job.
| Worse, the last place I interviewed only asked about
| learning from the current employer while never asking
| about self learning outside the office.
|
| 2. Employees, in many cases, believe they can cheat
| learning by using a tool or framework. That is largely
| due to a lack of boundaries and experience in a given
| environment or platform resulting in low trust of peers
| and the technology.
|
| If you want to require learning then provide sufficient
| learning material expecting a predefined structured
| outcome.
| creshal wrote:
| We _are_ training our employees. Learning the ropes of a
| new language /framework enough to make easy changes is
| trivial, so why wouldn't we? Much better than crippling
| our choices in software stacks we can use.
| dfabulich wrote:
| > Is there any Typescript backend framework as mature as
| Django?
|
| No TS framework is as old as Django, and if you're looking
| for "Django for TS" you won't find exactly that, but
| Next.js is the current reigning champion for server-side
| frameworks right now, according to the popular "State of
| JavaScript" survey https://2020.stateofjs.com/en-
| US/technologies/back-end-frame... Next is a "both-side"
| framework, allowing it to do stuff you just can't do in
| Django.
|
| If you want something much thinner than Next (and thus much
| thinner than Django), there's Express.
|
| > yet it cannot possibly be expected that frontend people
| learn more than a single language?
|
| The problem isn't learning two languages, it's interop
| between two languages.
| Kinrany wrote:
| IIRC Next is a backend-for-frontend framework, not a
| general purpose one. Unless that changed?
| 1_player wrote:
| Come on, as someone that has worked professionally with
| Django and Next.js, the only similarity they have is that
| they're both web frameworks. Django is light years ahead
| than Next.js is it's not even funny.
|
| Here's a very simple metric: Compare the Next.js
| documentation (https://nextjs.org/docs/getting-started)
| with Django's
| (https://docs.djangoproject.com/en/3.2/contents/) -
| better yet, compare the actual API reference and exported
| classes/methods.
|
| Yes, Next.js is one of the better Node/Javascript
| frameworks, but it's incredibly inferior to any other
| established framework in Python, Java, PHP, Elixir, etc.
| -- unless you only need a static page with some dynamic
| React components. I am in the unfortunate position of
| maintaining a more complex Next.JS app, using most of its
| "advanced" features such as dynamic routing, SSR,
| GraphQL, API, and it's the most painful project I have
| ever had the misfortune to work on, because the upstream
| interface and API is so woefully under-documented, buggy,
| changes too quickly it's hard to stay up-to-date, etc.
| etc. I weep every time someone on this forum suggests to
| start a new project with Next.js.
|
| In theory Javascript on the server and client is a
| productivity boost, in practice it is not by any measure.
| nicoburns wrote:
| The similarly named (but completely different) Nest.js is
| much closer to Django than Next. Still a ways behind in
| terms of maturity, but it seems to be more or less on the
| right path.
| Silhouette wrote:
| _I am in the unfortunate position of maintaining a more
| complex Next.JS app, using most of its "advanced"
| features such as dynamic routing, SSR, GraphQL, API, and
| it's the most painful project I have ever had the
| misfortune to work on, because the upstream interface and
| API is so woefully under-documented, buggy, changes too
| quickly it's hard to stay up-to-date, etc. etc._
|
| Would you give some specific examples of where you've
| found Next to be buggy or where it's introduced breaking
| changes? We're evaluating a number of possible Node-
| related libraries for a new project right now, including
| Next, and there's no substitute for hearing from people
| with real experience of using them in production.
| sillyquiet wrote:
| > Yes, Next.js is one of the better Node/Javascript
| frameworks, but it's incredibly inferior to any other
| established framework in Python, Java, PHP, Elixir, et
|
| This is like saying a screwdriver is incredibly inferior
| to a impact hammer.
|
| > In theory Javascript on the server and client is a
| productivity boost, in practice it is not by any measure.
|
| This is in direct contrast to my personal experience
| across multiple projects and teams. In practice it _IS_ a
| productivity boost, because JS does 99% of what anybody
| needs a web server to do.
| 1_player wrote:
| > This is like saying a screwdriver is incredibly
| inferior to a impact hammer.
|
| I'm sorry, isn't the goal of web frameworks, including in
| this category Django, Next.js, Phoenix, Laravel, Nuxt.js
| to respond to HTTP requests and present users with an
| HTML page representing a document or a more complex web
| application?
|
| > because JS does 99% of what anybody needs a web server
| to do
|
| Brainfuck is Turing-complete and does 100% of what any
| other language can do as well. I stand by the fact that
| having to "know" only one language is great in theory,
| but in practice it's not. Node and client JS/Webpack are
| a leaky abstraction it's not very hard to get yourself
| cut with. In non trivial modules, you'll find it hard to
| be able to use the same code verbatim on the client and
| the server. Then add the complexity of server-side
| rendering, serialisation/hydration, React suspense, code
| that mysteriously works only when server-side rendered or
| viceversa, etc. and you'll ask yourself "is this really
| worth it?"
| sillyquiet wrote:
| > code that mysteriously works only when server-side
| rendered or viceversa, etc.
|
| It sounds like your opinion of server-side javascript
| comes from experience with badly written and poorly-
| understood server-side javascript, because none of that
| jives with my experience in writing node-based web
| applications.
| creshal wrote:
| > No TS framework is as old as Django, and if you're
| looking for "Django for TS" you won't find exactly that,
| but Next.js is the current reigning champion for server-
| side frameworks right now, according to the popular
| "State of JavaScript" survey
| https://2020.stateofjs.com/en-US/technologies/back-end-
| frame...
|
| So by that graph, it has a good chance of being entirely
| deprecated and/or abandoned in the next 3 years, what a
| wonderful foundation for a backend.
|
| And it doesn't even have any support for an ORM? Neither
| does Express? Having to hand-write every single query and
| migration like it's 1999 again is hardly the cutting edge
| of IT stacks...
|
| > The problem isn't learning two languages, it's interop
| between two languages.
|
| How so?
| btgeekboy wrote:
| Regarding ORM, it's typically paired with Sequelize or
| Prisma. (I'm personally using the latter.) I've built
| Django apps in the past (it's actually how I learned
| Python in the 2.5 days), but what's nice about Node/TS is
| that the frameworks are more loosely coupled so you can
| pick/choose your best components. For example, while I
| mentioned the ORMs above, you can even go one step
| further and use a backend headless CMS like Strapi, which
| will get you the ORM + admin interface that you'd get
| from Django models.
| creshal wrote:
| > what's nice about Node/TS is that the frameworks are
| more loosely coupled so you can pick/choose your best
| components.
|
| For about two weeks, then one of them becomes deprecated
| again and you have to migrate everything all over
| again...
| lhnz wrote:
| This isn't really true though. There are plenty of open-
| source modules in Node which were released more than 5
| years ago and are still in use today. People only move to
| new ones, when they are clearly better. What exactly is
| wrong with that?
| creshal wrote:
| > There are plenty of open-source modules in Node which
| were released more than 5 years ago and are still in use
| today.
|
| And how stable was their API over the last five years? It
| hardly counts if over 5 years the APIs change so much
| they're basically different libraries at the end.
|
| Django's code churn for even complex projects is on the
| order of single digit hours per year at worst, the
| remaining 99.99% of time can go into delivering things
| customers care about.
|
| I can't say I've seen that sort of stability in anything
| Javascript-related, apart from maybe jQuery projects.
| (Which of course have their own problems because jQuery
| is the wrong abstraction usually.)
| nicoburns wrote:
| On the backend, Express has had a very stable API for 5+
| years. On the frontend, React has. However, stable or not
| there's nothing that competes with Django/Rails/Laravel
| in the Node ecosystem.
| maxrev17 wrote:
| I kinda get this but syntax is one thing, understanding the
| context you're working in is another.
| inopinatus wrote:
| If you've mainly worked in TS then it explains the blind
| spot, because JavaScript is chock full of awful missteps
| built up over the years. There's a reason my copy of
| "JavaScript: The Good Parts" is extremely slim next to its
| sibling, "JavaScript: The Definitive Guide".
|
| So you've come to it at a time when the syntax and
| capabilities have a popular subset that actually starts to
| fulfil the early promise. And yet, one may still be
| enormously critical of the anemic and inconsistent standard
| library, and don't even get me started on the horrifying
| dependency shitshow of the node ecosystem that cripples
| maintainability of anything over 18 months old.
|
| Just because we're all holed up in the throne room, doesn't
| mean there aren't monsters still roaming the sewers, just a
| few levels down, as illustrated by the article linked above.
|
| As for isomorphic code, I strongly encourage my competitors
| to write backend code in the same fashion as the front-end,
| because the resulting tight coupling and special-case-driven
| technical debt makes them easy to outmanoeuvre when markets
| shift. And if they're reading this then please also consider
| microservices, graphql, and nosql data stores whilst you're
| at it, for the same great reasons.
| skeletal88 wrote:
| It would be amazing if there were other languages available
| for front-end development in the browser, no? Even if you
| think that JS is so wonderful, then having competition would
| still be good, or no? Currently JavaScript has a monopoly in
| the browser and monopolies are always bad. Bad for innovation
| and everything else.
|
| It would be better if there were no oddities in a language.
| One of the reasons why everyone hates PHP is that it is full
| of inconsistencies, odd design choices, weird naming and
| unexpected behaviour. JS has at least some of these.
|
| If there was a second of third language available in the
| browser, then that too could be used to develop back-end
| applications and would have the benefits you describe - that
| you can use the same language for both stacks etc. For
| example - if you could front-end stuff in Python, would it be
| amazing or bad? Or would the current JS devs just fear for
| their jobs because of it?
| tester756 wrote:
| There are, you can write C# in browser easily.
| twic wrote:
| > having a system where everything is on the same tech stack
| (i.e. front end in TypeScript with React, back end with
| TypeScript on Node) has resulted in gargantuan productivity
| gains
|
| How so? Is it just about being able to use a single set of
| tools, libraries, habits, etc? Or are there particular things
| which are easier when the language is common? Are you sharing
| code between front-end and back-end.
|
| I do very lightweight front-end coding these days. It's
| usually some variation on populating and updating a table
| from a websocket, maybe with some simple filtering and
| toggling in response to user interaction. There, i can't
| think of any particular advantage to having both ends in the
| same language, but then mine is quite an unusual use case.
| eyelidlessness wrote:
| There's a lot of compelling reasons to share code
| _particularly_ at network boundaries. Using something like
| io-ts /zod/etc gives you simple, declarative, type safe
| validation. Being able to share that behavior is an
| enormous productivity boost in and of itself.
| twic wrote:
| Sharing validation for forms is definitely really nice.
|
| It feels like it should be possible to do that cross-
| language, generating some JS validation rules from Java
| annotations, say, but i have never seen it done.
| hn_throwaway_99 wrote:
| Mainly it has to do with teams. In most orgs there is
| something analogous to "a backend team" and "a frontend
| team", because the concerns and expertise are quite
| different.
|
| Oftentimes, however, a frontend dev may need some small
| extra bit of data or functionality from the backend, and
| vice versa. If the ecosystems are very different, then the
| amount of time it takes to set up that separate ecosystem,
| remind yourself of the relatively minor syntax difference
| e.g. between TS and Python, update your dependencies, etc.
| can be a big barrier, so often the answer is to just throw
| a ticket over to the team on the other side and wait.
|
| If, on the other hand, you can just quickly get into the
| other codebase, make a small PR and get it reviewed
| quickly, it can drastically improve the team's overall
| productivity.
| twic wrote:
| I've always had front-end and back-end owned by the same
| team, and in the same repo, despite being in separate
| languages. The repo has a single build script which
| builds all parts of the project, whatever language they
| are in. Implementing almost any feature involves touching
| both front-end and back-end code, so people stay fresh.
| All of this seems like table stakes to me.
|
| Maybe some organisations have separate teams working on
| the two parts of an application, which honestly just
| seems stupid, but that's not a necessary consequence of
| using different languages.
| sillyquiet wrote:
| I agree with this - EXCEPT:
|
| In a backend where you need a heavy-duty, multithreaded
| process to handle long-lived computations, node is _probably_
| not the way to go unless you want to pay for all the extra
| instances you 'd need for the same amount of load. In my
| experience, for example, a java-based graphQL server (that
| spawned multiple connections to various services) needed much
| much less in the way of resources than the node equivalent
| serving the same amount of traffic - AND the latencies were
| generally much better with the java server, depending on the
| size of the JSON payloads that it was handling.
|
| All that being said, you can certainly architect your way out
| of that problem and I imagine a relatively small percentages
| of web applications even HAVE that problem.
| hn_throwaway_99 wrote:
| I agree with all of what you said. Note in terms of
| "architecture your way out of that problem", that's exactly
| what we did. We have an eventing architecture that uses
| PubSub to publish to serverless functions that can then do
| heavier processing asynchronously. And for us, this wasn't
| a compromise, this architecture has a number of other
| benefits.
|
| But again, I definitely agree with what you've written,
| right tool for the job.
| pricci wrote:
| Where can I read more about that architecture you
| aretalking about?
| mattacular wrote:
| Not op but I assume they mean: a main web server is
| scheduling large jobs in the background by publishing an
| event to whatever pub/sub system you want to use (there
| are many!), lambdas can be subscribed to this system so
| they trigger off these events and publish a corresponding
| event back when they're done that the web app is
| subscribed to etc.
| bobthepanda wrote:
| > For contrast, I know many teams with a backend in Python
| and a frontent in React/JS, and I've worked on some teams
| with that setup. In my opinion it's virtually all downside
| compared to a backend in TS, as Python and TS are quite
| similar from a web programming perspective (I'm not referring
| to Python's advantage in data science tooling), so all it
| basically is is a barrier to your front end folks being able
| to make small enhancements on the backend quickly.
|
| How big of a problem is this?
|
| At the end of the day all that really matters is that the
| external representations that get handed off are the same and
| that everyone makes the same assumptions. Given the same set
| of fields manipulating a POJO with Java streams is not all
| that different from using modern Javascript on a blob.
| gentleman11 wrote:
| Typescript makes refactoring easier in what way? Can you do
| renames without error prone string search and replace? Can
| you get good autocompletions with ts? If so, that would be
| really nice
| Jarwain wrote:
| Yup! Especially using VsCode, which feels optimized for TS
| development. Click the var you want to rename, hit F2,
| rename it, and it renames all instances of the var. If
| you're renaming an import, it'll do it across all the files
| automagically. Moving a file? Imports get updated too!
|
| Plus you've got MS's intellisense powering autocomplete.
| Unfortunately, I don't think it can recognize different
| foods, but as long as you've typed your variables the
| autocomplete is pretty good!
|
| EDIT: the OP had a typo, saying food instead of good, for
| context as to why I made a food joke
| bcrosby95 wrote:
| None of this is better than the experience in Java
| though, which is what they were comparing it to. Maybe
| they were using shit tools?
| Jarwain wrote:
| The gp made this comment
| (https://news.ycombinator.com/item?id=27168048).
|
| > This biggest "aha" benefit I get from TypeScript is
| that it is structurally typed, while Java is nominally
| typed. In my experience it has proven much easier to
| refactor in TS because I just need to ensure my objects
| have all the right properties. With Java if I have a
| Thing1, but a library is updated to add just a single new
| property so now there is a Thing2 type, well now then all
| the places I need a Thing2 I have to completely copy over
| from Thing1 - I can't just add the property and be on my
| merry way. This happened to me many times in my Java
| career - I still think I have PTSD having to do a Jersey
| 1.x upgrade to a Jersey 2.x version across a large
| codebase. It was a nightmare I've never had anything come
| close to with Typescript.
|
| Not so much refactoring as upgrading, but tis an example
| of why duck typing is kinda nice
| lhnz wrote:
| Yes to all of your questions.
| dclowd9901 wrote:
| You forgot to ask, "can you get program flow analysis on
| top of static analysis for free?" To which the answer is
| also yes.
| williamdclt wrote:
| It's a bit sad that the bar is so low. If you don't have
| these, what is your editor even doing for you? Might as
| well use Notepad
| dfabulich wrote:
| Yes, both work.
| dcposch wrote:
| The first post also misses something fundamental about modern
| software: servers programming is becoming more browser-like.
|
| > Node is not ECMAScript in a server-side ECMAScript engine,
| it's JavaScript in a browser JavaScript engine. That's just
| too much of a force fit
|
| And what makes V8 a "browser JS engine"? A focus on:
|
| - rapid startup. Code starts running immediately, JITs
| quickly. The VM is designed for latency, not just for
| throughput.
|
| - excellent sandboxing. The VM is designed to run untrusted
| code.
|
| - no blocking code. Designed for callbacks and promises. No
| threading, no thread.sleep(), no mutex, etc. Makes is much
| easier for non-expert developers to write fast & reasonably
| correct code.
|
| Now look at things like Cloudflare Edge workers, Lambda etc.
| Modern server environments share all of those same design
| goals.
|
| Server-side JS/TS not only has the advantage of a single
| codebase. It also brings the design and engineering
| advantages of a browser VM to the server.
| kaba0 wrote:
| Your examples doesn't really read as a prototypical server
| application.
|
| Rapid startup: lambda is a tiny subset, and not really
| server application. A server app could take minutes and
| would still be okay, because they are designed to run for a
| long time. Even in case of scaling minutes are more than
| okay since deploying a new instance takes a similar amount
| of time.
|
| excellent sandboxing: you usually only run your own code
| connected to db and other very privileged services. If
| there is a vulnerability it is a very big problem with or
| without sandbox
|
| no blocking code: i'm not up to date, but node doesn't have
| a strong parallelism story at all, compared to the JVM, Go,
| .NET
| Kiro wrote:
| The only reason I'm using node.js is because I can do this:
| let num = 0; route('/url').post(data => num++);
|
| What other languages can I do this in that are better? I simply
| want to have a variable I can access and mutate from inside
| closures and let it live in memory without the need for
| databases or file systems.
| merb wrote:
| every language?
| ptx wrote:
| To be fair, threads complicate things.
| franklampard wrote:
| I am professional who used python, Java in my Career, and
| TypeScript is simply the best.
|
| "Too many people only learn JavaScript, become psychological
| dependent o it " is simply a false narrative from people who
| are stuck with obsolete web dev tech stack and refuse to learn
| better tools
| koonsolo wrote:
| > Node is not ECMAScript in a server-side ECMAScript engine,
| it's JavaScript in a browser JavaScript engine.
|
| Why would your custom ECMAScript server be any faster or more
| stable than any of the existing browser engines? If you look at
| the resources behind those engines, I don't know who would
| match that effort doing the same on the server.
| paulryanrogers wrote:
| My guess is the browser JS engines are optimized for quick
| compilation and execution. While a backend engine could
| optimize for longer, persist runtime.
| overgard wrote:
| 10 years ago I would have agreed with you, but in recent years
| Javascript (and moreso Typescript) are just exceedingly
| pleasant to use. I'm using Typescript in backend services
| despite knowing Python and C# well just because I like it.
| vletal wrote:
| I can imagine that the original argument does not apply to
| the languages which compile to JS. But IMO the fact that
| there is so many derived languages covering the mess which JS
| is only supports the argument against it.
| nicoburns wrote:
| TypeScript is just JavaScript with type annotations. The
| runtime semantics are identical. JavaScript itself has
| improved to the point where it's great to work with, and
| arguably the nicest of the common dynamically types
| "scripting" langauges (python, ruby, PHP, perl).
| gmac wrote:
| Completely agree. I used to work mainly in Ruby, and I
| guess I miss its rich standard library, but overall
| TypeScript is such a joy to work with that now I use it
| for almost everything.
| believeinskills wrote:
| Well I know plenty of people that are similar to me in that in
| our early years, we asked for resources and help, and the
| response that was constantly given was "use what you know,"
| which was bad advice for people who made websites who were
| looking to program.
|
| It's no wonder Javascript is the only thing used. I actually
| love React and ES because it's the first time I feel like a
| real programmer and not someone just writing Javascript. I
| don't really care about people's opinions about JS, I simply
| use what works.
|
| If you hated Javascript, maybe the anit-javascript community
| should have wrote blogs, made videos, and created content in
| the same way that the Javascript community did.
| bastawhiz wrote:
| > Too many people only learn JavaScript, become psychologically
| dependent on it, and they all collectively took it too far
| outside of a browser.
|
| Do you have any evidence for this? Because there's plenty of
| reasons why you'd share the same code in the browser and the
| server. Being able to do SSR and sharing validation logic are
| two huge and obvious reasons. Ever try to exactly duplicate
| validation rules between the browser and PHP? What about when
| they use weird regexp rules?
|
| I have a site builder codebase that renders previews instantly
| as you make changes, then uses the same code on the server to
| render the HTML and CSS for visitors. That would be otherwise
| be outright impossible to do without writing the same code
| again in another language.
| zozbot234 wrote:
| > Being able to do SSR and sharing validation logic are two
| huge and obvious reasons. Ever try to exactly duplicate
| validation rules between the browser and PHP? What about when
| they use weird regexp rules?
|
| PHP is adding support for FFI to any C ABI-compatible
| language, and you can run the exact same code in the browser
| via emscripten or a WASM polyfill. As a bonus,
| emscripten/WASM compiled code will also be more efficient in
| the browser than plain JavaScript or Typescript.
| chrisbroadfoot wrote:
| > As a bonus, emscripten/WASM compiled code will also be
| more efficient in the browser than plain JavaScript or
| Typescript.
|
| Small gains compared to the cost of implementing. 10-20%.
| Now you're asking your full-stack developers to know PHP,
| JS, C, and WASM.
| gls2ro wrote:
| Here is my perspective: There are plenty of reasons to use
| the same language on FE and BE but for me the main problem is
| the JS standard library.
|
| Let me give you one example:
|
| Lets say you want to validate if a string is a valid URL.
| What is a good way to do this in JS?
|
| Just for reference in Ruby for example I can do:
| URI.parse(input).kind_of?(URI::HTTP)
|
| No gems or any other engines needed.
| hoten wrote:
| The URL constructor.
| gls2ro wrote:
| Oh wow, how I missed that. I stand corrected!
|
| Seems like JS standard library is better than I thought.
| yashap wrote:
| TypeScript is a pretty good language for writing web servers,
| as long as you don't need to do computationally heavy parallel
| computing. And you can still do that, but it's very awkward.
|
| I've done plenty of backend work in all of TS, Scala, Go,
| Python and PHP. Scala is my personal favourite, but it's not as
| practical for teams as TS or Go, which are both very productive
| languages, with good enough type safety and performance, that
| new devs can learn quickly. And I'd easily choose TS over PHP
| or Python for a large system.
|
| Plus, it IS pretty nice being able to use a single language
| everywhere. My current company is TS RESTful services with
| TS/React on the web, and TS/React Native on mobile, pretty hard
| to beat how easy it is to do full stack dev work for most ppl
| in this setup.
| SavantIdiot wrote:
| > computationally heavy parallel computing.
|
| JS has no parallel computing support, so it is not an option.
| And when I say parallel computing, I don't mean distributed
| computing, I mean utilizing hundreds (thousands) of cores on
| a single die, like NVIDIA architectures. (It's a black art,
| even addition algorithms can confuse the newcomer.)
|
| The best course is to do what every other language does when
| it comes to simple-parallel operations, like Gauss-Jordan
| elimination: use a dedicated, optimized library, like NumPY.
|
| I really hope some day there will be a numpy for JS. NumJS is
| dead, and Google's TensorFlowJS is excellent for utilizing
| GPUs, but a dog when trying to do simple operations (the
| load/store async nature doesn't quite fit with most use
| cases.) I suspect WebAsm will facilitate the parallel nature
| of tensor operations without having to move
| lhnz wrote:
| It sounds like you want something a bit like WebGPU:
| https://gpuweb.github.io/gpuweb/
| SavantIdiot wrote:
| Close, but I don't want to have to switch memory models,
| e.g. upload/download. What I want is the incredibly
| diverse numerical computing support and logical syntax of
| NumPY but in the same process & memory space. The W3C
| endeavor is something a little different. Thanks tho!!
| lhnz wrote:
| I think you will be interested to read this article about
| the future of data programming in JavaScript (http://bens
| chmidt.org/post/2020-01-15/2020-01-15-webgpu/).
|
| I do think that this kind of thing will be able to be
| built on top of WebGPU (I saw this experimental POC that
| did so recently: https://github.com/milhidaka/webgpu-
| blas). The only issue is that since JavaScript doesn't
| support operator overloading even if a production-level
| library was created the code would be a little less
| readable.
| grishka wrote:
| ActionScript is also an ECMAScript language, and it's kinda
| ridiculous to see that JS still hasn't quite caught up. Out of
| things that modern JS lacks, AS had Java-like interfaces and
| you could specify types on variables.
|
| (Yes, I know about TypeScript.)
| SavantIdiot wrote:
| NodeJS is important for more reasons than "it's just
| JavaScript". It is asynchronous from the bottom-up, and it is
| literally a challenge to force asynchronous patterns into a
| synchronous ones, which is almost always a hack because async
| requires a lot of thought. This is a boon to IIoT control,
| where the pejorative "web server" is literally the endpoint for
| 10's of thousands of IoT edge nodes. NodeJS fits in with this
| architecture perfectly compared to the shoehorning required to
| make it work with PHP, (C/C++), Python or Java. (N.B.: I am not
| a java programmer, but we did review using Java, too, but it
| was voted down for other reasons.)
|
| If there is another asynchronous language that is as well
| defined as NodeJS and has as much library support, I would very
| much like to study it.
| ripe wrote:
| This. I grew up with Lisp and Smalltalk, yeah I am that old,
| but today I love Node to build web apps.
|
| It's a fantastic environment for asynchronous programming. It
| also has a built-in REPL for a management interface via TCP
| or Unix sockets. It doesn't really need any additional
| packages (I hate the dependency hell that npm saddles you
| with, and people don't seem to know that Node already has
| http, https, and websocket upgrades built in, so you often
| don't need any "frameworks" or libraries).
|
| Give me Node, and I can build an entire web app from scratch.
| Most of the time you don't even need to use JS in the
| browser. Just html and CSS are enough. Web apps the way God
| intended.
|
| I don't use Typescript either. Its type checking isn't worth
| the hassle of poor tooling and inscrutable stack traces.
| austincheney wrote:
| There are a couple of things that JavaScript got so incredibly
| correct:
|
| * Lexical scope natively without syntax or conventions
|
| * Functions as first class citizens
|
| * Inheritance, classes, OOP are not forced on you and can be
| ignored/omitted entirely from your code
|
| Those few things are what has kept me hooked on the language.
|
| > Node is not ECMAScript in a server-side ECMAScript engine,
| it's JavaScript in a browser JavaScript engine.
|
| What does that even mean? The APIs are completely unrelated and
| Node does different things that don't make sense in the
| browser.
| senthil_rajasek wrote:
| >> Node is not ECMAScript in a server-side ECMAScript engine,
| it's JavaScript in a browser JavaScript engine.
|
| >What does that even mean? The APIs are completely unrelated
| and Node does different things that don't make sense in the
| browser.
|
| I have taken the privilege of rewriting the quoted part of
| the parent comment,
|
| Node runs javascript on the server side in an engine built
| for the browser. It does not run ECMAScript with an engine
| specially made for server side apps.
| titzer wrote:
| > * Lexical scope natively without syntax or conventions
|
| I assume you mean over the alternative, dynamic scoping like
| in e-Lisp. But you realize that JavaScript's scoping rules
| are entirely wonky, e.g. that "var" declarations are lifted
| to the function level?
| austincheney wrote:
| To be more specific the term is _hoist_ which means the
| declarations are pushed to the top of the scope at run time
| for maximum availability, and _var_ is function scoped
| instead of block scoped. Block scoping is often more
| specific because a function body is a block as well.
| errantspark wrote:
| Right but we have `let` now which solves that problem.
| titzer wrote:
| Not completely, `let` also has a weird temporal dead
| zone[1], which is basically a dynamic check.
|
| [1] https://www.freecodecamp.org/news/what-is-the-
| temporal-dead-...
| hwillis wrote:
| var is a terrible example of that. Just don't use it.
|
| A good example would be the scoping in for loops and maybe
| arrow functions. For loops are goofy but virtually never an
| issue, and arrow functions are awesome.
| dclowd9901 wrote:
| And here I thought scope was kind of disaster in JS:
|
| - `const fooFunc = () => {}` is treated differently than
| `function fooFunc() {}` in declaration and subsequent access.
|
| - A function's invocation context changes depending on how it
| was declared (fat arrow vs. function declaration)
|
| Don't get me wrong: I love JS, but this is not one of the
| things I felt made it intuitive.
| austincheney wrote:
| The _this_ context changes, but I recommend developers not
| use _this_. That isn't a scope issue though.
| mweberxyz wrote:
| There would be no point in having two ways to do the exact
| same thing if function-style declaration and arrow-style
| declaration implementations were identical. Why would they
| add a new feature to the language if it was purely
| syntactic sugar?
| hollerith wrote:
| >a couple of things that JavaScript got so incredibly
| correct: . . . Lexical scope natively without syntax or
| conventions
|
| What language of the last 28 years _doesn 't_ "natively"
| lexically scope its variables?
| z3t4 wrote:
| JavaScript is different in that it use the function as the
| lexical scope rather then the angel brackets. This forces
| you to think about the code as functions, rather then
| blocks. And in turn helps you think of the code in three
| dimensions where time is one dimension, making it easier to
| understand code that runs asynchronously.
| icedchai wrote:
| Not Javascript. If I forget a var or let, it's global.
| austincheney wrote:
| Strict mode throws an error on implied globals. Use of
| modules forces strict mode.
| icedchai wrote:
| And that's all "extra" syntax.
| JoyrexJ9 wrote:
| strict mode is the default in everything now and had been
| for many many years.
| icedchai wrote:
| It isn't the default for a browser "<script>" tag.
| xigoi wrote:
| It's the default for <script type="module">, which you
| should use anyway for anything serious.
| galangalalgol wrote:
| That last bullet is my main complaint with java and c#.
| wvenable wrote:
| C# just removed the requirement to start code with a class
| or a main method; you can just start typing into the file.
| metaltyphoon wrote:
| I like this so much. In fact they are investigating the
| idea of #!/usr/bin/dotnet on a .cs file!
| nerdponx wrote:
| From my perspective (mostly a Python user), Javascript is a
| _fine_ language for general-purpose scripting and server dev,
| and Node is more than fast enough to handle typical workflows.
|
| Why do you think it's not a good language for this?
|
| Also, I see a lot of value in using a one single language that
| can truly do everything: frontend, server, and scripting.
|
| I guess you could use Python or Ruby like that with Wasm, but I
| haven't seen evidence of people doing that.
| lanstin wrote:
| Like JavaScript, one can argue that the only thing wrong with
| node is the ecosystem/developer community. Things like npm as
| just not curated enough given the large number of JavaScript
| developers and the attendant variability in quality of
| output. Node itself is an almost perfect call-back driven
| even loop for Unix network io, which till go and go
| routines/channels was the conceptually simplest way to use
| the CPUs you are paying for, saturate the network, and have
| subtle threading issues. (Python gevent was also good at
| that, but had more implicit magic which is bad for reasoning
| about code).
|
| But I am hopeful that when I finish reading the article I
| will not have to reuse my jquery / d3 based framework for
| doing quick data viz things (which I only started doing with
| great reluctance because people don't go wow over tabular
| data even if the data is wow-ing. The first request to make
| it pretty, i switched to mono space fonts. But jquery is
| showing its age.
| bennysomething wrote:
| I don't know what's wrong with me. I hate JavaScript. I tried
| learning react and redux and just gave up. All this to put a
| button and a field on a page. React was basically invented by
| John carmack to do doom 3 and copied to render web pages. Is
| this really required!? It's not a 3d games engine. I've worked
| on web apps that require a lot of page updates per minute and I
| still hate react. I stay the hell away from front end web Dev
| as it just feels like hell. Sorry drunken rant.
|
| Edit: I also worked on a node app that should have been written
| in a staticall typed language. Bugs that could have been caught
| at compile time literally caused me utter misery in on call
| overtime. All because some guy in our team demanded we wrote it
| in node. This was way before type script. I actually feel
| physical pain thinking about.
| schwartzworld wrote:
| You should really try learning react first without redux.
| Redux is for managing global state. It's rarely needed but
| has become the defacto solution for react state for some
| reason.
|
| React on its own is much simpler, once you grok the react
| compositional model. I don't know how you can do that while
| using redux too.
| adamscybot wrote:
| Perhaps give it another try, but with TypeScript. Im a front
| end dev and yes, I feel the JS pain. I look back at how I
| used to do things and think "wtf". TS completely changed this
| and brought it back to sanity.
| bobthepanda wrote:
| at least part of the problem is that Javascript and webdev
| have really low barriers to entry, which is positive in the
| sense that anyone can do it, but the problem is that anyone
| can reach that unhappy valley of knowledgeable enough to do a
| lot of damage without realizing it.
|
| If you put bad developers on other languages they usually end
| up running into some wall first but Javascript is pretty
| forgiving.
| vmception wrote:
| This is wrong lol. V8 changed the whole paradigm. Thinking of
| Javascript as still _just_ a browser language is the flaw.
| Pfhreak wrote:
| > The problem started a decade or so ago with Node.
|
| What problem, specifically? People enjoy writing Javascript. It
| has a ton of fantastic resources online, it is easy to debug
| and deploy, it's quick to pick up and forgiving of mistakes.
|
| > Too many people only learn JavaScript, become psychologically
| dependent on it
|
| You sound like Immortan Joe warning people not to become
| dependent on water in Mad Max. Let people enjoy the language
| they enjoy developing in.
|
| > they all collectively took it too far outside of a browser.
|
| What does this even mean? What's "too far" even mean? People
| want to write code, let them?
| zackify wrote:
| What I'm hearing is:
|
| Because the language wasn't planned to support all of this from
| the start, we just shouldn't use it.
|
| There's lots of great reasons to use a full JS / TS stack.
| There's lots of reasons not to.
|
| Doesn't mean it's inherently bad. This is the same logic used
| against PHP every day yet it's used all over.
| colordrops wrote:
| Unbelievable that this is voted to the top on Hacker News. The
| comment literally gives not one concrete example or reason by
| JavaScript is "bad". I'd expect more from you all here.
| cultofmetatron wrote:
| Couldn't agree more. I started in this field as a javascript
| programmer. I've since expanded my toolkit to include
| typescript, elixir, plpgsql and now gaining proficiency in
| rust.
|
| I'm continually frustrated by my colleagues refusal to step
| outside the javascript ecosystem. Don't get me wrong, JS
| certainly has its place but its not ALWAYS the best tool for
| the job. I see a lot of people reach for node as their go to
| backend tech choice simply because its the ONLY tool in their
| toolbox.
|
| Unless you're building a small focused microservice where the
| functionality involves calling out to a library with working
| tested code that does what you want, I think node is honestly a
| poor choice. To qualify my statement, I spent the first 7 years
| of my professional career building software with nodejs.
|
| The sweet spot is much smaller than the scope of projects
| people throw at it.
|
| * quick MVP? rails has more libraries that are drop in.
|
| * Performance? go and elixir have node beat for multicore perf
|
| * websockets? compared to phoenix channels, everything in node
| for serving websocket apis are a toy.
|
| Lambda functions though? yea nodejs kicks but there!
| beders wrote:
| Looking forward to the next article 10 years from now. Will code
| written now be incomprehensible then?
|
| One thing seems clear: We won't be using webpack, react or any
| other current tool. I'm not sure how organization can shoulder
| the costs associated with that kind of churn.
| Cyberdog wrote:
| I didn't know JS had `??` for a nil coalescing operator, or, more
| specifically, I thought it already had `||` for that purpose,
| since I've been using it for that for a decade or so without any
| problems. How do the two differ?
| TooCleverByHalf wrote:
| ?? - returns right side operand if left side operand is null or
| undefined
|
| || - returns right side operand if left side operand is any
| falsy value
| luftbbb wrote:
| Null coalescing is far more concise and basically offers a
| retroactive step in the case of a null. It's entirely different
| from using an OR condition
| qsort wrote:
| > 0 ?? 1 0 > 0 || 1 1
| nailer wrote:
| I like this answer because it's practical. Eg score 0 is a
| different thing from score undefined (which means you don't
| know the score).
| frosted-flakes wrote:
| ?? only coalesces nullish values (hence the name), which only
| includes null and undefined. || coalesces _falsey_ values,
| which include false, 0, and empty strings. || might work most
| of the time, but it requires extra checks when falsey values
| are valid.
| beardyw wrote:
| I think ?? only acts on null or undefined, || acts on any
| falsey value.
| ashdev wrote:
| Great post. Learned something new even though I've been using
| JavaScript for quite some time now.
| elcapitan wrote:
| Websites without Javascript are what I missed the most of the
| last 10 years.
| macando wrote:
| _async await_ was the biggest breakthrough for me. Made
| JavaScript code 3x more readable.
| BenoitEssiambre wrote:
| I really wish when things moved to async/await, that they would
| have gotten rid of promises like I proposed here:
| https://es.discourse.group/t/callback-based-simplified-async...
|
| As it stands it's layers of caching, state machines and
| complexity.
| contriban wrote:
| Confirmed. Every time I convert an old Node project to promises
| I constantly find bugs and situation that were just lost in the
| hell. The result is also so much cleaner that sometimes you
| realize you were doing something wrong entirely and you scrap
| the whole thing. No other JavaScript improvement comes close.
| Everything else is nice but only saves a few chars at most.
| macando wrote:
| And they announced promises like a big improvement over
| callbacks :D Now that was hell! Fortunately, when I started
| doing serious Node.js development, callbacks were already on
| the way out.
| sherr wrote:
| Some typos : "paramaters"
| lewisjoe wrote:
| I made a similar detailed document to bring my team up on the
| modern web dev workflows: https://bit.ly/3oi08M2
| YouthfulMarxism wrote:
| I'm so disapointed by the committee. So many utterly useless or
| easily bootstrappable features and yet, no pattern matching and
| pipeline operator stage 3 proposals. 0 progress for so many
| years. Lack of those roadblocks Typescript implementations.
|
| ReasonML and KotlinJS will faster become practical general
| purpose web languages than committee would start doing something
| usefull.
| Cyberdog wrote:
| > Lack of those roadblocks Typescript implementations.
|
| Is it JavaScript's job to improve the lives of transpiler
| implementers instead of improving the lives of JavaScript
| developers?
| epmatsw wrote:
| I think they're saying that TS won't add the feature until JS
| does. Still kind of a strange take IMO, but makes a little
| more sense.
| YouthfulMarxism wrote:
| First of all Typescript, is now more mainstream JS dialect
| than vanilla-js itself and, honestly, the only one i care
| about.
|
| And i thought it's kind of obvious for anyone, that until
| *JS* proposals are staged far enough - Javascript won't have
| those features too. There is a good reason why TS waits for
| the stage 3.
| anonymoushn wrote:
| no coroutines no buy
| osmarks wrote:
| Generators are basically coroutines, aren't they?
| halfmatthalfcat wrote:
| It took 6 years to ship ES6. We've now had a new spec iteration
| from every year after 2015. They are moving much, much faster
| and, having lived through ES5 to much pain and angst, I'm
| completely ok with them taking their time shipping these (very
| nice to have) features.
| cosmotic wrote:
| Please stop calling it modern. Call it New Features in ECMAScript
| 5 through 11.
| soheil wrote:
| It's nice to see JS improving, honestly all this improvement
| primarily makes searching for how to do something a lot easier.
| Now instead of copying and pasting 15 lines to, for example,
| handle async calls from Stackoverflow you copy three lines. I
| think learning new methods to do stuff in languages isn't
| relevant anymore when most web programming involves googling
| anyway. The only problem is sometimes answers on SO are outdated
| and even the most voted answer may be giving a suboptimal
| solution. This is something both Google and SO should have a huge
| incentive to fix.
| 29athrowaway wrote:
| This article is very distant from "Everything"...
|
| - Modules
|
| - Set and Map, WeakSet and WeakMap
|
| - String interpolation
|
| - Private methods (# prefix)
|
| - Template literals
|
| - Typed arrays
|
| - Symbol type
|
| - Generators
|
| - Proxy / Reflect
|
| - Internationalization
|
| And more...
| riho wrote:
| Seeing a lot of distain for JavaScript in here, but not enough
| examples of what's actually wrong with it. It's fine to criticize
| the language, there certainly are issues with it, but I'd like to
| see some actual constructive comments and examples from other
| languages where it's done better.
| indymike wrote:
| Most of the complaints aren't really about the language syntax
| or capabilities. Aside missing proper support for integers,
| modern Javascript is pretty nice. The complaints mostly come
| from developers being forced to use either Javascript (only way
| in the browser), or being forced to change code because of
| breaking changes in libraries.
| toolslive wrote:
| besides being really insane typing wise, javascript also both
| really lenient and unpredictable in what it accepts as
| expressions. Try to guess the result of the following
| expressions: > [] + [] > > {}
| + [] > > [] + {} > > {} + {}
|
| It means that if you feed it nonsense it does not stop you but
| happily carries on and explodes a few milliseconds later
| somewhere else. Another can of worms is the difference between
| null, 0,undefined, '', ....
|
| Ok, you got me worked up. I need to go for a run to blow off
| steam.
| kentor wrote:
| That is just javascript trivia that one rarely encounters in
| real code, and shouldn't be used to dismiss the entire
| language.
| noir_lord wrote:
| To borrow a Stroustrup quote
|
| > "There are only two kinds of languages: the ones people
| complain about and the ones nobody uses".
|
| I'm not a fan of JavaScript but I do like TypeScript.
| jpgvm wrote:
| The tooling and ecosystem are the main problems from my
| perspective. If you set yourself up with Kotlin + Gradle +
| IntelliJ you now already have all the tools you need.
|
| Want to create/maintain a modern JS/TS stack? Well, you are
| going to need npm, webpack, probably babel, linters, need to
| understand how to setup source maps and get those working for
| debugging server side. etc.
|
| It's a nightmare and it's all very fragile and that isn't even
| touching on the poor quality of the libraries outside of
| React/big ones.
| [deleted]
| tomcam wrote:
| Fantastic! I admit I want the same article for C. I am like a
| walking C89 standard but after that...
| oweiler wrote:
| Not a huge fan of JS but you can't deny that the language has
| improved tremendously over the years while still maintaining
| backwards compatibility.
| montroser wrote:
| Yes, indeed. It is really pleasant compared to how it was 10
| years ago, and still -- code written 10 years ago, even code
| written 25 years ago still runs in modern browsers. It's
| amazing and wonderful.
|
| JavaScript has quite effectively managed to avoid anything the
| Perl 6 fiasco which greatly contributed to Perl's demise, or
| the Python 2 => 3 timult, which turns out will not be a kiss of
| death, but made for some rough years. JavaScript did almost
| have its own trouble of the same sort with ES4, but it was very
| wisely abandoned when it turned out to be too
| ambitious/contentious...
| merb wrote:
| > Yes, indeed. It is really pleasant compared to how it was
| 10 years ago, and still -- code written 10 years ago, even
| code written 25 years ago still runs in modern browsers. It's
| amazing and wonderful.
|
| sadly that is not true. some stuff broke over the years. most
| often it was not javascript itself but changes in the dom
| api.
| GuB-42 wrote:
| I wouldn't call Perl6/Raku a fiasco.
|
| I don't actively use it but I followed it. It is actually a
| more modern language than pretty much anything else and it
| seems to have great community that is not a bunch of zealots.
| Also, it is far from dead.
|
| At the same time Perl5 is also still alive and from the
| start, it was clear that the two will be maintained in
| parallel. Perl6 was not intended to replace it, they changed
| the name to Raku to clarify the situation.
|
| So while it may be a fiasco if you consider the market share,
| it clearly isn't for the language. Perl5 doesn't really need
| change, and if you want to change it anyways, it would be for
| a whole new language, and that's exactly what happened.
| ketzo wrote:
| I dunno. If you walked into a sophomore-level computer
| science lecture 15 years ago, most of the people there
| would either have heard of Perl or be proficient in it
| themselves.
|
| Now? I'd be amazed if a single student had written a line
| of Perl, or ever _heard_ of Raku.
|
| That simply doesn't compare to where Python, Java, or even
| PHP are in the popular mind, IMO.
|
| I would call that something of a fiasco, frankly. Market
| share is everything for a programming language. The game
| isn't zero-sum, but it's close; there's only so many
| developers with so many hours to create libraries, guides,
| new software.
| superkuh wrote:
| Backwards compatibility is one thing. But forwards
| compatibility is something javascript devs have a terrible time
| with. The standards change fast and new features are added
| constantly. And unlike, say, Bash devs, javascript devs want
| the latest and greatest and don't care if it doesn't run on
| $software from 2 years ago.
| swiley wrote:
| I don't know if this is part of the standards but there was a
| backwards incompatible change in the way regex worked around
| firefox 73 and a bunch of sites crash in older firefox now.
| dleslie wrote:
| I'd like to say it's a testament to the original design; but I
| can't overlook the hundreds of millions of dollars, perhaps
| more, that has been spent to improve the language.
|
| It's nothing short of incredible that it is as fast as it is
| and as useful as it is. It shows that many hands do make light
| work; and money can buy that effort.
| irrational wrote:
| I don't have any numbers to back this up, but I'm pretty sure
| that between Google, Mozilla, MicroSoft, etc. more resources
| (both people and money) have been put towards improving
| JavaScript (language and performance) than any other language
| in the history of programming. Now I hope someone will
| provide numbers to show why I'm wrong.
| dleslie wrote:
| I want to say that C has had more resources due to it being
| the defacto compiler reference target; but honestly, I
| doubt it.
| epaulson wrote:
| I'm years behind on Javascript (I'm circa 'AJAX is new' in my
| knowledge) but I've been having good luck catching up using the
| Babel REPL with small snippets to just see how the new features
| get translated into the Javascript I know. Seeing what the
| compiler renames is a good way to understand the new scoping
| rules, etc.
|
| It's been especially helpful for yield and async/await, but I
| wonder if there's a bug in Babel with async/await. Just using the
| code sample from the article: function
| fetchUserName() { return new Promise(resolve =>
| setTimeout(resolve, 500)) } async function
| withAsync() { print("withAsync: fetching...")
| await fetchUserName() print("withAsync: done") }
| await withAsync()
|
| when I set the target to be 'ie 6', so hopefully I get output
| that's only the Javascript that I know, most of this gets
| translated to (a lot of) Javascript that looks normal for 2005
| Javascript - except the last 'await' line is still there. Is that
| a bug/limitation in Babel or was 'await' present in Javascript
| from years ago?
| dclowd9901 wrote:
| I don't know what the REPL you're running does with top level
| functions, but my guess is that an `await` needs to run within
| a function that is declared `async`. The reason (if so) would
| be that then babel could then transpile the function
| appropriately into a Promisory function. At the top level, what
| function would be translated?
| mweberxyz wrote:
| Top-level await is very, very new and requires ES modules --
| you can only use this feature without warnings recently in Node
| 15. For the foreseeable future, the final line should be
| replaced with: withAsync()
| .then(() => print("done") .catch((err) =>
| console.error(err);
| sandrot wrote:
| You're right, thank you for the explanation. My REPL runs the
| code in the textarea in an anonymous Async function, which is
| why top level async works in my examples.
| paozac wrote:
| Programming languages are tools, what matters is if they do their
| job. And the current popularity of javascript means it works for
| most people. But boy, how ugly and inconsistent it is. I wish I
| could like it.
| AegirLeet wrote:
| I write PHP for a living and every time I look at the JS world,
| I feel like they're exactly where PHP was 15 years ago, except
| with 20 times the amount of incomprehensible tooling.
| agumonkey wrote:
| Can you give more details ?
| AegirLeet wrote:
| 15 years ago, PHP didn't really support any programming
| paradigm very well, it was a huge untyped mess, the
| standard library was missing a lot of stuff, reusing code
| meant including individual files based on filesystem paths.
|
| Today, PHP offers a solid OOP experience, good gradual
| typing, a larger and saner standard library and code
| loading based on namespaced components.
|
| Now compare today's JS to PHP back in the day. It has the
| exact same kinds of problems. Except with modern JS, you'll
| end up adding TypeScript, webpack, Babel and a dozen other
| tools as well as several hundred megabytes of libraries to
| paper over all of those problems. But by doing that, you
| make the build process and the code that ultimately runs in
| a browser completely incomprehensible and undebuggable for
| the average developer. And then you start adding even more
| tooling (source maps that barely work) to try and solve
| that problem...
| agumonkey wrote:
| I had the impression that beside gradual typing, ES6
| solved most of the mess (cleaner apis, modules) which was
| happening at the same time PHP (and python) accelerated
| their growth.
|
| I find it really unfair to compare es6 to php 15 years
| ago, es6 is really cute (the babel/transpiling part is
| peculiar, I admit it)
| steve_adams_86 wrote:
| I've worked with PHP and JS extensively and while I could
| almost agree from some narrow perspectives, I think JS is
| nowhere near where PHP was 15 years ago in any sense.
|
| I was writing PHP 15 years ago. It wasn't a great dev
| experience and the tooling was awful. JavaScript today has
| stellar tooling in comparison, and arguably less warts in its
| standard library than PHP still has today.
|
| I really disliked JavaScript until I read some books that
| helped me understand what it's doing under the hood. These
| days I just don't have issues with it. Yeah, the ecosystem
| thrashes a lot and the tooling experience can be bad in
| regards to that, but otherwise it's impressive lately. Even
| without TypeScript, intellisense on regular JS enables
| extremely streamlined navigation of references and
| implementations, refactoring, project navigation, tooling
| integration, etc. Not to mention modern profiling and
| debugging tools for JS are incredibly easy to use and benefit
| from.
|
| PHP wasn't at this stage even 10 years ago. The debugging
| story was still xdebug and tooling was improving but not
| great. Composer was painfully slow and buggy - nowhere near
| as nice as yarn and npm are now.
|
| Yeah JS has problems, but I don't believe it's nearly as bad
| as old PHP.
| BeefWellington wrote:
| > JavaScript today has stellar tooling in comparison, and
| arguably less warts in its standard library than PHP still
| has today.
|
| There are a lot of reasons to like JavaScript as a language
| and NodeJS as a particular implementation. The standard
| library (or lack thereof) is absolutely not one of them as
| things stand today. I'm not even sure what you'd compare
| between them.
|
| If you meant to say "package available at the other end of
| npm install" instead of "standard library" I could see that
| being a different story.
| effable wrote:
| This may be a little off topic but your comment piqued my
| interest: I am currently learning JavaScript and I was
| wondering if you would like to recommend any of the books
| you read.
| sdfin wrote:
| I re-learned JS recently, https://javascript.info/ was an
| awesome resource and has almost anything you may need.
| Also MDN is good.
| gentleman11 wrote:
| If people didn't like JavaScript for front end work, it's not
| like they could just switch to python
| tshaddox wrote:
| Can't easily write Django code in JavaScript either. In
| general it's not like working programmers get to choose any
| programming language whatsoever for the hardware and platform
| they're writing software for.
| pessimizer wrote:
| You don't have to use Django (you can choose one of the
| billion alternative CMSes), but everyone has to use a
| browser. Hell, Django itself has to write javascript.
| sirsinsalot wrote:
| Django is not a CMS
| ironmagma wrote:
| There are a wealth of alternatives though... ClojureScript,
| Elm, ReasonML, and Purescript just to name a few.
| globular-toast wrote:
| I use both JS and Python for work and not a day goes by where
| I don't wish history had taken a different course and Python
| had ended up embedded in web browsers.
| qbasic_forever wrote:
| There was a strange time in the dark days of IE6 dominance
| 20 years ago that you actually could write page scripts in
| non-javascript languages. VBScript was a big option that
| some people used, and IIRC there was a way to get python
| support in IE (and Windows) script host too. When I was
| first learning Javascript in ~1998 I remember all the docs
| showed how to do stuff in both JS and VB script tags:
| https://stackoverflow.com/questions/17483782/vbscript-
| suppor...
| paozac wrote:
| Or Lua
| fit2rule wrote:
| This, a thousand times.
| garyrob wrote:
| This brand-new book on using Python (via Transcrypt) in the
| browser to build a React app may be helpful in that regard:
| https://pyreact.com. Just started reading it. Seems very good
| so far.
| gentleman11 wrote:
| Is the result ie 11 compatible and performant? Honestly
| curious
| dragonwriter wrote:
| > If people didn't like JavaScript for front end work, it's
| not like they could just switch to python
|
| Sure, they can, both via compile-to-JS solutions like
| Transcrypt [0], and via generate-the-frontend-with-backend-
| Python solutions like idom [1], Plotly Dash [2], and others.
|
| [0] https://www.transcrypt.org/
|
| [1] https://idom-docs.herokuapp.com/docs/index.html
|
| [2] https://dash.plotly.com/
| ad404b8a372f2b9 wrote:
| That's not a solution if you end up with Javascript in the
| end. (Also Dash is absolutely terrible, horrible
| documentation, horrible code.)
| vbsteven wrote:
| Why is that not a solution? The concept of
| compiling/transpiling a language into the target language
| for the runtime is everywhere.
|
| Even native languages like C/C++/Rust compile their
| language into binary format that the platform can run. It
| just so happens that the web _runtime_ format is JS
| instead of binary machine instructions.
| HideousKojima wrote:
| Because debugging your transpiled JavaScript becomes a
| nightmare in a language you already hate
| dragonwriter wrote:
| > Because debugging your transpiled JavaScript becomes a
| nightmare in a language you already hate
|
| That's what sourcemaps are for; you don't have to debug
| compiled instead of source format on the web just like
| you don't on other platforms.
| dragonwriter wrote:
| > That's not a solution if you end up with Javascript in
| the end. (
|
| It is, just as using compile-to-(or interpreted-by-a-
| runtime-in-)-native-code languages is a solution to "I
| don't like raw x86_64 machine code for desktop
| applications", even if you end up running machine code in
| the end.
|
| > Also Dash is absolutely terrible, horrible
| documentation, horrible code.
|
| "X is not a choice people can make" is a different claim
| than "One example of X is not something I personally
| would recommend".
| ad404b8a372f2b9 wrote:
| The issue is that writing code that goes through a JS-
| transpiler is more complicated than just writing
| Javascript, unless the language you choose is Javascript-
| adjacent, whereas writing code that compiles to machine
| code is infinitely less complicated than just writing
| machine code.
|
| As to your second point, that's why I put it in
| parentheses, of course it doesn't refute your claim but
| if you use as example a technology that has awful
| documentation because of this two-language paradigm, and
| leads to garbage code both at the Python stage and the
| Javascript stage, to me it doesn't paint a good picture
| of the whole concept.
| esrauch wrote:
| It turns out that even if you accept "Python is great and
| JavaScript sucks" that "Python compiled to JavaScript" ends
| up even worse than JavaScript.
| dragonwriter wrote:
| > It turns out that even if you accept "Python is great
| and JavaScript sucks" that "Python compiled to
| JavaScript" ends up even worse than JavaScript.
|
| Clearly, there are people that disagree with this value
| judgement, and the existence of that disagreement is an
| existence proof that Python for frontend is, in fact, a
| choice people _can_ make, even if it is one you find
| unattractive.
| esrauch wrote:
| I also have gotten DMs on Reddit from companies looking
| for devs since I commented on a thread 10 years ago about
| an obscure toy language: it doesn't mean thats a
| reasonable choice for technology.
|
| I think theres legitimate reasons to compile Python to
| JS, but "JS is bad" can't be one of them, since you
| _still_ have JS that you have to worry about. It makes
| sense for codesharing with server code or preexisting
| business logic.
|
| Over the years I've debugged js compiled from various
| languages, and it's seriously a terrible experience:
| however bad you think debugging handwritten js is,
| reading and debugging generated js is strictly worse (and
| you will have to)
| dragonwriter wrote:
| > however crazy you think handwritten js is, generated js
| is just obviously worse to try to read (and you will have
| to)
|
| Or...maybe I won't; I've used plenty of compile-to-JS
| languages (including what starts as "js" with JSX and
| modern features but gets compiled to plain, and more
| widely supported, JS), and I spend as much time reading
| and debugging JS in its compiled form as I do reading and
| and debugging .NET or Python bytecode instead of source,
| which is none.
| bobthepanda wrote:
| WASM is supposed to unlock non-Javascript for the browser,
| no?
|
| Also there have been attempts before but nothing really
| stuck. How many non-Googlers use Dart?
| irrational wrote:
| No? WASM doesn't replace JavaScript. Think of it as a high-
| performance library that JavaScript can make use of.
| echelon wrote:
| You can write Rust for the frontend right now. It's pretty
| neat.
|
| Yew [1] is one of the early Rust frameworks for client side
| work. It allows for multi-threaded (!) execution and
| javascript interop.
|
| Not many other languages make sense as you have to pack in
| the whole runtime, GC, etc. Rust is pretty well positioned
| for WASM, and it's going to take off soon.
|
| [1] https://github.com/yewstack/yew
| aphextron wrote:
| >If people didn't like JavaScript for front end work, it's
| not like they could just switch to python
|
| Sure you could. You can develop for the web in practically
| any language you like these days. People use JavaScript
| because it has native support for the DOM that nothing else
| can match. Until we get away from the DOM for application
| development, it will always be king.
| magila wrote:
| That has nothing to do with Javascript's merits as a
| language though. It's simply the only language browsers
| expose the DOM to natively.
| aphextron wrote:
| >That has nothing to do with Javascript's merits as a
| language though.
|
| Sure it does. DOM support is built into the very core of
| JS as a language, and that has shaped the entire history
| of its' development and subsequent API choices. It's not
| just a library that it happens to support, the way it
| would be with any other language.
| roofwellhams wrote:
| Try to debug that nightmare. Usually you'll need to debug
| compiled code.
| gentleman11 wrote:
| Do sourcemaps not help? I'm not experienced with python
| to js, but they help with minified js
| nsonha wrote:
| Example of inconsistencies? comparing to what? If you're gonna
| cherry pick some outdated es5 to make that point, dont bother.
| makapuf wrote:
| Iterating over an object keys, an array or a map?
| kingdomcome50 wrote:
| I would expect, given you have described an operation on 3
| different data structures using different words, that it
| would also demand 3 different kinds of syntax/denotation
| no? Your own language requires as much. Why not JS?
| makapuf wrote:
| Well in python by example you use for x in myobject to
| iterate and that's it, no Object.entries(myobj) vs.
| mymap.entries , lua is even more consistent, ..
| [deleted]
| frankenst1 wrote:
| for(let x of Object.keys({a:1})) {...} // Object keys
| for(let x of [1]) {...} // Array
| for(let x of (new Map().set("a",1))) {...} // Map
| neya wrote:
| I maintain systems written in Ruby, Elixir and PHP over the
| years. Every server side code written by me even as old as 5
| years ago, works with very little modification required for
| today.
|
| But the Javascript part is the one that always causes me hours-
| days worth of work into Rabbit holes. And by JS, I don't
| necessarily refer to the language alone. It's the entire
| ecosystem.
|
| Oh, `npm install`? You just found out you got like 1000+
| vulnerabilities. Alright, good thing it told me actually, let
| me update.
|
| BOOM! Babel doesn't support this specification in this file
| anymore because it's nonsensical so you have to do something
| else now. Ok, BOOM! Babel deprecated that now, you have to try
| this workaround. Oh, wait. Actually, there is no workaround.
| You gotta downgrade your node version.
|
| Ok, let me downgrade. Oops, that package isn't supported
| anymore on this node version. Oh, you need to replace this
| because it's no longer maintained.
|
| I literally never had to go though this pain with any of my
| Elixir backend projects.
|
| Fuck Javascript
| [deleted]
| Rompect wrote:
| Sounds a lot like the external packages are the problem.
| adevx wrote:
| 1: Trying to fix every vulnerability in any nested dependency
| is probably not what you want to do. In my experience only a
| tiny fraction has an attack surface and most are duplicates.
| 2: Webpack is a monster and updating webpack will always
| result in a lot of work. If possible use a well supported
| framework that incorporates Webpack, like Next.js or Nuxt.js.
| Updating will be a breeze. 3: Don't wait years before
| scanning for issues, update on a set schedule so it won't
| become a huge task once a critical issue is found.
| a1371 wrote:
| You're comparing Elixir & Ruby with Babel, not vanilla
| JavaScript. You are putting your code on non-standard
| JavaScript, that's on you.
| dragonwriter wrote:
| > You're comparing Elixir & Ruby with Babel, not vanilla
| JavaScript. You are putting your code on non-standard
| JavaScript, that's on you.
|
| Babel is the only way to use modern _standard_ JS without
| excluding older browsers.
| austincheney wrote:
| I completely disagree. The TypeScript compiler allows you
| to specify a compile target against a version of
| JavaScript. That means you can write modern TypeScript
| and have it compile to ES3.
| midrus wrote:
| So npm gives you warnings about vulnerabilities and that's a
| bad thing?
|
| You notice you have thousands of outdated dependencies and
| that's a bad thing?
|
| I used to work a lot with python years ago, and the only
| reasons we didn't have this problems was because the packages
| management was so terrible that you didn't even notice you
| had to update dependencies or that they had vulnerabilities.
| heavyset_go wrote:
| > _So npm gives you warnings about vulnerabilities and that
| 's a bad thing?_
|
| > _You notice you have thousands of outdated dependencies
| and that 's a bad thing?_
|
| This is a weird reply considering that the OP literally
| said those were a good thing:
|
| > _Oh, `npm install`? You just found out you got like 1000+
| vulnerabilities. Alright, good thing it told me actually,
| let me update._
|
| The bad things are in the lines that follow.
| lanstin wrote:
| Diff being you usually have like five python deeps for
| every hundred npm deps a d you can do the old school thing
| and subscribe to the security alerts for those deps. The
| difference in number of deps means you have the cognitive
| space to understand them. Npm needed to automate because
| the numbers are too high. One of python's old selling
| points was "Batteries included". And the idea is fewer
| large library rather than a bunch of tiny libraries.
|
| With a small number of deps where you skim the development
| DL, you know if there is a security issue or a cool new
| feature you want. Also it has more of the Unix C philosophy
| of don't break stable APIs in new releases. So upgrading
| mostly just worked. (Stuff like deliberately breaking old
| SSL protocols aside). (Until python 3 of course.)
| jonnycomputer wrote:
| I got to pains to limit how many python external
| libraries I use, for all these reasons. But because
| Python is so capable on its own, it works.
| Draiken wrote:
| Most languages I've used don't *need* to have 1000
| dependencies like JS does.
|
| They also don't have thousands of projects depending on
| ridiculous packages like left pad because they actually
| have a standard library.
|
| The surface of vulnerabilities and the brittleness of the
| entire ecosystem is the bad thing, not the warnings.
| Waterluvian wrote:
| I started just despising JS. But with discipline and a well-
| configured linter, formatter, and ideally using Typescript,
| I've found it to become my favourite language.
|
| Doesn't mean I'm saying JS is inherently beautiful. But if you
| ignore the bad features and do a little setup, it has the
| potential to be wonderful.
| Cyberdog wrote:
| So many people are bringing up TypeScript here as an example
| of how JavaScript isn't so bad. I kinda feel like that's
| cheating. Like saying eggs are absolutely delicious when
| baked into a cake - you're praising something after it has
| been turned into an entirely different product.
|
| Maybe TypeScript is great, but I just don't like the idea of
| depending on transpilers to not suck when creating the final
| code, and also having to debug that transpiled code, and then
| the whole transpilation step in between the standard command-
| S-command-tab-command-R workflow (this is also why I never
| use SASS/LESS if I don't have to).
|
| Once JS itself has strict typing and real classes, and enough
| time has passed that I can be assured 95% of people using
| five-year-old browsers will be able to use it, then we can
| talk about the wonders of JavaScript. Until then I don't get
| why anyone would use it (or anything that transpiles to it)
| when there are so many better alternatives for server-side
| development.
|
| Let's not even get started with Electron.
| osmarks wrote:
| Why is the transpilation step an issue? You can set it up
| to happen whenever the file is changed with most things.
| cesarb wrote:
| Because it's no longer the same language. You're not
| programming in JavaScript, you're programming in
| TypeScript, which happens to be compiled to something
| JavaScript engines accept. All the praise towards
| TypeScript does not necessarily apply to JavaScript. It
| would be like praising Assembly while you're actually
| programming in C.
| goodoldneon wrote:
| AFAIK, the only difference between TS and JS is types. TS
| doesn't give you anything that's functionally different
| than JS -- only types that are stripped during
| compilation. You can't perform any logic on types at all
| (e.g. you can't have conditional logic based on
| interfaces).
|
| Comparing assembly/C to JS/TS doesn't make sense.
| Cyberdog wrote:
| With most things, yes, if the implementation for that
| feature supports your operating system, and it doesn't
| take long enough to be noticeable, and there's no weird
| caching issues at any given level, then yes, it's
| transparent in that case.
|
| Or you could just write the JS directly and be done with
| it.
| Waterluvian wrote:
| People occasionally rely on compilers. I don't really see
| this as much different.
|
| At the end of the day all I care about is if I build the
| products and solve the problems I'm hired to do. Beyond
| maintainability, the "engineering" stuff is a distraction
| we need to be careful not to obsess over.
| lanstin wrote:
| Well yes. But as the problem solver, there is nothing
| better than when someone has a problem, and you have a
| solution ready at hand which came from lambda calculus or
| distributed systems tricks or some crazy shit from On
| Lisp. That is why they are paying you, not to cranks out
| good dutiful straightforward solutions but for clever
| ideas that are simple to implement and operate. The
| engineering is both awareness and skill in following
| processes to get great cheap and effective solutions.
| Otherwise you end up with 20 million lines of code and
| all the aesthetically sensitive people have have to leave
| the company.
| mnahkies wrote:
| > I just don't like the idea of depending on transpilers to
| not suck when creating the final code
|
| How does this differ from trusting a compiler or
| interpreter?
|
| Every language has to be translated to machine code in some
| way.
| Cyberdog wrote:
| > How does this differ from trusting a compiler or
| interpreter?
|
| When was the last time you found a bug and it was the
| compiler or interpreter's fault?
|
| At any rate, the big difference is debugging, as I
| mentioned above. How fun is it to debug code which you
| only kind of indirectly wrote?
| mnahkies wrote:
| The code output by typescript is generally pretty
| readable depending on the target, and the source mapping
| works very well regardless. The debuggers in all major
| browsers and ides handle it fine.
|
| I've not come across any bugs caused by typescript itself
| in the time I've been using it since 2014, and my point
| was that this is the same for c or any other language -
| how fun is it to debug assembly you only kind of wrote
| j45 wrote:
| Nice read. I wish something would speak to the increased
| brittleness of software in this world too.
| jonplackett wrote:
| Another really good resource with a lot of examples and
| explanation: https://javascript.info/
| jonplackett wrote:
| https://web.archive.org/web/20210515151920/https://turriate....
| tyingq wrote:
| Site seems a bit overwhelmed, archive.org copy:
| https://web.archive.org/web/20210515151920/https://turriate....
| sandrot wrote:
| thank you. I had to change my idle connection timeouts. Eeep!
| tomxor wrote:
| There's a lot to like in modern Javascript, pretty much
| everything in the list I appreciate.
|
| The only thing I wish was never added is the new Array Functions,
| I mean, ok they are "handy" sometimes, but they seem to get
| abused heavily. Newbies like stringing them together and even
| nesting them, when they could have achieved the same with a
| single for loop and the same number of lines. In other words they
| seem to encourage people to artificially increase the complexity
| of a problem without any objective improvement in legibility, not
| to mention lots of GC work with throw away arrays... many people
| don't seem to even be conscious that under the hood of most of
| the array functions is just another iterator of some kind.
| halfmatthalfcat wrote:
| Newbies aren't the only ones stringing them together and
| nesting them, even seniors like me are...to great effect,
| increased readability and are safer than potentially dangerous
| mutations.
|
| I teach all my reports to lean heavily into the new array
| functions because, if wielded correctly, are much more powerful
| than using for loops while using less code.
| contriban wrote:
| Many array looping functions have been around since ES5 and
| I've been personally replacing them to for-of loops with very
| few exceptions (.map() and .filter() remain handy)
|
| Useful fresh additions are .find() and .includes()
| rm_-rf_slash wrote:
| Vectorized array functions are easier for the compiler to
| optimize than for loops. Once things get nested the performance
| comparison isn't even close.
| Etheryte wrote:
| As a standalone idea yes, however in practice this is not
| actually the case [0], mostly due to those methods having a
| number of extra checks, more functionality built into them
| etc.
|
| [0] https://stackoverflow.com/q/21037888/1470607
| rm_-rf_slash wrote:
| Fair point, although as the answer states, it depends on
| use cases. Working with small datasets the performance
| difference is negligible, but with decently large datasets
| (~1-100mb) and nested loops the delta is night and day.
| Buttons840 wrote:
| That is a valid opinion, I agree there are advantages to plain
| for loops. However, it is not a universal opinion and I would
| argue against the for-loop, sometimes. Some languages people
| love do not even have loops.
|
| You never know what structure a for-loop will take, it could
| break early, skip items, build a new data structure, mutate a
| data structure, or all the above. If I see a map and a filter,
| I know exactly what each does.
|
| I don't want to argue over which is better. Pros and cons. I
| just wanted to say that chaining and nesting array functions is
| not a reliable sign that someone is a "newbie", maybe they're
| just someone with different preferences.
| django77 wrote:
| I've usually seen more complexity with single for loops and
| having complex logic mixed with imperative approach also makes
| it a lot harder to read.
|
| Array methods convey meaning a lot better. There are some cases
| where performance matters, but usually the performence cost is
| negligible.
| tim1994 wrote:
| I just wish those methods were available on iterators (and
| return iterators when called on arrays) and a collect method
| that creates a new array (a bit like Java). That would reduce
| the overhead and keep the advantages of this functional style.
| globular-toast wrote:
| A for loop is an imperative construct and can be used to do
| literally anything. One has to read on into the body of the
| loop to understand what's going on. Worse, there could be a bug
| and now you have no idea what the programmer intended.
| Array.map, on the other hand, only does one thing: turns an
| array into another array. The intention is clear. It makes a
| program much easier to understand.
| jjnoakes wrote:
| In javascript, what prevents the body of the map function
| from doing arbitrary stuff? Don't you have to read that to
| know for sure, just like a for loop?
|
| In some languages the map function may be restricted to not
| have side effects, in which case I'd agree, but not
| javascript, correct?
| globular-toast wrote:
| You can't stop bad programmers doing bad stuff. It's not
| about that. It's about communicating intention. Code as
| documentation.
| lanstin wrote:
| There is nothing more clear than code as a way to
| communicate, at least for me. My writing in English
| obviously could be better but easier just to show what I
| mean.
| django77 wrote:
| This is correct, but there are some guarantees such as the
| result will be an array of the same length, mapping
| function will be called for each element, function itself
| can be more easily tested in isolation and there are no
| imperative constructs (creating accumulator array outside
| of the scope, tracking the index, pushing to the
| accumulator array)
|
| This lends itself very nicely to functional programming
| (especially with typescript IMHO)
| jamil7 wrote:
| As someone who works in a few languages I find the array
| methods really handy as they work similarly. It's usually a bit
| clearer to me what the programmer's intention was with them
| rather than a straight for loop.
| malobre wrote:
| The page HTML is weird, there's no `<html>`, `<head>` or
| `<body>`.
| butt__hugger wrote:
| None of those are needed for proper HTML; they're implicit.
| vmception wrote:
| > The async/await keywords are here to save you from callback
| hell
|
| but does it?
| stevula wrote:
| Absolutely, unless you're using node or library functions that
| require callbacks. Even then there is usually a non-callback-
| based alternative or you can wrap in a promise to use
| async/await.
| amerine wrote:
| Hey Sandro, it's been a long time! Excellent post!
| sandrot wrote:
| Thank you, Mark! Super long time.
___________________________________________________________________
(page generated 2021-05-15 23:00 UTC)