I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to adapt rather than a failure of the ecosystem.
People wouldn't complain about it so much if it didn't suck.
Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon).
The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be a JS-app" thingie) have practically destroyed how most of the websites are displayed by the 2 devices I own. Sites like Hacker News or Wikipedia, which still work perfectly fine, are very far and few between. I sincerely deplore this.
deleted 10y ago
[deleted]
Well what's unique about HN and Wikipedia? They're largely non-monezited. If Buzzfeed can make more money off of a flashy website it's hard to argue with.
I don't think it's either/or. You can make a "flashy" (in the sense of Buzzfeed) without it being burdened by huge amounts of js. Likewise, monetized sites are still frequently not like Wikipedia or HN.
HN doesn't do much, but Wikipedia does a decent amount of stuff with JS on their website despite people taking it as an example of "the web as documents"
meanwhile, I don't know how FB or Twitter are nice user experiences when you operate on a "paginate 20 tweets at a time" philosophy.
I'm with you, but it's just part of the growing pains. The web is successful because it's easy to layer businesses on top of each other... I can have a Tumblr with a Shopify backend and Google Adwords on top. Apps are walled gardens so they can only enforce one business model at a time. That can make things nice and tidy, but it walls you out of the messy, compositional business models of the web.
Because business models are composed on the web, it's just harder to settle on unified design standards. It takes time for everyone to agree on a separation of responsibilities on the page. This is compounded by the sheer newness of the business models. My webcomic about fancy cheeses has a segment marketing a line of tractors now to industrial buyers at a conference in Wisconsin this week? OK. That's an opportunity I probably wouldn't have had selling Java apps.
A web limited to textual content is a pretty quaint and uninspiring vision, IMO.
The web started that way because static documents are relatively easy to represent, but the future (and present, for that matter) is rich experiences that can be distributed in the same way.
But there are many steps left to get there, so either buckle up and help build that future, or get used to an ever-shrinking ecosystem of the purely textual Web.
I'm personally very excited by the convergence of mobile and web development, PWAs, improved functionality for layouts, self-hosted app architectures (like Tent and Sandstorm, language-agnostic runtime via Web Assembly, better serving performance via HTTP/2, low level multimedia APIs, encapsulation of rich UX via Web Components, and so on and so on.
Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.
Do you want to bet on that last one?
Sure, but in the meantime the web is a much less accessible place for screen readers, underpowered mobile devices, and those without good internet connections
> Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.
Could have said those same words literally a decade ago when we were all struggling to figure out all this Rails and MVC stuff and how automated ORMs worked above MySQL. Seven or eight paradigm shifts later, we're all still confused and I see no cohesive knitting.
My opinion happens to differ. Textual content is incredibly rich and is likely a target for all content in the future. Consider, we are literally training models to accurately caption things today.
Why? Because language is a hell of an abstraction. More, it is approachable and can often be bounded. Consider, I am not even remotely skilled in art. However, I can adequately describe, for me, a picture by saying who is in it and the event. Try doing the same without language. Often "quaint and uninspiring textual" language.
Do I opine for the what we had in the 90s? Not necessarily. But I do grow weary of folks reinventing frameworks that merely further complicate the very abstractions that they created and now require these frameworks.
And I would love if my 2001 Honda Accord was compatible with Tesla's autopilot, but I understand it is not a realistic expectation.
I'm not sure why you'd expect the web to be a. Mostly text and b. able to render easily on obsolete devices.
The web is becoming a robust application delivery platform. That is so, so awesome. Most people do not want to be stuck with shitty looking, text only websites. Moving the platform forwards necessitates that it will use more resources. Increased resources availability and consumption over time is fairly consistent across most aspects consumer computing.
deleted 10y ago
[deleted]
I would love HN to provide an easy way to see where the reply thread to this first comment ends. Some js might enable that. Basic html/css - I think no.
deleted 10y ago
[deleted]
But I seldom hear people saying the old web pages can't be shown on today's browser.
That is a vision that is incompatible with the reality of computing from the past 10 years.
Amen! React might be the best tool for building hybrid mobile or even cross platform electron apps, but the truth is, it suck balls for web development.
Bundling the entire website inside a single js file, that needs to be re-downloaded everytime you add a div or change a single css class is stupid, sorry.
Your website doesn't need to be pure text. It can be beautiful, modern and responsive. And it doesn't need much js for that.
The world has become mobile first, not js-centric. Pushing spa everywhere is just wrong.
React is great for web development (using Next.js) based on my recent experience.
Citing only one side of any architectural trade-offs isn't particularly interesting either. The other side is that we can now easily build sites using Universal JS (serverside-rendered combined with SPA).
Delivering a website with seemingly instantaneous repaints even on flaky internet connections is just a superior end-user experience.
Just click through the primary nav of a Universal JS site vs an old-school one, and it feels like we've been putting up with the equivalent of the old 300 ms tap delay, but for all websites and website links.
Not engineering away that latency penalty will tend towards foolish for website properties that want to remain competitive.
Users will become increasingly accustomed to very responsive sites and the latency penalty that is currently normalised will become more glaring and unacceptable.
Ten years ago MapQuest was state of the art, and you'd click "next tile" over and over to traverse a map. Then Google Maps showed up with its voodoo ajax and infinite scroll and ushered in the modern web app era. Sure, some folks overdo it, but I'm not going back.
Javascript fatigue fatigue.
Monocultures develop because one tool is far better than all the others.
Javascript isn't a monoculture because all the tools are bad.
Ah and so what good monoculture can you direct us to?
By the way, the OP I responded to said "front-end", not "JavaScript". How does your attitude jive with WebAssembly which will allow you to compile C++ or Rust for the browser?
Huh? Who is talking about monoculture? OP certainly isn't, and I don't think anyone else is seriously suggesting such a thing.
It's not unreasonable to expect that the ecosystem doesn't operate under an ever-expanding set of wrappers, frameworks, layers, and models, and it's certainly not unreasonable to expect that our tools don't suck.
The open standards you talk about ARE already a part of the ecosystem, and well-established: HTML, HTTP, DOM, and ECMAScript. The new JS library of the week is not a part of that.
First, let's be clear here: React was first open sourced in 2014, being used at Facebook extensively before that. Sure, it's no Win32 API, but it's not exactly the new kid on the block.
But the point of the web already having these standards is exactly the point - these frameworks are built on top of and contribute to the underlying universal standards, so what's the problem?
There's this cargo cult complaint where people talk about 'layers and layers of bad abstractions' while rarely offering a superior solution or describing exactly which abstractions are bad and why they are bad. Mostly just hemming and hawing about things being "bad" and "overcomplicated".
It's basically the same instinct as complaining about code written from a previous dev that you didn't write--because you didn't write it, you weren't there to think about the very real tradeoffs that always have to be made when actually implementing something, rather than just complaining about the previous person's implementation.
I never know which abstraction people are complaining about. Is it http? html? the dom? javascript? wrapping libs like jquery? view frameworks like react? routing frameworks? complete frameworks like angular? what's the solution? get rid of all of those things? use different UI abstractions? get rid of javascript ?(oh wait, you can already). The truth is, it's just easier to complain than it is to implement, so that's what people do.
Completely agree here. I think many people realize this and have built awesome tooling to be able to manage different ecosystems and environments.
One that I've been particularly keen on over the last year is GraphQL. If you're interested in simplifying frontend development while giving it more power and control to dictate the data that it needs for each component / view, you should check out GraphQL. I know what you're thinking... "Ugh, another dev tool to learn etc etc". But it's definitely one that's here the stay and a bigger idea than even REST itself. The OPEN STANDARD of it is KEY.
The idea is that you have a type system on the API level and one endpoint. And querying works using a standard GraphQL language, so it's cross-API compatible and you don't need to go learn a whole new API convention at each new place or project you're working on since with REST, they're probably all built in different ways. And GraphQL works across all platforms (i.e. no more proprietary SDKs). All you need are things like Relay and Apollo and that's it.
I've actually been working on a platform called Scaphold.io (https://scaphold.io https://scaphold.io) to help people learn more about GraphQL and give them a cleanly packaged server and help you manage your data so you don't have to in order to feel the benefits of GraphQL right off the bat. Because of the use of GraphQL, it comes with the best of both worlds of Parse and Firebase with awesome data modeling tools, real-time capabilities, and of course it's built on an open standard.
Truly is the future of APIs that works perfectly with React, and any other framework that comes out down the road for that matter. Facebook's tooling is really neat cause it's built from first principles as well as from their experience running one of the largest distributed systems in the world. So they definitely know a thing or two about building developer tools that are cross-platform compatible and developer-friendly.
> I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem
Old people also get tired by all these "apps" wining for your attention; they want "just a phone". Young people grew up with it. Note to self: I'm getting old.
Old people were used to buying development toolset (compiler+tools+IDE), usually including a physical book, with which they can create software. Young people are used to assessing open source projects, and piecing a project together on top of many freely available libraries/frameworks.
I'd be careful of making such generalized statements, whipper-snapper...some of us senile old devs actually pieced together some "wild and free" C-libs (i think we used duct tape and hairpins, but im losing my memory in my advanced age) and even used dynamic-loading (DLLs of course) back in the day.
>Old people also get tired by all these "apps" wining for your attention; they want "just a phone". Young people grew up with it.
https://www.youtube.com/watch?v=z-194bOCJnE https://www.youtube.com/watch?v=z-194bOCJnE
> To expect web development to be a perfect monoculture is a failure
Except, it's already a monoculture of one language (JS) and one display algorithm (DOM) and everything is just compensating for that.
The "runtime" is not general enough.
It won't change the fact that a lightweight scripting language is coerced into running increasingly heavier apps. Defending it, comes off as a Stockhilm syndrome really.
I get the Javascript fatigue fatigue part, but this comment breaks the HN guideline against name-calling in arguments, and even crosses into incivility:
> We aren't going to get off of your lawn while you continue to beat a dead horse.
> a failure of your imagination and ability to adapt
Please don't do this in HN comments regardless of how tired you are.