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

The melting pot of JavaScript (2017)

increment.com

Post reply on HN
Print view View original

21–30 of 200 posts

Re: The melting pot of JavaScript (2017)

#21

Post by sam0x17 »

mattmanser wrote: post #20
sam0x17 wrote: post #16

Earlier quoted context omitted.

At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA…

I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app. I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two. Add on top that massive extra expense of doing a pure SPA compared to the ease…

It could be that our app is uniquely situated to avoid these issues, but we have had the opposite experience. Our API is versioned so things never get out of sync, the frontend code has no external dependencies so its as unbrittle as one could imagine, and we use aws API gateway to fake server side endpoints, so we dont have to do some weird url scheme. This could never work with a CRM though.

Re: The melting pot of JavaScript (2017)

#22

Post by w4tson »

Is it unfair to say that some of these problems are caused by a lack of awareness (or an unwillingness) to learn from other communities (like, Ruby, Java etc) that have solved these some of these problems already?

Re: The melting pot of JavaScript (2017)

#23

Post by hrabago »

zach43 wrote: post #11

I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further

Ten years ago, JavaScript was my go to when I wanted to expose others to coding. It still is today, but now that comes with the caveat that the most popular libraries and framework require a significant amount of prior knowledge to understand and to start using.

I haven't done this exercise in a long while, but the last time I tried to start a project from the "most current and stable releases and recommendations", I ended up not being able to get anything running. In the end, I had several hundred megabytes of libraries downloaded, a complicated configuration, and a non-working application.

Today, there are toolsets to get you started with everything and produce a running application, but it's almost totally opaque. I'm afraid to use them because the first time something breaks, I don't know if I would be able to resolve the issue.

I would still rather have a decent understanding of how things connect.

Re: The melting pot of JavaScript (2017)

#24

Post by gedy »

simion314 wrote: post #18
zach43 wrote: post #11

I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further

>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…

npx create-react-app my-ts-app --typescript takes about 30 seconds from command to running app.

Maybe the issue people have is there is no 'js-lang.org' with one tutorial site and getting started. It's a huge community, so of course random blog posts will be a mixed bag of quality.

Re: The melting pot of JavaScript (2017)

#25

Post by gedy »

perfunctory wrote: post #8
lewisjoe wrote: post #2

I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…

Really curious what is actually wrong with "crude bash scripts for building"? I had experience with both types of projects - the ones with home made crude build tools (in Python, not bash), and the ones with modern javascript build pipelines. The first build never broke. The second build would break every couple of months for no obvious reason without us touching the project structure.

Maintenance. Because seems they are usually written/owned/optimized by some build brainiac that becomes a bottleneck or leaves at some point.

Re: The melting pot of JavaScript (2017)

#26

Post by spricket »

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript.

Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard.

JS could use a little more of the cruft and process that makes Java and C# especially so "uninteresting".

Java especially is kind of a joy to work in if you ignore the cruft. Everything is generally well documented, the libraries are mostly very solid, code is almost always backwards compatible, there isn't a zillion ways to do everything, frameworks tend to live for a decade or so.

And it's faster than JS, and uses way less memory, and mostly solved dependency hell and bloat over a decade ago.

Java feels like it was designed, not grown. Everything follows similar convention so it's easy to pick up new libraries. The advantages are many. The drawbacks are few as long as you use things like Lombok and code generation liberally. By the way; code generation using agents, annotation processors, and bytecode manipulation is pretty much standard and a godsend for doing interesting things (and getting around the cruft) .

In java, I can write code on the fly at runtime, or even during compile time using standard tools. Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated

Re: The melting pot of JavaScript (2017)

#27

Post by pwaivers »

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

Since JavaScript is a prototype language, doesn't reflection come in automatically?

Re: The melting pot of JavaScript (2017)

#28

Post by me551ah »

You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, these will become obsolete too.

Re: The melting pot of JavaScript (2017)

#29

Post by c-smile »

mattmanser wrote: post #20
sam0x17 wrote: post #16

Earlier quoted context omitted.

At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA…

I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app. I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two. Add on top that massive extra expense of doing a pure SPA compared to the ease…

I've architected Web Application that runs as in a) connected as in b) occasionally disconnected mode (LocalStorage + sync when online).

For #b SPA is the only option.

Re: The melting pot of JavaScript (2017)

#30

Post by ausjke »

I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to add event-loop and/or restful framework than making javascript looks like python/java one day as far as backend goes.

In 2019 I still have 0 interest in javascript/TS for backend, the thousands of modules under node_modules alone is enough for me, and not all real world product need async/promise/callback/SPA, javascript is over-heated too much, not fun at all.

Post reply on HN