Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

251–260 of 303 posts

Re: Ask HN: Why is everything in JavaScript changing so fast?

#251

The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…

Do you have more details on JS in microcontrollers? I'm curious about real-time systems, etc. I found the Tessel ( https://tessel.io/ ), but its hardly a microcontroller - its a MIPS SoC. It looks like the Espurino is more of a traditional microcontroller. But the unit cost is high - $40! Is anyone using JS on a microcontroller in a high volume product?

Not sure it's low enough for volume project , but the closest today is espruino js on esp8266 ($2 wifi MCU) , or its brother , the esp32.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#252

I think many people are missing what's happening here. This isn't the first time we have seen lots of churn. Every time some group discovers something "new" they latch on to it and try to shape it in their image of what is the best. This is natural and important. Even looking back about 20 years, how many companies where making CPUs? How many different architectures where there? How many companies where making PC clo…

Small Comment. The ARM architecture is RISC. And mostly every phone/tablet/wearable(even stuff like your TV) has one of those.

It's not a "true" RISC architecture anymore. There are "complex" instructions that would be frowned upon by the original RISC community.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#253
post #115
post #94

Earlier quoted context omitted.

It's easy to sit back and critisize JavaScript and the web with dismissive comments like this. I have heard variations on these same memes for many years. But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum…

quantity !== quality

TypeError exception: Expected even more equals signs.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#254

Earlier quoted context omitted.

We have to rewrite everything in JS because JS is the language that runs on browsers. :) If you were asking a higher-level why (why do we have to use the browser), look rer's sibling comment. I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old t…

> We have to rewrite everything in JS because JS is the language that runs on browsers. Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway. Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal? If the problem is discoverability/installation/security etc we could focus on ap…

If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes

To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#255

Earlier quoted context omitted.

On the contrary; Rails was a massive innovation because it proved that opinionated, reasonable defaults ("convention over configuration") is how most people actually want to write software. For a CRUD app, Rails was a shining beacon of light, because it allowed you to crank one out in mere hours, instead of days of fiddling with repetitive glue code that you would've had to write instead in literally any other web fr…

> how most people actually want to write software. [citation needed] Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light. JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you…

> [citation needed]

Okay. The year is 2005. PHP5 was fresh out of the oven and most people were still on PHP4. From PHP's point of view, there's rumors of something happening in the Ruby community that will be big, and should be talked about [1].

Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on the announcement you can gauge the contemporary reaction; comments detail the fact that Rails was breath of fresh air from the configuration-heavy Java frameworks of the day -- represented by Struts [3], but others weren't much different in this regard, as these books from 2002 and 2004 about alternatives to Struts show [4][5]. Several ASP developers, detail their positive experiences in switching their web development to Rails [6][7][8]. The PHP world is forever changed -- by 2006, frameworks inspired by Rails abound [9]. "Ruby on Rails" becomes a popular phrase, some frameworks borrow the naming scheme along with the ideas: "Groovy on Grails" [10] tries to bring Rails' ideas to the Java world, "PHP on Trax" (formerly "PHP on Rails" [9]), "ColdFusion on Wheels" [11].

I'd say Rails made quite the splash.

[1] https://blog.phpdeveloper.org/2005/12/31/25/ [2] https://developers.slashdot.org/story/05/12/14/0034219/ruby-... [3] http://weblog.rubyonrails.org/2005/2/22/comparing-struts-to-... [4] https://www.safaribooksonline.com/library/view/programming-j... [5] https://www.safaribooksonline.com/library/view/programming-j... [6] http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-ana... [7] http://weblog.rubyonrails.org/2005/12/20/neters-tell-scoble-... [8] http://weblog.rubyonrails.org/2005/7/5/not-knowing-where-it-... [9] https://h3rald.com/articles/rails-inspired-php-frameworks/ [10] http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-mo... [11] http://cfwheels.org/blog/how-oo-almost-destroyed-business/

Re: Ask HN: Why is everything in JavaScript changing so fast?

#256
post #133
post #94

