SilverLight halott

SilverLight halott
2011-09-14T08:50:50+02:00
2011-09-17T14:30:20+02:00
2022-10-26T04:35:35+02:00
  • Sajnos tipikus, hogy nem közvetlen információval dolgoznak a véleményt nyilvánítók. Részemről csak erről volt szó.
    Mutasd a teljes hozzászólást!
  • A kimoderálsá rendben lenne, de aki ezt teszi az törölje magát hírt is, mert az abszolút nem korrekt. A társalgás maradhat.
    Mutasd a teljes hozzászólást!
  • Ami nem baj, olvastam a hirtelen flood-ot, és nem jó, amikor már abba az irányba megyünk, mikor egymás kompetenciáit firtatjuk.
    Véleményt mondani és álláspontot foglalni akkor is lehet, amikor nem foglalkozunk valamelyik technológiával. Csak vezér cikket ne irjunk róla....

    A támadóid egy része egyébként valószinűleg nem látta a Build keynote-ot, és a fenti cikkre támaszkodott. Ami sajnálatos módon (kedves Sting) vagy rendkivül pontatlan, vagy szubjektiv. (inkább az előbbi)
    Mutasd a teljes hozzászólást!
  • Látom kimoderálták eredeti hozzászólásomat. Szerencsére itt meg van: Windows 8 fejlesztői bejelentés + első reakciók (FRISSEBB)
    Mutasd a teljes hozzászólást!
  • Nem biztos, hogy bátorság, inkább vizió kérdése. Mindig vannak úttörők, akik kitapossák az utat, és 1000000-ból 1 rohadtul meggadagszik, de emiatt aggódni felesleges. Plussz a .NET és Xaml tudás annyira produktiv környezetet ad, hogy egy Metro Style app pár nap alatt elkészithető (most nem a féléves projektekről beszéel, hanem sima konzumer appokról)
    Mutasd a teljes hozzászólást!
  • Egy picit hadd szóljak bele én is. WPF fejlesztő voltam, Silverlight fejlestző lettem és Win8 fejlesztő leszek, (installing win8 :D)

    Amikor elolvastam a kérdéses cikket, főleg miután végig néztem a konferencia keynote-ot, hát kicsit elgurult a gyógyszer, el is határoztam, hogy nem reagálok most én élből erre.

    Némi szúsza után.
    WPF-ről átlépni Silverlight-ra gyerekjáték volt. Expression Blend adott, ugyanaz. Xaml adott, kb ugyanaz, picit volt butább, anno ezzel együtt kellett élni, de ma már nagyon kicsi a rés a kettő között. És most egyáltalán nem rettent meg a Silverlight elhagyása. Amiről egyébként SZÓ sincsen. Ugyanis az SL appok ugyanúgy futnak tovább, mint eddig. Ha elkezdtél egy LOB appot fejleszteni, az is futtni fog teljesen jól, max nem metro style appként. Ha ezt szeretnéd, pár namepspacet nyivlán cserélned kell. Hogy pontosan miket még erről nem nyilatkoznék, tekintve, hogy még én se nyúltam az SDK-hoz.

    De végül is mi itt a legfontosabb?? Az, hogy a skillset megmarad. Mert a Silverlight nem attól nagyszerű, hogy ő a Silvrelight, hanem attól, hogy ott a Xaml és számos olyan koncepció, amit a wpf-től átvett és a metro-s appok is visznek majd (pl databinding). Persze kicsit tanulnunk kell, de minimálisat. Sőt még blendet is kapunk hozzá.

    Jó ideje mondogatom már (azóta, hogy a wpf halálát vizionálták az emberek), hogy nem WPF, Silverlight, vagy Metro Style app a kérdés... hanem az hogy XAml, vagy nem Xaml. Az MS válasza meg az, hogy egyértelműen xaml.

    A html és javascript egy lehetőség. Mindkettő csak egy nyelv, amit szintén lehet használni. Mögötte úgy is a WinRT van, meg a saját üzleti logikat amit, hát ide a véres bökőt, hogy .net-ben fogsz megirni.

    Szerintem, a korábbi igen borús hangulat után, most kimondottan inkább örülni lenne célszerű.

    Üdv,
    Zoli
    Mutasd a teljes hozzászólást!
  • Ha ez így működne, akkor ma mind az Apple AppStore, mind az Android Market kongana az ürességtől, hiszen mindenki a bűvős 60 (vagy akárhány) százalékos penetráció elérése várna és várt volna évek óta


    Azért az appstore és az android market átlagos programjai, és a desktop programok nem egészen ugyanabban a ligában játszanak, kivéve talán a játékok egy részét.

    Nyilván nem fogja mindenki a Windows 8 megjelenésének másnapján kidobni az asztali kódjait, de annak semmi akadálya nem lesz, hogy elkezdjenek gyűlni ezek az új, Windows 8-only alkalmazások.

    Azon túl, hogy ki kell fejleszteni őket. Ami ugye pénz.

    Ilyen körülmények között meg tök felesleges további energiákat ölnie bele. Pláne ha immár létezik egy valóban minden téren és értelemben közvetlen belső konkurenségnek számító platform is ez az új HTML5+JS alapú felület személyében.

    Aminek viszont pont az a lényege, hogy platformfüggetlen. Innentől kezdve pedig a hajukra kenhetik a windowst.

    A hasonlóval nem megy semmire, ugyanazt meg nem építheti bele.

    Már miért ne menne ? Ilyen specifikus elem nem lehet túl sok, ugyanis ellenkező esetben a html5/js egyetlen komoly előnye veszne el: a platformfüggetlenség. Másrészt, egy épeszű fejlesztő ha választania kell a gugli és a ms egyedi cuccai közül, akkor nem a MS-t fogja választani. Pláne, ha elterjed az a _pletyka_ hogy a Google Page Rank-nél hátrány ha ott a MS-specifikus JS API...

    Ez a mostani új fejlesztési modell ennek a felzárkózási folyamatnak a lezárását jelenti, ami végre lehetővé fogja tenni a Microsoft számára, hogy kvázi saját érdekében is megcsapolja a mostanra már talán az asztaliét is meghaladó méretűre duzzadt webes fejlesztői-, kód- és tudásbázist, amit mindeddig parlagon hagyott heverni, sőt, még annál is rosszabbat tett vele: átengedte a Google-nak és más versenytársainak, hogy azokat erősítsék, vele szemben.


    Nem tudom, innen annyira nem tűnik annyira átütőnek ez a hatalmas fejlesztői tudásbázis. Idáig még nem láttam webes alapon _semmit_ amit ne lehetne fél kézzel megcsinálni desktopon.

    Egyrészt azért, mert HTML+JS-hez sokkal többféle eszköz sokkal többféle platformra érhető el, mint .NET-hez és társaihoz, másrészt pedig mert a fejlesztés ezekben a nyelvekben sokkal dinamikusabban, egyszerűbben, rugalmasabban oldható meg, mint a klasszikus, merev, egy adott gondolkodást kikényszerítő és komplex egészt képező platformok esetében

    Konkrétan milyen többféle eszközre gondolsz ? Van egy csomó kicsi js lib, részben szépen átfedve egymást funkcionalitásban, de én ezt nem igazán nevezném előnynek. Ahogy maga a dinamikus típuskezelés is önmagában gányolás. Addig jó amíg kezdő vagy, utána viszont sokkal-sokkal több bajt okoz mint ami előnye van.
    Mutasd a teljes hozzászólást!
  • "de maga a tény, hogy 5 évvel a stabil változat bemutatását követően még mindig csak showcase és/vagy belső, egyedi alkalmazások készülnek ezen platformon, nyilván beláttatta vele, hogy erre egyszerűen nem vevők az emberek (se fejlesztők, se ügyfelek)"



    példa

    Egy fecske nem csinál nyarat, de azért készült egy pár ütős cucc amire a html5 még hosszú évekig nem lesz képes. Szerintem az MS stratégiája az lesz mint a java stratégiája az FX-el. Van egy ilyen eszköz amit bárki elővehet, ha a szükség úgy hozza, de nem ez lesz a legfőbb csapásirány. Ezek a hatásvadász címek, csak az olvasottságot gerjesztését szolgálják nem a valóságot tükrözik.

    - A Wikipedia Google-gyilkos keresőt fejleszt
    - Az Amazon iPad-gyilkos tablettel támad.
    - Új, "Java-gyilkos" nyelvet mutatott be a Red Hat
    - Facebook-gyilkos közösségi oldalt indít a Microsoft is
    - A Toshiba hamarosan bemutatja az Apple iPad gyilkos tabletet
    - Újabb Atom-gyilkos processzor jön idén
    Mutasd a teljes hozzászólást!
  • Ez nagyjából igaz (azért tud pár dolgot, amit html-js-el ma nem igazán lehet megoldani), de szvsz nem is a funkcionalitás a nyerő a html/js megoldásokhoz képest, hanem a fejlesztési módszer.

    Sokan ugyanezt a dolgot pont a HTML+JS mellett, annak előnyeként említenék. Ti. hogy annak a nyerőbb a fejlesztési módszere. Egyrészt azért, mert HTML+JS-hez sokkal többféle eszköz sokkal többféle platformra érhető el, mint .NET-hez és társaihoz, másrészt pedig mert a fejlesztés ezekben a nyelvekben sokkal dinamikusabban, egyszerűbben, rugalmasabban oldható meg, mint a klasszikus, merev, egy adott gondolkodást kikényszerítő és komplex egészt képező platformok esetében.

    A harmadik dolog, hogy az nem kérdés, hogy a már létező webes platformokkal, megoldásokkal (és itt a keretrendszerek mellett gondolhatunk webalkalmazásokra, weboldalakra, webszolgáltatásokra és webes API-kra is) egy a HTML+JS párosban íródott alkalmazást könnyebb integrálni, összelőni, együttműködésre bírni, nem pedig a .NET-est, aminek a legtöbb webes koncepció teljesen rendszeridegen, kezdve a dinamikus típusoktól kezdve a szöveg-alapú adatcserén át egészen a futásidejű értelmezésig.

    Szóval az egész csak nézpont kérdése, és az, hogy az ember mit lát a maga számára jobbnak, kényelmesebbnek, szimpatikusabbnak elsősorban annak függvénye, hogy egyrészt honnan érkezik, másrészt hogy hová tart, azaz milyen alkalmazásokat, milyen munkarendben, milyen más rendszerekkel összekötve, stb. kíván létrehozni. Ezen gondolatmenet mentén kijelenthető, hogy nagyon sok feladat és alkalmazási terület van, ahol bizony a HTML+JS-ben történő fejlesztés sokkal praktikusabb, mint akármilyen klasszikus asztali platform alkalmazása, még akkor is, ha olyan komplex, jól átgondolt és átfogó eszközről beszélünk, mint a .NET.
    Mutasd a teljes hozzászólást!
  • Én a saját kis maszek dolgaimat sem szívesen adnám forrás szinten az ügyfél kezébe (amíg nem fizet semmiféleképpen), de pl. a főállásom esetében a főnököm ilyen téren még konzervatívabb. Nála nem igen jöhet szóba ilyesmi.

    Az obfuscation nyilván opció itt is, ami ugyan nem tökéletes - de ezt akármelyik .NET program esetében is elmondhatjuk, ami szintén igen jó hatásfokkal fejthető vissza.

    Ugyanakkor én úgy érzem, hogy ennek jelentősége (ti. a program forráskódja is elérhető ill. visszafejthető) a napjainkban egyre kisebb. Egyrészt, mert ma már a teljesen egyedi alkalmazási logika az ami kiteszi a programok írásának legnagyobb idejét, így elég kevés olyan a fejlesztő által megírt kód marad amit értelmesen el lehetne lopni önmagában - hiszen a szervízfunkciókat és az újrahasznosítható részkomponensek nagy részét (ha ugyan nem az összeset) már nem egyedi megoldások és könyvtárak, hanem az OS meg a használt framewörk biztosítja.

    A másik, hogy a nyers forrással ma már nem sokra megyünk, mert az már eleve egy általában jóval magasabb szintű vizuális tervező, modellező, stb. eszköz által automatikusan generált valami, ami hatékonyan nem módosítható és fejleszthető tovább az eredeti, magasabb szintű modell hiányában, ami azonban a visszafejtett vagy akár nyers forrásból nem rekonstruálható.

    Így maga az a tény, hogy egy programok forrását a konkurens vissza tudja fejteni irrelevánssá válik, hiszen értelmesen nem tud belőle szinte semmit lemásolni, ellopni, felhasználni - amit meg mégis, azt is csak leginkább úgy, hogy teljesen nyilvánvaló és bizonyíthatóan törvénybe ütköző lenne. Ami kombinálva a központi terjesztési pontul szolgáló alkalmazásbolttal (amelyből a MS nyilván kérésre azonnal kiirtja az esetleg mégis lopott kódokra épülő vagy más módon jogsértő konkurensek alkalmazásokat) egyszerűen értelmetlenné és irrelevánssá tesz minden hasonló visszaélést.

    Szóval én ezt speciel abszolút nem látom problémának a platform esetében.
    Mutasd a teljes hozzászólást!
  • Az azért szerintem egy igen nagy hátrány, hogy a html+js páros végeredménye nyílt forrású.

    Én a saját kis maszek dolgaimat sem szívesen adnám forrás szinten az ügyfél kezébe (amíg nem fizet semmiféleképpen), de pl. a főállásom esetében a főnököm ilyen téren még konzervatívabb. Nála nem igen jöhet szóba ilyesmi.

    De ha belegondolok, hogy a html+js párosban írt összes dobozos program kódja elérhető legyen az szerintem eléggé bekorlátozza az elterjedési lehetőségeket. (Hadd idézzek a Csengetett mylord-ból: "Hová vezetne ez!..." )

    Ok. Az új platform-ot lehet a zárt .net-el is fejleszteni (hál Istennek. Remélem ennek a halálát nem tervezik Redmond-ban), de így szerintem erősen kérdéses a html+js páros komolyabb elterjedése.
    Mutasd a teljes hozzászólást!
  • miközben funkcionálisan nem tudott többet kínálni sem asztali téren, mint a már ott bevált ill. vele párhuzamosan létező asztali platformok, sem a weben, mint az ott már szintén időtlen idők óta létező, de nyíltságuk miatt sokkal jobban hozzáférhető technológiák.


    Ez nagyjából igaz (azért tud pár dolgot, amit html-js-el ma nem igazán lehet megoldani), de szvsz nem is a funkcionalitás a nyerő a html/js megoldásokhoz képest, hanem a fejlesztési módszer.

    Nincs oldalújratöltés, nem kell trükközni, hogy úgy működjön kb mint egy asztali alkalmazás, illetve a c# is ott fityeg :).
    Mutasd a teljes hozzászólást!
  • "meg fogja őrizni a [Silverlight-fejlesztők] befektetéseit" - de teljesen nyilvánvaló, hogy ez az adott kontextusban mindössze csak annyit jelent, hogy a cég nem fogja egyik napról a másikra megszüntetni a platform támogatását. De az, hogy a Silverlight mint technológia jövője az új Windows ökoszisztémában megpecsételődött, a fentiek tükrében aligha lehet kérdéses


    A fentiekre kívántam reagálni: A bemutatott slide-on egybként ott van a SilverLight, mint desktop application fejlesztői platform ( a jobb alsó sarokban, sajnos ).

    Még valami a XAML + C# az maga a SilverLight. A kérdés, hogy ez a metro ui fel fog-e települni Windows Update-tel. Vistára és 7-esre.

    Mutasd a teljes hozzászólást!
  • Azért, mert szerencsétlenkedtem. És nem akartam én az egészet hozzáfűzni, csak véletlenül elkommitáltam, utána meg lemerült a laptopom.
    Mutasd a teljes hozzászólást!
  • A html/js a windows halála. Ha ad is mindenféle kiterjesztéseket a MS erre, a gugli következő lépése az lesz, hogy hasonlókat beépít a chrome-ba is - és persze elérhetővé teszi a dolgot win7-re, XP-re, linuxra, MacOS-re, Androidra, IOS-re.

    A hasonlóval nem megy semmire, ugyanazt meg nem építheti bele. Pont ez a lényege az egész dolognak. Ti. hogy a web egyébként is elmozdult abba az irányba, hogy egyre inkább képes legyen mindarra, ami a klasszikus asztali platformokon megvalósítható ill. amit most ez az új platform is kínál. A különbség annyi, hogy a HTML5, a WebGL és társai nyílt szabványok, így az arra készült alkalmazások valóban nem függnek a Windows-tól. Szemben az új Windows alkalmazásmodellel, amely ugyan a nyílt HTML-re, CSS-re, JS-re épül, de valójában proprietary API-kat hívogat - így a rá készült alkalmazások nem hordozhatók, csak a platformcsaládon belül. Pont ezzel éri el a Microsoft azt, hogy a Windows-ra továbbra is szükség legyen, függetlenül attól, hogy elvileg nyílt eszközök, nyelvek és technológiák felhasználásával készülnek rá az alkalmazások.

    A Microsoft részéről pont az volt a legnagyobb hülyeség, hogy a webet és a webes technológiákat teljesen ignorálta az új évezred első évtizedében, annak ellenére is, hogy azok képezték az informatika legdinamikusabban fejlődő és bővülő területét. Jól nyomon volt érhető a cég homlokracsapása amikor végre rájött erre stratégiai tévedésére, és úgy 2007-2008 környékén elkezdte hirtelen megpróbálni behozni a lemaradását, mind az új IE-változatok, mind az olyan fejlesztői eszközök kiadása formájában, mint pl. az Expression sorozat, az ASP.NET MVC, stb.

    Ez a mostani új fejlesztési modell ennek a felzárkózási folyamatnak a lezárását jelenti, ami végre lehetővé fogja tenni a Microsoft számára, hogy kvázi saját érdekében is megcsapolja a mostanra már talán az asztaliét is meghaladó méretűre duzzadt webes fejlesztői-, kód- és tudásbázist, amit mindeddig parlagon hagyott heverni, sőt, még annál is rosszabbat tett vele: átengedte a Google-nak és más versenytársainak, hogy azokat erősítsék, vele szemben.
    Mutasd a teljes hozzászólást!
  • Az már csak hab a tortán hogy miért lett másodosztályú utas a MS saját technológiája a rendszeridegen javascripthez képest...

    Nyilván azért, mert a fordított és proprietary platformok minden hátrányát sikeresen hozta magával, miközben funkcionálisan nem tudott többet kínálni sem asztali téren, mint a már ott bevált ill. vele párhuzamosan létező asztali platformok, sem a weben, mint az ott már szintén időtlen idők óta létező, de nyíltságuk miatt sokkal jobban hozzáférhető technológiák. Ez HTML5 előtt is így volt, de a HTML5 végképp betette a kaput neki.

    A MS persze sok éven át nyomatta ennek ellenére, de maga a tény, hogy 5 évvel a stabil változat bemutatását követően még mindig csak showcase és/vagy belső, egyedi alkalmazások készülnek ezen platformon, nyilván beláttatta vele, hogy erre egyszerűen nem vevők az emberek (se fejlesztők, se ügyfelek) - az alternatív mobil platformok és a HTML5 térhódításával pedig egyre kevésbé lesznek azok.

    Ilyen körülmények között meg tök felesleges további energiákat ölnie bele. Pláne ha immár létezik egy valóban minden téren és értelemben közvetlen belső konkurenségnek számító platform is ez az új HTML5+JS alapú felület személyében. Ami megjelenése nyilván nem érte meglepetésként a MS-ot (hiszen ő készítette), és amelynek puszta létezése is tökéletes bizonyítéka annak, hogy a Silverlight kinyírása stratégiai szempontból már legkésőbb a Windows 7 kiadása óta eldöntött kérdés volt a cégen belül.
    Mutasd a teljes hozzászólást!
  • Innentől kezdve viszont nagyon bátor az aki erre az API-ra nekiáll fejleszteni addig amíg nincs 60% fölött az elterjedtség - viszont nehezen fog felmenni ez 60% fölé, amíg ez csak a win7 újabb kiadása, márpedig a fenti API nélkül nagyjából ez a helyzet.

    Ha ez így működne, akkor ma mind az Apple AppStore, mind az Android Market kongana az ürességtől, hiszen mindenki a bűvős 60 (vagy akárhány) százalékos penetráció elérése várna és várt volna évek óta (ami irányába azonban még az elindulás sem következett volna így be sose). Ehhez képest valójában százezerszám állnak az alkalmazások mindkettőben, pedig egyikük sem éri el a 60%-os penetrációt, még a mobilszegmensen belül sem - nem ám, hogy a Windows őshonos piacát, az asztalit is beleszámítva.

    Nyilván nem fogja mindenki a Windows 8 megjelenésének másnapján kidobni az asztali kódjait, de annak semmi akadálya nem lesz, hogy elkezdjenek gyűlni ezek az új, Windows 8-only alkalmazások. Főleg, hogy ez az új fejlesztési platform a HTML5+JS révén sokkal hozzáférhetőbb, a Windows-alapúság miatt pedig sokkal ismerősebb és megbízhatóbbnak tűnő lesz mindenkinek, mint amilyen a kvázi vadiúj és vadiismeretlen Android és iOS is voltak anno indulásukkor.

    Arról nem is beszélve, hogy hosszútávon (a folyamatos Windows 8-ra, későbbi 9-re, 10-re váltással) mennyivel nagyobb lesz garantáltan ez a piac, mint akár az Android, akár az iOS volt vagy van ma, és ebből kifolyólag mennyivel fontosabb lesz stratégiai szempontból is az ezen történő minél előbbi megjelenés minden komoly cég számára (is).
    Mutasd a teljes hozzászólást!
  • A kiszivárgott levél elolvasása azért volt hasznos számomra, mert jól lehet belőle látni, hogy mennyire tudatos stratégiai izmozások mennek a háttérben (szóval nem csak az újságírók belemagyarázásai ezek a stratégiák.)

    [Caja] Fwd: "Future of Javascript" doc from our internal "JavaScript Summit" last week - Mark S. Mil

    Nyilván az a céljuk, hogy a Dart-ot elérhetővé tegyék minden browserben. Ezt úgy próbálják elérni, hogy készítenek Dart -> Javascript cross-compilert, vagyis a delikvens megírja a cuccot Dart-ban, és a szerver Dart-kódot szolgál ki arra a böngészőre, amelyik támogatja és Javascript kódot arra, amelyik nem. Nyilván ebben a helyzetben versenyelőnnyé válik a browsereknek a Dart-ot támogatni, hiszen a Dart kód gyorsabbanfut majd.

    Egyáltalán nem azért írom ezt, mert úgy gondolom, hogy sikerrel járnak ezzel, csak jelzem, hogy elvileg milyen stratégiákban gondolkodnak.
    Mutasd a teljes hozzászólást!
  • Az elfogadja itt persze azt jelenti, hogy nem tud mit csinálni. Vagy azt, hogy inkább nem a webes platformot választja.

    De valóban nem ez a legnagyobb baj vele, hanem a típuskezelése. Ahogy a PHP-vel is.
    Mutasd a teljes hozzászólást!
  • A JS-nek az az egyik erőssége, hogy minden létező böngésző támogatja, az a Dart meg Chrome only. A JS-nek különben sem a sebessége a nagy baja, mert aki scriptet használ, általában elfogadja, hogy lassabb, mint a natív alkalmazások. Sőt azt is elfogadja, hogy a kliens oldalra kerülő kódot bárki megnézheti.
    Mutasd a teljes hozzászólást!
  • A WCF-et LC kérdésére reagálva hoztam fel. Pontosan arra akartam én is rávilágítani, hogy a WinRT képbe kerülésének semmi köze az egész WCF témához. A kliens oldalon lévő üzleti logika szétválasztását már egy előző hozzászólásomban írtam én is:
    Sőt! Kimondottan azt írják, hogy az üzleti logikát .NET-ben írd és tedd ki egy DLL-be, a felület logika és a felület meg mehet abban ami neked könnyebb!
    Mutasd a teljes hozzászólást!
  • Ez a bejelentes inkabb valami trukkos marketing lesz :D, mindenki elkezd aggodni, hogy mi lesz, kozben meg a linkelt kép alapjan még a majd' 20 éves win32 sem múlt ki.



    És még delphi fejlesztőket is keresnek párszor, pedig az miatt is rinyálnak néha, hogy így meg úgy cserbenhagyta a fejlesztőit a Borland, winforms is működik.

    Amúgy nekem ma még mindig sokkal gyorsabb winformsban mint asp.net-ben, vagy silverlight-ban, wpf-ben.
    Pedig jó ideje tolom a wpf-t, silverlightot, előtte meg sokat asp.net-eztem. Winforms-mal meg összesen kb 1-2 évet dolgoztam. De ha gyorsan kell valami, akkor sokkal gyorsabban összedobom vele.
    Mutasd a teljes hozzászólást!
  • Köszönöm. Mobil telefonokon régóta van ilyen controll elem. iOS alatt pld UIScroll-nak hívják. Nyilván itt valami tőkeháború lesz a háttérben, ha úgy döntöttek, hogy egy egész rendszert íratnak ahelyett, hogy szimplán egy új kontroll elemet adnának a meglévő platformoknak. A csata kimenetele majd úgyis dönt a sorsáról. (Felhasználóként csak azt észrevételezném, hogy aki windowst használ, az jobb szeret egyszerre több alkalmazást látni a monitoron, így ez az ötlet desktop-ot lecserélni talán jó, de alkalmazás felületnek használni szerintem elba**ott egy ötlet.)
    Mutasd a teljes hozzászólást!
  • Mivel a Metro style felület csak a Win8-on érhető el ez annyira nem meglepő. Viszont ha megfelelően felépített alkalmazást fejlesztesz, akkor ez csak annyit jelent, hogy a felhasználói felületet érintik a változások. Ha az üzleti logikát egy WCF szolgáltatáson keresztül éred el, akkor ez az egész azt a részt nem érinti.


    Nem értem hogy érinti a wcf a témát. Nyilván, ha van egy service-ed, azt nem érinti egyáltalán a metro ui.
    Kliensoldalon is van általában üzleti logika.
    Inkább ott kell szépen szétválasztani a rétegeket. Pl egy külön dll-be pakolni a ui független részt.
    Mutasd a teljes hozzászólást!
  • Mivel a Metro style felület csak a Win8-on érhető el ez annyira nem meglepő. Viszont ha megfelelően felépített alkalmazást fejlesztesz, akkor ez csak annyit jelent, hogy a felhasználói felületet érintik a változások. Ha az üzleti logikát egy WCF szolgáltatáson keresztül éred el, akkor ez az egész azt a részt nem érinti. A felületet meg úgy is újra kell rajzolni, hogy a felhasználói élmény megfelelő legyen.
    Mutasd a teljes hozzászólást!
  • Ez a bejelentes inkabb valami trukkos marketing lesz :D, mindenki elkezd aggodni, hogy mi lesz, kozben meg a linkelt kép alapjan még a majd' 20 éves win32 sem múlt ki.

    Itt szerintem vagy valami nagyon uj szulethet a semmibol (de az hogy terjed el, ha remek is, de csak magaval kompatibilis?), vagy megy tovabb a jelenlegi 'kompatibilitasok' egymasra halmozasa, mint ami most van.
    Mutasd a teljes hozzászólást!
  • Köszi a választ!

    A kép alapján azt értem, hogy a VS-ben ahogy eddig is tudok majd fejleszteni, és elérem a kényelmes varázslókat, meg a .net által nyújtott lehetőségeket (ado.net, linq, stb... mindenki ismeri ezeket)

    Viszont azt nem értem, hogy futtatáskor ezek már nem a hagyományos .net framework-ot fogják használni, hanem a WinRT-t. Ez fogja tartalmazni a .net framework-öt?

    És webfejlesztés mennyibe érintett? (akár webforms, akár mvc)
    Ha jól értem az semennyire? (A szerveren ugyanazon a logikán fog működni a weboldalak kiszolgálása, IIS + .NET el. )
    Mutasd a teljes hozzászólást!
  • A html/js a windows halála. Ha ad is mindenféle kiterjesztéseket a MS erre, a gugli következő lépése az lesz, hogy hasonlókat beépít a chrome-ba is - és persze elérhetővé teszi a dolgot win7-re, XP-re, linuxra, MacOS-re, Androidra, IOS-re. A fejlesztők meg melyik javascript extension-t fogják preferálni ?
    Mutasd a teljes hozzászólást!
  • Teljesen igazad van abban, hogy bonyolult a helyzet és még senki nem tudja melyik nyelv fog elterjedni a fejlesztők körében. Ezt majd a jövő eldönti, nekem egyenlőre az is elég, hogy dolgozhatok tovább a megszerzett tudásommal és a felépített könyvtáraimmal. A felhasználói részről jövő nyomással kapcsolatban az én tapasztalatom (kissebb projektekben dolgozok) az, hogy teljesen mindegy a felhasználónak, hogy miben dolgozol, csak legyél készen időben és a megfelelő minőséget biztosítsd. Azzal, hogy a jelenlegi alkalmazások futtathatók leszenk még a Win8-ban és az áthelyezésük is megoldható ha kell már az is biztosítva van, hogy még 5-10 évig használhatóak is maradnak.
    Mutasd a teljes hozzászólást!
  • Persze, ott vannak. Benn ott a sarokban a C++/win32 mögött.
    Aztán ott a szép zöld WinRT API-d ami fölött ott a C# és a html, de az hogy a WinRT API Communication & Data-nak lesz-e köze az EF-hez, vagy a WCF-hez, arról már nincs szó. A .NET != C#+XAML.

    És arról sincs szó, hogy a zöld rész portolva lenne win7-re vagy pláne XP-re is. Ami azt jelenti, hogy ha a szép zöld UFO-t programozgatod, akkor a progidat garantáltan csak win8-ra adod el.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd