It is useful, you don't need to worry about insects and infectious diseases. Most pesticides are damaging to the surrounding ecology. Moreover, with the way industrial farming is currently done, most plants are genetically similar to each other. This means that if a bacterial outbreak were to occur, it could potentially wipe out many crops. In an enclosed environment, you eliminate these things. Although, you could still do it in a green house.
Forcing the DOM, JS and CSS was a mistake. The problem was that you couldn't have alternatives. wasm is going to disrupt front end by allowing you to have a strong typed language that you can use to build your own framework like the good ol' days.
Only once for the containing canvas. A direct access to the canvas pixel data and webGL offscreen rendering is all you need. With a few hacks, we're already 90% there. I expect by next year to see an explosion of this. There already are projects in Github that translated SDL and OpenGL to build web widgets.
The process was very controversial at the time, and still is, and its success is hotly debated – with the claimed benefits including a reduced cost to the taxpayer, lower fares, improved customer service, and more investment. Despite opposition from the Labour Party, who gained power in 1997 under Tony Blair, the process has never been reversed wholesale by any later government, and the system remains largely unaltered. A significant change came in 2001 with the collapse of Railtrack, which saw its assets passed to the state-owned Network Rail (NR), with track maintenance also brought in-house under NR in 2004. The regulatory structures have also subsequently changed.
Even the Financial Times, notoriously partisan backers of privatisation and markets, struggles to make the case for rail privatisation these days (although they do try, bless them).
>There is a growing consensus among both executives and industry experts as well as the public that Britain’s unique attempt to create competition on Britain’s rail network has not delivered.
>While it has led to more services, and encouraged more users to pay higher prices, it has not unleashed the productivity improvement necessary both to upgrade the network and stabilise the network’s finances.
>Over the same period, for instance, London’s state-owned metro network, Transport for London, has grown just as quickly and delivered much more state-of-the-art investment.
That's been my biggest gripe with modern gaming. It feels like 2 of the first 3 hours of most modern games are cutscenes. I miss powering on a game, hitting start, maybe reading a paragraph, and going straight to the action.
Luckily some recent indy games have filled that itch. Yooka-Laylee, A Hat in Time, and Hollow Knight have felt like modern updates of what I grew up on.
Hollow knight, aside from Breath of the Wild, was my favorite game of the year.
It's such a great, great game. It offers a fantastic atmosphere supported by a fitting score, an unexpected amount of unique content, an interesting story and a fitting amount of challenge.
Try Nioh or Dark Souls, you’ll have gameplay coming out of your ears. If you want cutscenes and dialogue with balance, try Persona 5, which is balanced by very tight gameplay; likewise with Yakuza 0. Avoid anything from Ubisoft like it was carrying plague.
Speaking of Ubisoft, is it just me or do they repackage the same game with different skins over and over gain? I swear Assassin's Creed, Far Cry, Ghost Recon and Watch Dogs are the same game with different skins.
It is not just you. It reminds me of Taco Bell. They’re only working with a dozen or so ingredients, sometimes fried, sometimes grilled, in various combinations. After a while though, you start to realize it’s just a “new” arrangement of the same “meat” and it gets ooooold.
I couldn’t agree more, I think they just got lost in the easy money. If we’re lucky they might fall on some hard times that fall short of killing them, and rememember that making really great games was how they became huge the first time. Otherwise, it’s hard to see a way forward the way they are now.
Ghost Recon is IMO the best "skin" of those four. Although they look somewhat samey, they are very different games (though I would lump Watch Dogs under "Scifi AssCreed").
Far Cry is a bit of a mixed bag, 3 was fun, 4 wasn't, I'm looking at 5 because it looks fun too.
EA DICE do the same, Battlefront and Battlefield feel and play very similar, they just have different visuals and voices. There's nothing inherently wrong with reusing the same code, especially when the games work and sell very well, but it does make the games feel a bit similar.
...how many versions of pokemon have Nintendo released that are the same thing? How many mario parties? (Hint, there are 16 mario party games in the main series)
Ghost Recon Wildlands has been my favorite game to fire up and relax with for a long while. The Open World is massive and dense without feeling overcrowded. Esp. playing as squad with friends is fun, even if all you do is fly around in a helicopter and find bases to clear out (my personal challenge is to clear a base without raising alarm once, which I managed 6 out of 8 times). I also positively love how free the mission setup is.
I would wish that OW-games would be more like Wildlands.
Two games by the same studio who are praised for their ability to tell a story.
To be honest there are only a few games I played during the ps3 era (bought it for the cell chip+linux and left it unpatched when they removed it from the firmware until the system was broken wide open), but the last of us was a great story and fun game.
I like how the (brief) opening cut-scene ends with Doomguy losing patience with the computer trying to narrate to him after only a few seconds, and smashing it. The game's attitude to storytelling is established quickly and decisively.
My favorite part of all that is the fact the developers actually did develop lore and a back story for Doom 2016 that the player is then free to either explore or ignore. The attitude towards storytelling that they established is so much more impressive when you realize that they actually did put effort into making a story.
No webassembly is a solution to it. JS just sucks. Actually so does HTML and CSS. The entire web ecosystem is a closed platform. The reason that the front end stack is constantly bloated is because JS,HTML & CSS are awful. If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks. Strong typing is good, reactive programming is good. Using html and css strings is idiotic, and we couldn't build alternatives to this model for the past 30 years.
Please clarify what this means. Standards are open access and browser engines and JS engines are for the most part (Edge, Safari, Chromium, Firefox) open source, so "closed platform" seems, to me, inaccurate.
> If the people behind wasm were smart, they'd allow generic handles to a graphics context so that people can write/export other rendering frameworks.
Do you see how bloated web browsers are already? Do you really want apps to recreate all of this base functionality, or even to encourage such horrific inefficiency? Hopefully I'm missing something, because this seems like a terrible idea.
HTML (or any SGML-derivative, really) + CSS is the only application view format we have in common use that allows for clients of all shapes and sizes to reformat the page to fit them (with reflow rules, browser-default styles, and user-agent styles); and for alternative clients like screen-readers or "scraper"-like API clients to work with the view without the author having considered their needs ahead of time; and, best of all, for client-supplied optional third-party extensions to go into the view and mutate it to suit whatever custom purpose the client desires.
In other words, by mandating that the application view layer interacts with the client by delivering declarative (HTML) or imperative (JS) instructions to populate a semantic document (the DOM), rather than to populate a particular viewport; and by mandating that styling considerations are kept as separated as possible from that document; we can then operate on that document apart from the application's control, and render it the way we want to, or parse it into something entirely else.
A large part of the point of "the web" as a technology stack, is to provide exactly that capability. There's even a name for explicitly targeting such use-cases as a developer: HATEOAS (i.e. making your API endpoints act like web pages as well, in that they're also "documents" embedding hyperlinks to related documents, and form-input descriptions for making queries against the document—so that API clients can "navigate" your API just like browsers navigate your site. In extremis, your API becomes your site—since, if every endpoint is already responding with hyper-documents, your controllers can just have a logic for "Accept: text/html" that renders that hyper-document into hypertext, and attaches styling to it.)
If you don't care about any of that, you don't need the web. You just need a Hypercard viewer with an address bar. Or Lotus Notes.
HTML and DOM is the current way that is forced on us. What if I had a better model? I can't implement it myself. The DOM was meant to describe documents, not interactive webpages. HTML and CSS never had to compete with other ideas or technologies, because you physically can't do it.
The DOM is a relic from the 90s that refuses to die.
Implement it yourself, rendering to WebGL (with a canvas fallback if you really care). When you're done, show HN! We'll probably mock you, unless it's somehow awesome. The DOM is horrible, and knowing what we know now we could at least make it less weird, but some of the big annoyances really are its greatest strengths.
I am doing something similar. The problem is not just HTML/CSS it's also JS. You need a strongly typed language, and have a scripting language on top. What I'm doing now is a Rust based framework, with an Erlang like scripting language to define complex interactions. Taking inspiration from Flash, all animations and transitions can be keyframed with tweens. Taking inspiration from the C/C++ to python interoperability, I want the same with Rust and Erlang. Now my entire backend can be written in Rust.
Unfortunately, I'm not open sourcing it. Not until I get a proper graphics context, and implement my own rendering engine. I think web assembly is going to revolutionize the web. I see browsers allowing you to cache common libraries/assets, and html/css being replaced by several competing UI paradigms. The one I favour is inspired from functional reactive paradigm, but there are equally valid alternatives. I don't think there will be a single frame work to rule them all, just competing schools of thought. Right now the web doesn't have any competing paradigms, just html, css,and js.
Reason web sucks:
HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation. This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves). Some of them had far more impressive UIs than the webpages of today. This type of UI is an order of magnitude harder with html/css than just doing it all via X11 and C (even with memory management concerns).
The reason for this is that HTML first isn't strongly typed. If you make something complicated, and make a small change, it messes everything up. Your compiler can't help you. HTML tags are somewhat inconsistent. React, Rails etc. are all trying to address this problem. They are all taking inspiration from android, iOS, QT and gtk+ to make it somewhat component based. However, you fundamentally can't achieve this. HTML is in a land of its own, when you create an HTML tag, sure you can wrap it in a JS class, and mimic some of the characteristics that desktop frameworks provide you. You won't get the whole thing. I've seen many times different frameworks reinventing html templates (like handle bars). Templates can't solve all issues.
CSS sucks. The first thing about css that sucks is the "cascading" part of css. It should just be ss. CSS was originally designed to limit bandwidth by having it cascading. That's not the case today, and it messes everything up. The second thing that sucks, similar to why html sucks, is that again css is in a land of its own. It's hard to control css from JS (for interactive site you want this). I'm not even going to talk about how hard it is to position things properly via css when you are building layouts dynamically.
JS just sucks. I don't think I need to elaborate, I've mentioned enough points already.
Every single web framework out there is trying to address some aspect of the problems I mentioned, but my claim is that you can't solve it, you need to start over. Imagine if CPU makers made crappy inconsistent assembly code. Every year a new compilers and languages come out that tries to fix their predecessors. The most logical choice is instead to ditch that chip maker, make a better CPU with a consistent assembly code. You can't do that with web, you can't ditch assembly(html,js,css).
It only took 30 years for the web to get web sockets, webgl and now wasm. I think in another 20 years we'll come a full and get the remaining amenities that modern operating systems provide.
The reason I chose Rust is because it's a low level language with strong typing. It's not quite Haskell, but good enough. Writing a web server and UI with Rust is very nice. It just connects to the backend processes with ease, and doesn't make things awkward the way npm does. I do a lot of low level numerical and mathematical simulations, all done in C/Rust with all coordination & distributed computing done in Rust. I want Rust to take over. The sequence should be: Erlang -> Rust -> C
I chose Erlang because years ago I saw how reactive programming is extremely useful for complex interactions in a AAA game I was working on. In a game system you have the play interacting with the world, with enemies. The enemies interact with the player and each other. The player can pause the game at any point, then you need to bring up a menu screen with its own interactions. I've seen this work flow done in many different ways, and by far the reactive paradigm is the most sane. This was done in a bastardized version of Lua and Lisp.
I pretty much agree about JS and Rust, but I find myself disagreeing with some of your points regarding CSS/HTML.
>> Reason web sucks: HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation.
CSS does have a concept of keyframes now (I know this may not cover everything you like about flash keyframes, but I figured I'd throw it out there in case you were unaware):
https://www.w3schools.com/css/css3_animations.asp
>> This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves).
Those layouts had a known aspect ration, 4:3, and a reasonable expectation of being viewed on a large screen. HTML and CSS are expected to work on a wider variety of screens that may change size and aspect ratio on the fly, possibly during an animation. If I only had to make HTML/CSS animations for use on a normal television screen with a known zoom level in a specific browser, I could make interfaces every bit as beautiful as your N64 games (well... with a competent designer, but my point is that I could write the layout and script the animations). Some of the pain points of HTML and CSS are historical accidents that can't be changed without breaking compatibility, but some of them are quite useful and necessary. Responsive design is a good thing, it just sucks to write an animation that works in a whole range of aspect ratios and zoom levels. It's a problem that Sony and Nintendo never had to design around. The amount to which this constraint cripples and strengthens the web is hard properly convey. I love and hate it, but as time goes on I learn to hate it less and love it more.
>> It's hard to control css from JS (for interactive site you want this)
It's costly, as it touches the DOM, but it's not hard. Just change the class attribute (or even the inline style attribute -- there are cases where this can be argued for). Simple example: https://www.w3schools.com/js/js_htmldom_css.asp
> The first thing about css that sucks is the "cascading" part of css.
This tells me you hve very little experience with CSS or even HTML. The cascade saves you from declaring "font-size: 16px" in every single element of your page. Think of it as a form of property inheritance
Sorry, you can’t say “CSS sucks” when the only limitation it has is your lack of knowledge. If YOU can’t build complex layouts with it, it’s not the language’s fault. Plenty of people can. Open an “awards” site and see what people can do and you can’t.
It depends on what you compare it to, most native stacks have a more simple and understandable way of handling styling and control layout.
You can cut a lot of things with an ax, but you shouldn't criticize someone for wanting a saw, even if you can build the skill set to do the same with an ax.
The fundamental problem is that if you do end up reimplementing a slightly better DOM yourself, you end up with (e.g.) 20 MB of browser and rendering code. This will have to be downloaded by the client. If this were a onetime thing (perhaps some kind of "install"), it wouldn't be a problem.
But browser caches aren't generally up to the task of making it a onetime thing because:
-They're usually pretty small.
-They'll evict pretty frequently.
-They're limited to same-origin, even if the content cached is exactly the same. (For security reasons, yes, but there's no way to opt out.)
If caches were fixed, I think we would see a much healthier web ecosystem. Incidentally, it would make the browser vendors themselves fairly obsolete, which is probably why it hasn't happened yet.
I think billybolton is right that HTML/CSS/JS/the DOM all kind of suck, and that they can't feasibly be replaced is problematic. The heroic modern struggle of the web ecosystem is an attempt to encapsulate and work around the suckiness.
> Incidentally, it would make the browser vendors themselves fairly obsolete, which is probably why it hasn't happened yet.
Mostly, but not entirely true. It's been a while seen we've seen a new browser come out, but the time is ripe to begin work on one, and release it in a few years. Just fork webkit to maintain backwards compatibility. I see browsers just becoming a sandbox virtual machine with a key ring, with minimal functionality.
Apple has the strongest incentives to build what I am mentioning. Not sure if they will.
It took 100 years to go from the onset of the printing press to the book form and we are in some weird in between time frame where browsers aren't really enough to do what we want. Conceptually it is going to take something that is revolutionary, yet at the same time extremely familiar... like the book. I bet we would find similar strains in the intervening decades between the printing press and the book.
If that's your opinion then why bother targetting web browsers with WASM at all? You've been able to create highly interactive apps and games using native development for ages. I simply see no need for a new bytecode format, especially when mobile is ARM-only already, and even less so in Web browsers. WASM doesn't define a rendering or sound API, nor does it solve any other single problem game developers are having on established platforms. And, like JavaScript, needs HTML and CSS or another graphic API such as WebGL or canvas.
It's not for games. We are dealing with big data, we need to highly interactive UIs on the web that we can use to communicate and interact with this information. Something like this is where I see the future of web:
http://globe.cid.harvard.edu
That is not real time, but very difficult to pull off on web (harder than using C++ on desktop! Debugging webGL in JS is a nightmare). I don't see any issues with an ARM processor. The Harvard globe project if done in C++ could definitely run on a 2004 era computer. Most phones these days are much more powerful.