Earlier quoted context omitted.

It's easy to sit back and critisize JavaScript and the web with dismissive comments like this. I have heard variations on these same memes for many years. But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum…

> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users. I believe that part of the reason is the ease of access to JS development. It allowed an inordinate…

There are a few condescending attitudes at play in your comment.

Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and practice. So, being easy to use is a much more powerful feature for a language / framework / platform than most.

Also, we should all be aspiring to use tools that enable us to quickly spin up a prototype UI that looks convincingly useful. I'm not sure why that's a knock against JS.

Also consider this: the languages / frameworks / platforms before the web, and before JS, were harder to use and relatively very discouraging to new users (this also sometimes goes for the communities associated with those languages / frameworks / platforms).

We all started from a place of ignorance as software developers, and many of us never would have left that place if it weren't for someone looking at us and seeing a computer whiz in the making.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#257

A lot of comments here seem to suggest it's just because of people creating projects to get attention. I think this reason is massively overstated, and appeals to the unfortunate HN meme of disparaging other people's work to signal that the commenter is smarter than the herd. However, I would suggest that we are now building applications at a level of complexity which has not previously existed on the web before (unl…

I'm not sure which comments you are referring to, but there is a lot of truth to the idea that developers (especially frontend developers) are, in some cases desperately, trying to build their reputation by contributing to or starting GitHub projects. Notice I said "build their reputation" not "get attention". The fact is it is almost impossible to get a job as a non-junior frontend dev nowadays without a GitHub prof…

It goes hand in hand with the industry shift (especially for frontend tech) with considering one's GH as an essential aspect of one's resume.

I wonder how much of that shift is also just perception within a certain bubble/echo chamber, though. There's certainly a trend in online forums and startups to ask applicants for their GH profile, but I suspect this is one of those things that some employers are doing because they think everyone else is. Are those employers really then reviewing all of those profiles to see which include projects where an applicant really made a meaningful contribution and which are just token updates or yet another ad hoc, informally-specified, bug-ridden, slow implementation of half of someone else's popular and established work?

The only thing I know for sure about that sort of policy is that it would immediately rule out most of the best developers I've ever worked with. Most of those people are busy building working projects for their businesses/clients/employers during work hours, and then having a life at other times. Some do contribute back to OSS projects or help answering questions on online forums as well, but not as a resume-building exercise, and it's rarely where you'll find the best indications of what they are capable of building.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#258
post #161

Earlier quoted context omitted.

Every time I see this argument I have the same response -- we tried this. We came really close to having Java be the standard and it failed for a ton of reasons (security was incredibly difficult, absurd slowness, UI/UX problems, user adoption issues, etc). What makes you confident we could get it right the second time?

Yes, you have an excellent point, and I worry about that. It also worries me that what I am proposing is pretty much what Flash did, I think, and we all hate that. I think we can do better because we know what we need now, and we have some good and bad examples to guide us. The problem with the JVM is that it is too heavyweight. But we know that lightweight is possible because everyone loves Lua. Security is doable b…

Finally, someone gets it. Thank you!

Re: Ask HN: Why is everything in JavaScript changing so fast?

#259
post #87

Earlier quoted context omitted.

Okay. I guess you're welcome to do that? We browser coders will just continue to go to market faster. It's pretty cool that, if you put your work in, you can make a GUI on the browser that is accessible to all desktops and phones. That's 2 billion users. The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?

What's wrong with native apps? They use less memory, battery, and processor than an interpreted stack. They can be more responsive than the hardwired 16ms latency built into the browser. If you need network it's not hard to open a socket. The browser itself is a native app opening sockets. In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps…

Where is the 16ms hardwired latency in the browser coming from?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#260
post #148

Earlier quoted context omitted.

> The python API would likely be no slower and much easier to write and debug. But probably not for your qa engineer who most likely already (and possibly only) knows javascript.

Who needs more than one language? One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT? SINGLE STACK!! /s

They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack.

For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time.

EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.

Post reply on HN